arsdoc update issue in CMOD 9.0

[mani]

Hi,

I am getting the below error while executing arsdoc update in CMOD 9.0 on RHEL 6.4

arsdoc update -h APAC -g 'TA' -f "Client Reports" -u archive -i "where BUID='0058' AND CIFNo ='123456'" -n "ODGrp='yyyyy'"

2015-04-08 10:56:16.325536: ARS2120E 'yyyyy' is invalid for 'DocDate'.  A date/time in the range '01/01/0001' to '31/12/9999' is required.  Note that 2-digit years less than 70 are interpreted as year 20nn.

Note: password for the archive user id is already added to the stash file.

Note: This was working fine in CMOD 8.4.1.6

The user archive is having the update permissions to the app group and also the field "ODGrp" has the Updateable check box enabled.


Any ideas or suggestions on the possible cause of the issue is much appreciated.


Thanks
Mani

[Justin Derrick]

In order to keep performance brisk, CMOD segments tables by date.  The field that OnDemand uses to segment these tables is a date field with the 'Segment' checkbox enabled in your Application Group configuration.  You may need a -S option to specify the date range for there 'where' clause.  If you want this to take effect for all segments (tables) documents, just choose a very wide date range (01/01/1970 - 12/31/2015).

The example you provided looks weird, because "yyyyy" appears both as part of the update statement, and in your error message, even though they should be separate values.  Can you show us the actual values?  The attempt at obscuring the data may be causing confusion. 

Thanks!

-JD.

[mani]

Hi JD,

I just gave "yyyy" only for this forum for masking purpose.

we can take ODGrp = 'ABCD"

[mani]

Hi JD,

I tried many options with the Segment date option (-S). details below:

arsdoc update -h APAC -g 'TA' -f "Client Reports" -u archive -i "where BUID='0058' AND CIFNo ='123456'" -n "ODGrp='ABCD'" -v -S 01.01.2015,31.12.2015,%d.%m.%Y


2015-04-09 12:12:33.830443: ARS6117I Querying database with SQL string 'where BUID='0058' AND CIFNO= '123456' AND ODGRP ='ABCD''

2015-04-09 12:12:33.830709: ARS6085E Search unsuccessful



2015-04-09 12:12:33.830739: ARS2120E '01.01.2015' is invalid for 'DocDate'.  A date/time in the range '01.01.Y' to '31.12.Y' is required.  Note that 2-digit years less than 70 are interpreted as year 20nn.

2015-04-09 12:12:33.834175: ARS6026I arsdoc completed.

Note:

I checked the AG table in the backend( DB2) I am able to find the row as below:

BUID  DOCDATE    ODGRP      CIFNO               
----- ---------- ---------- --------------------
             
0058  04/02/2015 ZZZZ    123456 

[Justin Derrick]

Two things I've noticed.

It's adding the parameter in the -n option to the query -- when it seems like it should be part of the update command instead.

Second, I usually quote the parameters to the -S option, because there's a lot of special characters.

The examples in the documentation seem to confirm that your arsdoc command isn't working properly.  Which version of CMOD are you using?  (I know the topic says 9.0, just wondering what patch level you've applied.)

http://www-01.ibm.com/support/knowledgecenter/api/content/SSEPCD_9.0.0/com.ibm.ondemand.administeringmp.doc/doddo009.htm?locale=en

[mani]

Hi JD,

we use CMOD server: 9.0.0.0

No fix pack applied yet.

Thanks
Mani

[Alessandro Perucchi]

From you command that you use, I see no problem at all.

I would say that the -S is optional, and if you want to update all segments, then you don't need it.

Now... I would suggest to try to install the latest fix pack for V9, which is at the time of writing FP5. And try again. If that doesn't work, then something is fishy!!!
Would it be possible to share how the AG and APP are done? Maybe we can help that way.

[mani]

Hi all,

fix pack Version:  9.0.0.5 is applied and all good now. many thanks for your time


thanks
Mani

[Alessandro Perucchi]

Hello Mani,

thanks for the update :-)

I've checked the releases notes of CMOD V9 and didn't see anything strange, so maybe that was a generic undocumented correction. :-)

Nice to know!

 

[Justin Derrick]

Glad to see that a patch fixed it...  If only all fixes could be so simple. 

Take care!

-JD.