z/OS DFSMSrmm Implementation and Customization Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


How expiration processing works

z/OS DFSMSrmm Implementation and Customization Guide
SC23-6874-00

Expiration processing can be either on all volumes or a subset based on the EXPROC command in the SYSIN file. DFSMSrmm checks the expiration date for volumes not retained by a vital record specification and not held by the HOLD attribute. If the expiration date has been reached and the EXPDTDROP limit and action settings do not require the volume to be retained, DFSMSrmm changes the volume status to "pending release". DFSMSrmm checks for any actions that should be taken before the volume can be released. DFSMSrmm defers most release actions for later processing. However, DFSMSrmm processes the "notify owner" release action immediately if an electronic address is provided for the owner and the DFSMSrmm system option NOTIFY is in use. If the volume has the retention method EXPDT and there are no outstanding actions then DFSMSrmm tries to release the volume in the same run.

You can use parmlib option EXPDTDROP to control the results of expiration processing. EXPDTDROP specifies a limit on the number of expiring volumes to be processed and on the action to be taken when the limit is reached. If the EXPDTDROP limit has been reached and the action is FAIL, then the volume status is not changed. Otherwise, if the INFO or WARN action is specified, DFSMSrmm changes the volume status to ‘pending release’ and the appropriate message is issued.

When a data set is no longer retained by a vital record specification, DFSMSrmm releases the volume on which the data set resides only if no data set on the volume is retained by a vital record specification and the volume is not held by the HOLD attribute. If you use the RMM ADDVRS RELEASE(EXPIRYDATEIGNORE) operand, DFSMSrmm ignores the volume expiration date and uses information in a vital record specification to control retention.

If the volume has the EXPDT retention method, expiration processing always attempts to return volumes to scratch on the same run as the volume is released. This is as if the SCRATCHIMMEDIATE attribute is set for the volume with the VRSEL retention method.

If the volume is retained by the VRSEL retention method, DFSMSrmm does not immediately return a volume to scratch status or to its owner when a volume reaches its expiration date and is not retained by a vital record specification. You must run expiration processing two times to return a volume to scratch status or to its owner. The first run of expiration processing sets the volume status to pending release. The second run of expiration processing completes the return. DFSMSrmm does not change the volume status during the first run of expiration processing. DFSMSrmm marks the volume as pending release during the first run of expiration processing in case you want to reclaim the volume. Running expiration processing two times give you time to make changes to the volume status before the volume is released.

To reclaim from pending release and set the hold attribute for the volume, issue the subcommand RMM CV volser RETPD(1) HOLD. To reclaim from scratch status and set the hold attribute for the volume, issue the subcommand RMM CV volser STATUS(MASTER) RETPD(1) HOLD. Authorization requires either CONTROL access to STGADMIN.EDG.MASTER, or UPDATE access to STGADMIN.EDG.CV.HOLD.volser.

If the volume is retained by the VRSEL retention method and you do not need to run expiration processing in two runs, specify the RMM ADDVRS RELEASE(SCRATCHIMMEDIATE) operand. This enables you to return volumes to scratch in a single run of expiration processing. Sometimes DFSMSrmm cannot make the return in a single run, for example there could be other release actions required. Also, when all catalogs are not fully shared or when TCDBs for partitioned tape libraries are not shared, you might need to run expiration processing more than one time to return volumes to scratch status.

See Confirming global volume movement for information about the global move confirmation processing that takes place during vital record processing.

If you retain volumes by set, DFSMSrmm retains all the volumes in the set if any volume in the set is retained. DFSMSrmm sets the retention date for all the volumes in the set to the highest retention date for the volumes in the set. See Defining system options: OPTION for information about implementing volume retention by set by using the DFSMSrmm EDGRMMxx parmlib OPTION command RETAINBY(SET) operand.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014