OnDemand User Group
Support Forums => z/OS Server => Topic started by: rjchavez on March 27, 2020, 07:34:20 AM
-
There have been topics on updating the retetion in-place for OAM objects before. I was part of one thread a few years back. I understand that I can update the retention period of an OAM object without reload but, the issue/challenge I'm having is "How to correlate a loaded report to an OAM object?" I've been looking at the columns in the OAM tables and ARSAG, ARSSEG tables but can't figure out how to tie back the Appliation Group stuff to OAM stored objects.
Any ideas would be appreciated.
-
What I've been able to assertain so far is that the ARSAG.AGID_NAME column is unique for each of the Application Groups. This ties back to the OSM_OBJ_DIR.ODNAME (OAM) column, at least partially.
-
I tried to provide a bit more detail on the relationship of oam document store. I've attached a PDF with examples. Hope this helps.
-
Excellent job on your document Scott! It's interesting to see how this is slightly different from the multiplatforms world. :)
-JD.
-
I tried to provide a bit more detail on the relationship of oam document store. I've attached a PDF with examples. Hope this helps.
Thank you! It does confirm some of my research. My dilema is that we have AGs with multiple applications so changing the retention for an entire AG is not feasible. Often times we have requests to extend the retention for a specific application only. So we end-up extracting all documents and reloading them into a new AG with the desired application. I'm trying to see if I can change the retention on only certain set of documents.
-
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?
-
rjchavez...
It sounds like you could really use the Enhanced Retention Management (ERM) module for CMOD.
-JD.
-
Thanks. I though so too but in some high-level reading I thought ERM was only to place holds on documents and not necessarily expiration date(?) Is that not true?
-
With CMOD's ERM, you can create holds on specific documents, or set an implied hold at load time, and remove the holds from the documents that can be expired.
https://cmod.wiki/dox/CMODv10.1/EnhancedRetentionManagement.pdf
-JD.
-
It's been a couple of years since I had to do this. My comment in the JCL explains it.
THE WAY OAM IS CONFIGURED, THE EXPIRE PROCESS "CHECKS" WITH
THE MANAGEMENT CLASS FOR EXPIRATION. THIS IS "TRUMPED" IF
THE (ODEXPDT) COLUMN IS OTHER THAN THE DEFAULT.
-
Question: If I update the management class in the OAM object directory for the documents in question, would that effectively change it's retention?
-
No., I wouldn't recommend doing that. You'll confuse the heck out of OAM if you do. OAM has already stored your objects in matching 4K and/or 32K tables for that management class.
-
Ok, then why would the OSREQ CHANGE include the ability to update the MANAGEMENTCLASS?
-
I believe you are mis-interpreting the SYSIN card. This is not a "change" to a management class, but a fully qualified REFERENCE to the document in question. Remember they are paired.
OND.COLL.M1TEST.SGD03M1T.MCDM01 GAA.L4.FAAA <===
OND.COLL.M1TEST.SGD03M1T.MCDM01 GAA.L4.FAA1 <===
-
Hi Scott. I understand that your JCL is using the OSREQ CHANGE to remove or place a hold on an object. My question is, why not use the OSREQ CHANGE ... MANAGEMENTCLASS(xxxxx) to update the management class of the object to a different retention? The next time OSMC executes on the storage group, it would change the ODMCASDT date as per the retention period of the MC.
-
First of all, I agree with Greg (he's my supervisor ;D ) .
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.
-
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.
-
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
-
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.
-
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.
-
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?
-
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 :)
-
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.
-
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)
-
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).
-
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?
-
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.