Hmmmm, There could be many potential situations to explain this, but two that spring readily to mind are documented in the DFSMSrmm manuals, as per:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2R320/6.3? SHELF=DGT2BK31&DT=20031211125737& If you use the parmlib member EDGRMMxx OPTION VRSEL(OLD) operand, you can chain vital record specifications as follows: 6.3.1 What You Can Chain When You Specify VRSEL(OLD) * Data set vital record specifications contain the retention information for the data set. * Any name vital record specification chained to the data set vital record specification can only contain movement information. * Both data set vital record specification and name vital record specifications can contain movement information. * Vital record specifications are chained using NEXT. * Release options are not supported but can be defined. Setting the parmlib member EDGRMMxx OPTION VRSEL(NEW) operand, you can specify vital record specifications as follows: 6.3.2 What You Can Chain When You Specify VRSEL(NEW) * Both data set vital record specifications and name vital record specifications can contain retention information. * The name vital record specification can use any retention type. * Both data set vital record specification and name vital record specification can contain movement information. * Vital record specification chains are made by using the NEXTVRS operand or the ANDVRS operand. * Release options are fully supported. **** Basically this is all about Boolean logic and you need to consider what your overall or individual VRS policy should be, for each and every rule. As with most things, generally the 80/20 notion applies; hopefully the 80 is the norm and the 20 is the exception. **** Secondly you may want to consider the chaining commentary contained here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2R320/6.6.4? SHELF=DGT2BK31&DT=20031211125737 Retain 3 cycles of the data set that matches the data set name mask. Retain each additional cycle of the data set for at least 3 days. Retain the latest cycle in the home location, the next cycle in storage location REMOTE, and the remaining cycles in the home location. RMM ADDVRS DSN('WK.**') CYCLES - COUNT(1) - LOCATION(HOME) NEXTVRS(REMC1) RMM ADDVRS NAME(REMC1) CYCLES - COUNT(1) - LOCATION(REMOTE) NEXTVRS(HOMC1) RMM ADDVRS NAME(HOMC1) CYCLES - COUNT(1) - LOCATION(HOME) NEXTVRS(DAYS3) RMM ADDVRS NAME(DAYS3) DAYS - COUNT(3) - LOCATION(HOME) **** With DFSMSrmm it is prudent to be explicit and define the cycle you require without any presumptions. Ultimately I feel this is a good thing as this translates to Plain English, which ultimately is what policies should be, defining a business requirement explicitly ****. Disclaimer: Of course if you have recently converted from another Tape Management Subsystem (TMS), then part of the DFSMSrmm conversion process will assign the tape volume (VOLSER) from the existing TMS location (vault) to the DFSMSrmm location (LOCDEF) and only do this once; so only newly created or updated volumes will benefit from movement actions via the DFSMSrmm EDGHSKP VRSEL, DSTORE and EXPROC processing. HTH, MWM. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
