You define vital record specifications to set retention policies for data sets or volumes managed by the VRSEL retention method, and data set on these volumes that are not excluded from VRSEL processing. Data set vital record specifications apply to the volume on which the data set resides. Volume vital record specifications assume nothing about data sets on the volume.

The retention period in a vital record specification overrides the expiration date set for a data set or volume and can extend or reduce the time a data set or volume is retained. You can set retention policies for data sets and volumes using the RMM ADDVRS subcommand or the DFSMSrmm ISPF dialog. You can define a vital record specification to cover a single data set and volume or use data set name masks and generic volume serial numbers to define vital record specifications to cover multiple data sets and volumes.

The expiration dates 1999/365 and 1999/366 mean "never-scratch" dates when you specify the DFSMSrmm EDGRMMxx parmlib OPTION command with the MAXRETPD(NOLIMIT) operand. Using these dates in your JCL does not prevent DFSMSrmm from allowing a volume to be expired, returned to scratch status, or written over.

To manage volumes by using these expiration dates to mean permanent retention, you must ensure that DFSMSrmm processing does not override the "never-scratch" dates. Here are some examples where DFSMSrmm processing ignores the expiration date. For example, use the EXPIRYDATEIGNORE operand in any vital record specification and DFSMSrmm ignores expiration dates, even "never-scratch" dates. Also when you issue the DELETEVOLUME subcommand with the RELEASE operand, you are requesting that DFSMSrmm release the volume no matter what the expiration date is. Note also that DFSMSrmm does not consider the expiration date when determining if a file can be overwritten. DFSMSrmm looks at the parmlib OPTION MASTEROVERWRITE operand and parmlib VLPOOL EXPDTCHECK operand to determine if a file can be overwritten.