OAM Object Name Reference

[scottnys]

First of all, I agree with Greg (he's my supervisor  ) .
We have traditionally used various OAMs: 1year, 3years, 10years, etc.   Even if that would work, we wouldn't want to effect all of the other reports stored in that OAM - just the one APPLICATION Group in question.

if the report's retention were to be extended, we would only change all of the OAMs objects related to that ONE Application Group.  We would then change the CMOD Storage Set to then point to ANOTHER OAM with the desired, longer retention.  Future reports would then be stored there. 

[Greg Ira]

We've never tired running an OSREQ CHANGE so I couldn't say if that would work for you.  My concern doing that, in our case, would be that the collection name would effectively be changed and I'm certain CMOD wouldn't be able to find the document when trying to recall.

[Mehmet S Yersel]

Question:  If I update the management class in the OAM object directory for the documents in question, would that effectively change it's retention?

You also have to set the ODPENDT to , say today or a date in the past, thus forcing OSMC nightly processing to 'look' at this object and recalculate its retention and expiration dates.


It has been a long time that I had done this and I don't currently have access to an OAM based CMOD system to test and verify what I remember as doing. I hope my memory is not fooling me.

Here is what i have found from the documentation: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idao200/noselct.htm

I hope this helps,
Mehmet

[rjchavez]

I've been doing some extensive testing on all of this on our DR system (mirror copy of production).  I've developed some queries which go against ARSSEG and the OAM tables and create the OSREQ CHANGE MANAGEMENTCLASS(....).  I have AG which contain many applications but they all have a specific retention/MC.  Back when, IBM services was contracted to convert us from SARS to CMOD.  They have a DB field named OD_RID which is equivalent to the Application Name and thus many Applications can be contained within an AG.

My query goes against the AG and finds the OD_RID (AP) that I want to change.  I picked one particular application and changed it's management class in OAM from 90-day to 1-year.  Obviously the ODPENDDT does not change when the update is made.  I then run the OSMC cycle on the particular storage group and viola, the ODPENDDT changes from 90-day to 1-year.  I then retrieve the documents wihthout a glitch.  The OSREQ CHANGE does not change the object name so CMOD can always find it.

The only caviat is in our naming convention of the AG which indicates the retention period in the name.  So now, the AG 'name' indicates a 90D retention but there are applications with different retentions within.  I will keep testing for a few days performing new loads and running the ARSMAINT cycle which cleans up the indexes etc. to see if the retention works as designed.

[Mehmet S Yersel]

I was able to identify the documents in the OSM_OBJ_DIR that I would want to change the expiration for.  One issue though, in your UPDATE statement you're updating the ODEXPDT but in my OAM table ODEXPDT is set to '0001-01-01'.  What does look like an expiration date is ODPENDDT which is set to '2024-02-05'.  Would that be the date to change?

I wouldn't recommend changing the ODEXPDT. As a general rule, we should avoid changing any derived attributes that the system could override and undo and worse of, cause data loss. Instead, change management class as if you were storing the object new, right now. Whatever the desired storage/management classes are, change to these classes. Next, you need to tell OSMC to adjust all other object transition dates (migration/expiration) by updating the ODPENDT to today or some old day.

If your management classes dictate a multi-tier storage (DASD, then TAPE (or tapeless-tape etc)) , ODPENDT would indicate the date of next transition to be applied by OSMC. By setting it to today after updating management class, you would be quite safe in protecting the data integrity within OAM.

In the past, I have migrated large OAM systems from one sysplex to onother remote sysplex on an external network, directly OAM-to-OAM on same sysplex due to LPAR consolidations where we had to combine OAM instances and migrate data from one OAM/LPAR into the other... some crazy stuff...  So, this is what I strongly suggest to do, don't update the ODEXPDT because it is a derived field. Let OSMC calculate that for you based on ODPENDT and management classes. 

[rjchavez]

Well I think I may be SOL here since the AG has an "Expire in 90 Days" setting and since I'm not changing AGs but rather OAM MC/date, then indexes would expire before OAM.  Any way to get around this?

[Mehmet S Yersel]

Well I think I may be SOL here since the AG has an "Expire in 90 Days" setting and since I'm not changing AGs but rather OAM MC/date, then indexes would expire before OAM.  Any way to get around this?

Admin Client -> Applications -> select your application and right click -> View an Application -> Advanced Options -> Under Life of Data and indexes you will have 2 options:

Use application group value
Expire in ##### days

This might be the other place to make corresponding changes.  As always, test everything even if clear as day

[rjchavez]

Well I think I may be SOL here since the AG has an "Expire in 90 Days" setting and since I'm not changing AGs but rather OAM MC/date, then indexes would expire before OAM.  Any way to get around this?

Admin Client -> Applications -> select your application and right click -> View an Application -> Advanced Options -> Under Life of Data and indexes you will have 2 options:

Use application group value
Expire in ##### days

This might be the other place to make corresponding changes.  As always, test everything even if clear as day

Thanks but the problem now becomes that, since the AG has multiple applications and all "had" the same expiration date for the indexes, I now have a "mix" (e.g. some 90-days some 1-yr) so updating the Exire in # days to 1-year would keep around the 90-day indexes but with no data.

[scottnys]

When we use the "expire in xxxx days" we store all reports in a "forever" OAM.  That way full control is within CMOD.  When we let OAM expire the reports, we change the Expiration Type to "Storage manager" and "life of Data and Indexes" to NEVER EXPIRE. there is an OAM Delete Trigger for DB2 that inserts an entry for CMOD to delete the Index Data Records using the ARSMAINT job (Doesn't help after the fact, however)

[rjchavez]

When we use the "expire in xxxx days" we store all reports in a "forever" OAM.  That way full control is within CMOD.  When we let OAM expire the reports, we change the Expiration Type to "Storage manager" and "life of Data and Indexes" to NEVER EXPIRE. there is an OAM Delete Trigger for DB2 that inserts an entry for CMOD to delete the Index Data Records using the ARSMAINT job (Doesn't help after the fact, however)

That would make sense.  Unfortunately all of our AGs have Expiration Type of Load and Expire in ## days specified.  And there's no way to update the Expiration Type without extracting/reloading the documents into a new AG.  This is becoming more and more of an undoable task -- at least for us(me).  It would seem that my solution is the same that I established some time ago -- unload/reload documents from one AG to another (no update in place here).

[rjchavez]

So when using Expiration Type of "Storage Manager" on z/OS CMOD, you must either use the ARSEXPIR or ARSEXOAM utility to expire indexes.  One uses SMF data the other uses some sort of DB2 table.  Not familiar with either of these.  Can anyone elaborate on the benefits if any? 

[Greg Ira]

ARSEXOAM keeps OAM and your CMOD tables in sync when you have expire by storage manager.  e.g. If you load into an OAM table that expires objects after 1 year when that object is expired by OAM it places an entry, via DB2 trigger, into an OAM_DELETE table.  ARSEXOAM processes that table to clean out any related entries in your ARS tables.