Author Topic: What is the best way to change retetion for Appgrp on OAM storage set  (Read 4474 times)

SV

  • Guest
Working on retention change ( say 2 year to 3 year ) for an AppGrp that is on an OAM storage set. Found out there are more AppGrps on the same OAM storage set, which does not need retention change. What is the best way to change the retention for this 1 APpgrp?

200 MM Docs are on the Ap0Ggrp that require retention change. CMOD 9.0 on Z.OS. OAM is using DASD.
« Last Edit: July 08, 2015, 08:09:40 AM by SV »

rjchavez

  • Jr. Member
  • **
  • Posts: 67
    • View Profile
We're on CMOD 8.5.0.6 using OAM and the only way we have been able to change the retention of "already loaded" reports, is to offload them and re-load them assigning the new storage node with the new retention period.  Here are the steps we use:

1)   Create a new application group and associated with the new storage node (retention). 
2)   Create the new application and associate it with the new application group.
3)   Update the folder (or create a new one) and associate it with the new application group.
4)   Run the arsdoc command above to export the reports.
5)   Run the arsload command above to import the reports into the new application group.

Not sure if there's an "easier" way to do it in CMOD 9+.

rjchavez

  • Jr. Member
  • **
  • Posts: 67
    • View Profile
We also checked with OAM L2 and here's what they said regarding the retention:

"If the COLLECTION exists, and specifies a Management Class, the ACS routines will NOT be driven to determine the new MC. Therefore the COLLECTION needs to be deleted, and redefined into the catalog. On the first retrieve or store to this collection, it will then have its SMS constructs updated according to your ACS routines.

After this then other new objects will also be assigned the new MC. As for existing objects, OSMC needs to be re-driven to update the object directory with the correct dates according to the new MC. In order for this to happen, the ODPENDDT column needs to be changed to the current or earlier date. The simplest way to do this would be to use the OSREQ macro to change the MC for the objects.       

Everything else will take care of itself later when OSMC next runs for this object (since the OSREQ will also cause the ODPENDDT to change to the current date).                                                     
                                                                       
If you want to make the changes through OnDemand (as opposed to using the strictly OAM process outlined above) then it would be a matter of unloading/reloading the data."

leodejong

  • Jr. Member
  • **
  • Posts: 24
    • View Profile
Re: What is the best way to change retetion for Appgrp on OAM storage set
« Reply #3 on: September 08, 2015, 08:39:59 AM »
Hi
What we have done is write a little Rexx to generate a buch of OSREQ TSO commands.
The format is.
OSREQ CHANGE collection objectname RETENTIONPERIOD(rp)
In the Rexx you have to generate the objectnames from the directory tables and to get the retention period you have to do a lot calculation with the date.
No need to unload/ reload
Leo
Leo de Jong, Rabobank,The Netherlands

SV

  • Guest
Re: What is the best way to change retetion for Appgrp on OAM storage set
« Reply #4 on: September 08, 2015, 11:31:07 AM »
Hello Leo, thanks for pitching in; I am not an OAM expert; So can you elaborate this expiration change process by adding bit more detail.

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1208
    • View Profile
Re: What is the best way to change retetion for Appgrp on OAM storage set
« Reply #5 on: September 10, 2015, 09:29:38 AM »
Hello Saravanan!  and Robert and Leo!

The OAM IVP contains an example of changing a retention period.

Example and discussion can be located here:

http://www.odusergroup.org/forums/index.php?topic=887.0

Ed
#zOS #ODF

scottnys

  • Guest
Re: What is the best way to change retetion for Appgrp on OAM storage set
« Reply #6 on: April 15, 2016, 08:06:07 AM »
I wanted to through my two cents into this, realizing it's not recent.  We have the same issue from time to time.  We started by "reloading" the report into a different OAM with the desired retention.  With LINE data that would work.  With AFP docs, not so much.  In investigating OAM some more, we found to options (leaving the currently loaded reports where they are).
1) There are columns in OAM that, when given a value, will override the original definition of that OAM.  What I did was to assign the "ODEXPDT" column a date and extend it's retention.  This works great for keeping the report in place.  You would then change the storage set to point future loads to another OAM.

000800 //*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
000810 //*   IN CASES WHERE THE USER REALIZES THAT THE RETENTION IS NOT     %%%
000811 //*  LONG ENOUGH AFTER A SERIES OF LOADS HAS ALREADY HAPPENED,       %%%
000812 //*  THERE IS A SOLUTION.                                            %%%
000813 //*   THE WAY OAM IS CONFIGURED, THE EXPIRE PROCESS "CHECKS" WITH    %%%
000814 //*  THE MANAGEMENT CLASS FOR EXPIRATION.  THIS IS "TRUMPED" IF      %%%
000815 //*  THE (ODEXPDT) COLUMN IS OTHER THAN THE DEFAULT.                 %%%
000816 //*                                                                  %%%
000817 //*  THE JOB:"OSREQHLD" WILL PUT A PERMINENT HOLD UNTIL IT IS        %%%
000818 //*          RELEASED.                                               %%%
000820 //*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
000830 //**                                                                   
000840 //   INCLUDE MEMBER=GOTO32PC                                           
000850 //**                                                                   
000860 //UPDIXTBL EXEC PGM=IKJEFT01,COND=(4,LT),DYNAMNBR=20                   
000870 //STEPLIB  DD DISP=SHR,DSN=ONDDODP.V10.SDSNLOAD                         
000880 //SYSTSPRT  DD SYSOUT=(,)                                               
000890 //SYSOUT    DD SYSOUT=(,)                                               
000900 //SYSTSIN   DD *                                                       
001000  DSN SYSTEM(DODP)                                                       
001100  RUN PROGRAM(DSNTIAD) PLAN(DSNTIA10) -                                 
001200   LIB('ONDDODP.V10.RUNLIB.LOAD')                                       
001300 //SYSDUMP   DD SYSOUT=*                                                 
001400 //SYSPRINT  DD SYSOUT=(,)                                               
001500 //SYSIN     DD *                                                       
001600    UPDATE OBDNNXXX.OSM_OBJ_DIR                                         
001700      SET                                                               
001900           ODEXPDT  = ODMCASDT + 5 YEARS                                 
002000    WHERE ODNAME LIKE 'PWB.L1825.%';                                     
002100                 


2) the second option is more "open ended"    This option would tell OAM to leave it alone until the "HOLD" was released.  This option is better for "lets just pause until we can figure it out" thing.

********************************* Top of Data ****************************
//OSREQHLD JOB  (OSRQ,C313),IRA.SYSTEMS,MSGCLASS=X,CLASS=S,               
//         NOTIFY=&SYSUID                                                 
//*********************************************************************   
//*            DSYS.OLTP.PROD.JCL(OSREQHLD)                           *   
//*  PLACE/REMOVE EXPIRATION HOLD ON AN OAM OBJECT                    *   
//*                                                                   *   
//*                                                                   *   
//* OSREQ CHANGE <COLLECTION NAME> <OBJECT> DELHOLD( )                *   
//*                                                                   *   
//* DELHOLD(HOLD) PLACES INDEFINATE HOLD ON OAM EXPIRATION FOR OBJECT *   
//* DELHOLD(NOHOLD) REMOVES OAM HOLD.                                 *   
//*                                                                   *   
//* COLLECTION NAME CAN BE VERIFIED BY CHECKING THE FOLLOWINT TABLE   *   
//*                 OAMADMIN.CBR_COLLECTION_TBL                       *   
//*  OBJECT IS ODNAME FROM OBDXXXXX.OSM_OBJ_DIR                       *   
//*  SEE CSYD01.SPUFI.INPUT(CROAMHLD) FOR SPUFI CREATE OF COMMAND     *   
//*                                                                   *   
//*  CHANGE ACTIVITY:                                                 *   
//*********************************************************************   
//STEP1    EXEC PGM=IKJEFT01,REGION=4096K                                 
//STEPLIB  DD DSN=ONDDODP.V10.SDSNEXIT,DISP=SHR                           
//         DD DSN=ONDDODP.V10.SDSNLOAD,DISP=SHR                           
//SYSPRINT DD   SYSOUT=*                                                 
//SYSTSPRT DD   SYSOUT=*                                                 
//SYSTSIN  DD   *                                                         
 OSREQ CHANGE OND.COLL.M1TEST.SGD03M1T.MCDM01 GAA.L4.FAAA DELHOLD(NOHOLD)
 OSREQ CHANGE OND.COLL.M1TEST.SGD03M1T.MCDM01 GAA.L4.FAA1 DELHOLD(NOHOLD)
/*                                                                       
//*