OAM errors from CMOD 8.4.0.3 on z/OS 1.13

[LWagner]

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

[Justin Derrick]

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!

[LWagner]

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.