Messages

16

z/OS Server / Re: OAM Object Name Reference

« on: April 07, 2020, 07:49:24 AM »

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.

17

z/OS Server / Re: OAM Object Name Reference

« on: April 07, 2020, 06:53:51 AM »

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?

18

z/OS Server / Re: OAM Object Name Reference

« on: April 07, 2020, 06:08:27 AM »

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.

19

z/OS Server / Re: OAM Object Name Reference

« on: April 06, 2020, 12:10:23 PM »

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.

20

z/OS Server / Re: OAM Object Name Reference

« on: April 06, 2020, 05:01:43 AM »

Ok, then why would the OSREQ CHANGE include the ability to update the MANAGEMENTCLASS?

21

z/OS Server / Re: OAM Object Name Reference

« on: April 03, 2020, 02:19:18 PM »

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

22

z/OS Server / Re: OAM Object Name Reference

« on: April 03, 2020, 09:33:02 AM »

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?

23

z/OS Server / Re: OAM Object Name Reference

« on: April 03, 2020, 07:57:26 AM »

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?

24

z/OS Server / Re: OAM Object Name Reference

« on: April 03, 2020, 07:05:57 AM »

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.

25

z/OS Server / Re: OAM Object Name Reference

« on: March 27, 2020, 08:55:21 AM »

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.

26

z/OS Server / OAM Object Name Reference

« 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.

27

z/OS Server / Re: ODF Customized e-mail Subject

« on: January 24, 2020, 06:23:45 AM »

Nice to see others are using that functionality.  That APAR was ours.  We changed Java from 7 to 8, being that it was being unsupported.  The "recipient" check was not getting hit any longer.  Glad we could expedite your implementation.  We waited 4+ months for the fix.

Thanks for the reply.  Questions:  I take it that you are running with the ++APAR and all is OK?  How long have you been running with it?  Production?

28

z/OS Server / Re: ODF Customized e-mail Subject

« on: January 17, 2020, 01:51:03 PM »

I tested using JAVA V7 and it fixed the problem.  I also installed the ++APAR and tested with JAVA V8 successfully.

29

z/OS Server / Re: ODF Customized e-mail Subject

« on: January 17, 2020, 09:38:53 AM »

Here's IBM response:

"There is an unreleased APAR for CMOD V10.1:

PH17448 ARSODF.XML EMAIL CUSTOMIZATION NOT WORKING FOR JAVA 8

The workaround is to point to JAVA 7."

I've tested it with JAVA 7 and it works.  I'm also requesting the ++APAR to test with V8.

30

z/OS Server / Re: ODF Customized e-mail Subject

« on: January 17, 2020, 09:27:00 AM »

Hello all,
We're in need to customize the Subject line for "specific" recipient only.  The arsodf.xml comments seems to suggest that you can do this by using the <Recipient> tag under the <EmailAttachmentNotify> section.  It's not clear wether the <Name> tag should specify the RECIPIENT or RECIPIENT LIST or does it matter.  I've tried everything including the actual e-mail address in the <Name> tag under <Recipient> to no avail.  The only thing that seems to work is the "default" Subject immediately following <EmailAttachmentNotify>.

Any ideas?

I've opened a PMR/CASE