Greetings,
I think I might have found a problem with CMOD v9, and before opening a PMR, I wanted to see if any of you had experienced the same issues with the ARSDOC QUERY command on CMOD v9 as I am. Here is a description of the problem I am experiencing.
Sorry for the lengthy post, but I tried to include as much info as possible...
We run CMOD on an AIX platform. Our documents are composed and processed on a mainframe thru a batch process. For control purposes, after every load, we run the ARSDOC QUERY command in order to create a detailed control file containing specific index values that can be compared with another control file created at the composition step.
Here is a sample command with its output message:
2013-09-24 12:23:26.240799: ARS6108I Starting arsdoc. Version: 9.0.0.2
2013-09-24 12:23:26.241195: ARS6165I /opt/IBM/ondemand/V9.0/bin/arsdoc query -h localhost -u cmodload -G IPMFPOLP -X 5329-13-0-56FAA-20130830000000-20130830000000-5333 -v -N (company) (province) (policyNumber) (policyInceptionDt) (transSequence) (policyType) (documentClass) (branch) (transCode) (docRecipientType) (testDataInd) (internUseTransInd) (transPaperInd) (transSubCode) (transEffectiveDt) (lastUpdTsAccStat) (processingDt) (stdDocNumber) -o testF.dtl
2013-09-24 12:23:26.241818: ARS6822I Attempting login for userid 'cmodload' on server 'localhost' ...
2013-09-24 12:23:26.428441: ARS6080I Login successful
2013-09-24 12:23:26.428757: ARS6836I Querying for application group 'IPMFPOLP' on server 'localhost' ...
2013-09-24 12:23:26.476028: ARS6082I Query successful
2013-09-24 12:23:26.476502: ARS7013I Building hit list for 'IPMFPOLP' ...
2013-09-24 12:23:26.578493: ARS7014I Hit list successful
2013-09-24 12:23:26.578851: ARS6071I Writing 6 hits in file 'testF.dtl'...
2013-09-24 12:23:26.580687: ARS6092I Write successful
2013-09-24 12:23:26.581749: ARS6026I arsdoc completed.
This still worked fine after the upgrade to v9.0.0.2. The problem started as soon as we converted our application groups to create/use new style date/time field types in place of existing old style date/time field types. Once the conversion process was completed, the same command as above generates no output, and suprisingly... no error. Here is the output following the conversion of an application group:
2013-09-24 12:28:41.548357: ARS6108I Starting arsdoc. Version: 9.0.0.2
2013-09-24 12:28:41.548796: ARS6165I /opt/IBM/ondemand/V9.0/bin/arsdoc query -h localhost -u cmodload -G IPMHPOLP -X 5319-9-0-156FAA-20130924000000-20130924000000-5323 -v -N (company) (province) (policyNumber) (policyInceptionDt) (transSequence) (policyType) (documentClass) (branch) (transCode) (docRecipientType) (testDataInd) (internUseTransInd) (transPaperInd) (transSubCode) (transEffectiveDt) (lastUpdTsAccStat) (processingDt) (stdDocNumber) -o testH.dtl
2013-09-24 12:28:41.549306: ARS6822I Attempting login for userid 'cmodload' on server 'localhost' ...
2013-09-24 12:28:42.009532: ARS6080I Login successful
2013-09-24 12:28:42.010000: ARS6836I Querying for application group 'IPMHPOLP' on server 'localhost' ...
2013-09-24 12:28:42.056780: ARS6082I Query successful
2013-09-24 12:28:42.057213: ARS7013I Building hit list for 'IPMHPOLP' ...
2013-09-24 12:28:42.165356: ARS7014I Hit list successful
2013-09-24 12:28:42.165819: ARS6071I Writing 0 hits in file ' testH.dtl '...
2013-09-24 12:28:42.198371: ARS6092I Write successful
2013-09-24 12:28:42.200809: ARS6026I arsdoc completed.
The log entries in the system log are the same, they identify the appropriate number of hits, but nothing gets moved to the output file... other than the field names if the ?H parameter is used.
I even tried the command without using any date fields... that didn?t change the outcome.
I tried using the new DB2 field names for the newly converted date fields... that generated an error.
I am all out of ideas ???
Any suggestions?
Patrick
I think in one of his recent posts, Alessandro mentioned that between 8.5 and 9.0 you may have issues if you are using the new date format.
In your case too this may be the problem, but i am not sure.
Hi again folks,
I'll open a PMR for the issue described above. In the meantime, I found a workaround solution. The arsdoc query command has many options, so I tried to duplicate the expected results by using different parameters.
The origal problem was running the following command:
arsdoc query -h instance -u userid -p password -G applGroup -X loadId -v -N "(fieldA) (fieldB) (fieldC)" -o outputFile
This command doesn't require a query (-i) because the -X parameter returns all the documents loaded by the specified loadid. So I tweaked the parms to do the same but using the -x parameter which limits the query to the specified loadid and using the -i parameter with a dummy query to return all documents. the resulting command was this:
arsdoc query -h instance -u userid -p password -G applGroup -x loadId -i "WHERE fieldA <> ''" -v -N "(fieldA) (fieldB) (fieldC)" -o outputFile
Suprisingly, I am getting the appropriate results. :o
This way is probably not as efficient, but it will do until we get a fix...
have a great weekend :)
Hi PBastien,
Well I've learned a few things lately about this new date :-)
When you convert an existing application group with the new date format (eg: doc_date), then CMOD will create a new field called "<field>_DT", (eg: doc_date_dt).
Starting from this moment, the old field (eg: doc_date) will stay empty, and the new date will be stored in the new one (eg: doc_date_dt).
CMOD will automatically detect that case, and create the SQL query accordingly.
Now with the "arsdoc query" command, you might need to experiment what works or not... like you did. I haven't had many opportunity to play with it...
Hope that helps a little bit.
Sincerely yours,
Alessandro
Hi Alessandro,
I have done quite a bit of reading on the converted dates also ... and the details you provided are correct. However, the original date is not left blank... it is set to -1.
Thanks for your input...
Have a great day :)
Patrick