How to trouble shoot CMOD OAM reports when they do not transition from OAM DASD

[LizetteKoehler]

I am having a challenge with CMOD and OAM.  We have a large number of reports in OAM DASD.  But most of them should have transitioned to OAM TAPE

We have worked on the ACS Code with IBM L2 SMS.  We have tried to set up reports to see if they actually transition.

I am looking for an easy way to diagnose the ACS routines to see how the transition process works

We thought when we set up CMOD with OAM the process was working.  Instead, some of the OAM Objects just keep growing on DASD and consuming everything they can.

I also need a refresher on the process used that tells OAM that the report should go to TAPE.

Our ACS routines are not complex.  but I think sometimes the logic flow in SMS for CMOD/OAM can get confusing for me

Thanks

Lizette

[Greg Ira]

Has anyone checked if your OSMC (OAM Storage Management Cycle) is completing successfully for your OAM storage groups?  OSMC should be running daily and it handles the transitions.  If there is any errors (missing objects, missing directory) the processing ends for that storage group and moves on to the next.  We've discovered in the past a few storage groups that had been erroring out for months and the docs sat on DASD well beyond their transition dates.

[Mehmet S Yersel]

Hi Lizette -

Before you start, verify that the OAM storage/management class is defined to handle life-cycle as you expect (30 day DASD then 83 months on TAPE, etc). If not, this might be where the problem is. Assuming the storage/management class is defined correctly and assigned to the objects in question, then you should expect DFHSM to act accordingly.

To verify DFHSM works properly, you can run a query on the OAM Object Directory table and identify the objects (or object count) due for DFHSM processing. DFHSM started task will have 2 type of activities during its processing window:

1. Create backups of newly added objects or any objects so far not backed up yet (due to DFHSM window closing without going through all storage groups)
2. Migration (or expiration) of objects with ODPENDT =< CURRENT DATE

If there are no objects in any storage group that meet any of the 2 criteria above, there will be no action taken on that particular OAM Storage Group during DFHSM processing.

If any of the objects has not been backed up yet (secondary copy attributes blank (TAPE and VOLUME), can't remember the attribute names but if you pull the object directory structure, you can tell which one they are), or there are objects in need of DFHSM processing (ODPENDT <= today which means there is something  in need of expiration or migration),  then you should expect activity on that  storage group.

If there are no errors, maybe there are other things such as a small processing window not sufficient to go through all the pending activities. Or, when CPU utilization is very high, DFHSM might not be able to get enough processing cycles and it may fall behind. Make sure to see DFHSM task visiting every storage group before it ends. If it ends and there are still objects to process,  you may see a lag until you can catch up.

One final thing to check: If DFHSM procesisng is good and so far you have not seen any irregularities, check DB2 internals. Many years ago we had a DB2 table problem where deleted rows were not being physically deleted and the table size was constantly growing and adding new extents despite the fact that there were same number of deleted rows as newly added ones. It turned out to be a DB2 problem where space from deleted rows were not being reclaimed for use. OAM DASD sits on DB2 AUX tables. Make sure your DB2 tech team verifies that there is no DB2 problem and that if there are deletions, these deletions finally get deleted physically as well and don't stay there forever.

Good luck with your investigation of the root cause.
I hope this helps,
Mehmet