We are still on CMOD 8.4.0.3 on Z/OS 1.11, and CMOD worked very well until very recently.
Since I am on z/OS 1.11, with 1.13 imminent end of September or October, OAM support at IBM is refusing to be of any assistance.
We are now seeing a lot of errors in OAM, paired ARS0024E and ARS0020,
Object not found, and No space left on Device. The no space left makes no sense because we are reading data. Most of our data is migrated from CMOD 2.1, and I think that is the reference to node OD390PRD.We are on a virtual VTS, so we could not have had the volume of data go bad suddenly, but there should be a way to access it. I have read quite a lot of data that should also have come from the same node, as part of a data migration effort from z/OS based CMOD to AIX based CMOD.
ARSDOC Get commands work up to a certain date range, then there seem more errors than successful hits.
Can anyone give me a clue what is going on ?
Will z/OS 1.13 solve this problem ?
I'm not familiar with now OAM related to (and works with) CMOD on the Z, but in the MP world, it's unfortunately common for there to be a misconfiguration between CMOD and TSM (which handles long term storage ie, storing data on tape). In that scenario, TSM expires data as per it's configuration, and if CMOD isn't expiring the database records at the same time, you end up with orphaned records. That is, you can search and find old records, but you can't retrieve them, because the database rows pointing to them have been removed or marked as expired.
You may want to simply look at the age of the records, then your CMOD configuration (including Life of Data and Indexes and your arsmaint expiration schedule) and see if there's a reason why this data has been disposed of.
-JD.
Justin:
Thanks for the thoughts on this. I am well aware of the data expiration aspects. In many of the cases, I have reports that can be read for over 90%, but a particular block of pages fails within that report. I am migrating data, oldest first. In working with the DASD manager (we have a guy dedicated to managing the storage hardware and its configuration), CMOD is the only product using OAM, and he and I work on the data expiration configuration together.
For one particular report, with failing iterations, the first 150 iterations of the report all loaded without a problem. Those took about three weeks to run in their batch script.
Each of the object read/not found failures does produce a dump file in OMVS, in CMOD's temp directory. A few days ago, every object read seemed to be failing, and the mount point for this directory was out of space. I cleared out the directory, freeing up at least a few hundred megabytes.
I tried a retrieval of a few small reports, and they still failed. The subsequent CEEDUMP dump files all point at repeated attempts to access inaccessible storage.
I then tried a retrieval of a very large report, which had been successful for weeks in its retrievals.
It completed loading about 40 minutes after I left work, though on an iteration of the report which had not been tried yet.
Next I should try to load one of its iterations which failed at the end of last week. There are three of those.