I am seeing a lot of
ARS0020 SM Error: ARSZSMRE: 00000013 EDC5000I No error occurred. (errno2=0x00000000), RC=19, Reason=0, File=arssmsms.cpp, Line=928 Srvr->mf-prod.ladwp.com 10.10.88.8<-
couple with an ARS0024 error giving the object name and application group,
05/27/2015 23:59:46 sysuid 82205 Error No 24 Object >13OOXAA< in Application Group >ZKB< not found in node >OD390node< Srvr->mainframe.server.name mainframe-ip-address<-
I am migrating data from z/OS CMOD 8.4.0.3. Extract method is scripts running on a Windows CMOD server, strictly used for this purpose.
The scripts check for an error following "arsdoc get", and will repeat the arsdoc get, until it succeeds or I terminate the script.
I have successfully run hundreds scripts, with a few to thousands of iterations. Errors like this have been rare, except in about 10% of scripts.
I am currently processing a script that has these errors frequently. In many instances, with multiple atempts, the script iteration progresses through the document not found error, and eventually completes. I also have had some which appear to never complete, failing on over a dozen attempts, and one over 200.
I can not upgrade my CMOD 8.4 to CMOD 9.0, as we are lacking DB2 v10, and it looks as if this is a long term issue.
IBM OAM support says things look ok in OAM, and throw it back for CMOD support. But we need to purchase for out of support CMOD.
I am working on that.
Meanwhile any ideas ? The data in question is NOT expired. The arsdoc get code below is a sample from a working script.
Here is an extract sample:
:EXTRACT-LABEL-CIR01N02-V01-11535
arsdoc get -h <ip-address> -u sysuid -p syspw -A 7 -vcgNn -i "WHERE REPORT_NAME = 'CIR01N02-V01' AND POSTING_DATE = 11535 " -f "DAILY CASH BATCH LISTING" -G DOC0200 -o CIR01N02V01 -d c:\ars1-testa 2>> DOC0200.CIR01N02-V01.log2-11535.txt
IF %ERRORLEVEL% NEQ 0 (
TIMEOUT 180
GOTO :EXTRACT-LABEL-CIR01N02-V01-11535
)
Thank you
This can happen for a variety of reasons. In the MP world, this is because TSM is configured to store the objects for a different length of time than CMOD is configured -- so the object expired in the storage manager (TSM in our case) but the record still exists. Alternately, it could be that your AG is set for segment expiration -- and you've retained metadata for longer than the system was configured to store the objects. It looks like the record you're looking for is over 14 years old -- it could be either case, really...
Good luck!
Data is there. Alternate posting date files load without error.
Some load after an initial error.
Its data Finance wants kept ... as long as possible.