ARSDOC UPDATE No Long Allows for Multiple Lines in Parmfile in 8.5.0.6

[JJeffrey]

We just upgraded and migrated our CMOD installation from AIX to RHEL and ver 8.4.1.5 to 8.5.0.6 and DB2 9.1 to 9.7.  In the previous version we were able to update the rows in DB2 using ARSDOC UPDATE with multiple name value pairs in a parmfile. Now it looks like that we are now limited to updating one record at a time.  This is not an efficient use of time when we could have hundreds of rows that need correction. One line at a time? Really?

Anybody have any suggestions (besides having correct data in the first place, we're not going there) ideas or experience with this issue and how to get around it?  I'm not liking the responses I'm getting from IBM from my PMR.

This is my command:

arsdoc update -h cmod*** -F /home/mylib/update/input.txt -v

This is the contents of the parmfile:

[-f "EEOB"] [-i "WHERE ContractNo = 'xxxxxxxxx' and NotificationNo = 'PDF2******9011619'"] [-n "ContractNo = 'zzzzzzzzz'"]
[-f "EEOB"] [-i "WHERE ContractNo = 'xxxxxxxxx' and NotificationNo = 'PDF308*****030263'"] [-n "ContractNo = 'zzzzzzzzz'"]
[-f "EEOB"] [-i "WHERE ContractNo = 'xxxxxxxxx' and NotificationNo = 'PDF309******29255'"] [-n "ContractNo = 'zzzzzzzzz'"]
[-f "EEOB"] [-i "WHERE ContractNo = 'xxxxxxxxx' and NotificationNo = 'PDF3103*******566'"] [-n "ContractNo = 'zzzzzzzzz'"]

The utility will err on all lines EXCEPT the last and that it will execute as seen below:

OnDemand Login:admin
OnDemand Password:
 
 
05/01/13 07:59:34 : Attempting login for userid 'admin' on server 'cmodprd1' ...
 
05/01/13 07:59:34 : Login successful
Usage: arsdoc update -h hostname [-u <userid>] [-p <passwd>] [-U <user_alias>] [-v] (-F <parmfile> | ((-i <sql_query> | -q <namedquery>) [-f <foldername>] [(-g <name> | -G <name>)] -n field1=value1 [-S <startdate,enddate[,format]>]))
        Version:  8.5.0.6
        -f <foldername> OnDemand folder                 (required in parm file)
        -g <name> Application Group Name
        -h <hostname> OnDemand Hostname                 (command line only)
        -i <sql_query> SQL query string
        -n <field1=value1> One or more database field names and values
        -p <passwd> OnDemand User Login Password        (command line only)
        -q <namedquery> Public named query
        -u <userid> OnDemand User Login Name            (command line only)
        -v Verbose                                      (command line only)
        -F <parmfile> Requests parameter file           (command line only)
        -G <name> Application Group Name
        -S <startdate,enddate[,format]> Segment date range
        -U <user_alias> User alias that appears in System Log messages
Flags in a parameter file must be delimited by brackets EX: [-f foldername]
 
05/01/13 07:59:34 : The error occurred on line number 1.
 
05/01/13 07:59:34 : Searching for folder 'EEOB' ...
 
05/01/13 07:59:34 : Search successful
 
05/01/13 07:59:34 : Searching for documents in 'EEOB' ...
 
05/01/13 07:59:34 : Querying database with SQL string 'WHERE ContractNo = 'xxxxxxxxx' and NotificationNo = 'PDF30*******0263''
 
05/01/13 07:59:34 : Search successful
 
05/01/13 07:59:34 : Updating 1 documents with
ContractNo=zzzzzzzzzz

[Justin Derrick]

This sounds like a bug, and if I had to guess, I'd say it was only updating the most recent record (ie, only searching one table segment).

How many records do you get if you search for that same criteria? 
Have you tried entering a segment date range with the -S option, and inserting the desired date range into the WHERE clause?  (It might be inheriting the default dates from the folder config.)

Let us know how it works out.

-JD.

[JJeffrey]

Tried the command with -S this morning because I had 38 indices to update for a member.  Ended executing a manual update 38 times.  This is not acceptable. Why is it when IBM updates something they break something else? What am I left to do when I have 900 rows to update?  Run the command 900 times?

[Ed_Arnold]

Have you opened a PMR with IBM support?

Ed

[JJeffrey]

Yes I opened a PMR 

[JJeffrey]

The solution turns out to be we now have to run dos2unix on the parmfile after we sftp it and before we use it.  Because we use FileZilla to sftp the file to the server and  because THAT in turn uses pieces of PuTTY, the file doesn't transfer as ASCII. Apparently PuTTY doesn't yet support ASCII ftp protocol. Thanks to my teammate who drilled down in a couple of FileZilla forums for the info.  I have performed several tests of this solution and it works.