Process each data set record in the BCDS

For each data set record in the BCDS, DFSMShsm performs the following processing:

It determines if the version is a retired version. See Data set retirement for a description of "delete if backed up". If the version is a retired version, DFSMShsm knows that it is not an SMS-managed data set and processes it according to rules for processing non-SMS-managed data sets. EXPIREBV processing for non-SMS-managed data sets is described in Availability management of non-SMS-managed storage.
If the version is not a retired version, DFSMShsm continues processing.
It determines if the data set exists and is SMS-managed.
For each data set that does not have a retired version and does not indicate that all backup versions are for an uncataloged data set and that does not have a scratch date recorded by prior EXPIREBV processing, DFSMShsm determines the names of the storage class, management class, and data class for the data set.

If a catalog entry exists for the data set, the data set has not been scratched.

If the data set is not cataloged and the MCB record does not contain a scratch date, DFSMShsm assumes that the data set has been scratched, and it records the current date in the scratch date field of the MCB record in the BCDS. DFSMShsm resets an existing scratch date to the current date if the date of the most recent backup version is the same or later than the existing scratch date. Because DFSMShsm cannot be sure, it assumes that the old scratch date is invalid. This is because the data set may have been recreated and backed up after prior EXPIREBV processing found that the data set had been scratched. This creates the possibility that more then one EXPIREBV command will need to be run to remove the backup versions, but it also prevents DFSMShsm from deleting valid backup versions. The scratch date is stored when either DISPLAY or EXECUTE is specified on the EXPIREBV command.

DFSMShsm then checks the MCB record to determine if the data set was SMS-managed when it was last backed up. If the data set was SMS-managed when it was backed up, DFSMShsm processes all of its cataloged backup versions as described here. If it was not SMS-managed, DFSMShsm processes it as described in Processing for expired backup versions of non-SMS-managed data sets.

If any error occurs, other than being unable to find the data set, DFSMShsm assumes that the data set still exists and processes only the uncataloged versions of the data set as described in Processing for expired backup versions of non-SMS-managed data sets.

If the MCB record already contains a scratch date, DFSMShsm assumes that the data set has been scratched and determines from the MCB if the data set was SMS-managed when it was last backed up.
It identifies expired backup versions.
Each SMS-managed data set’s backup versions are processed based on the RETAINDAYS value and the attributes specified in the management class associated with the data set (or in the default management class if the data set is not associated with a management class). If a management class name is found but there is no definition for the management class, DFSMShsm issues a message and does not process the cataloged backup versions of that data set.

After the management class has been established, processing depends on whether the data set exists:
- If the data set exists, the management class used is the one associated with the existing data set.
  1. DFSMShsm compares the number of backup versions that exist with the value of the NUMBER OF BACKUPS (DATA SET EXISTS) attribute in the management class. If there are more versions than requested, the excess versions are deleted if the versions do not have a RETAINDAYS value or the RETAINDAYS value has been met, starting with the oldest. The excess versions are kept as excess active versions if they have an un-met RETAINDAYS value. These excess versions will then be changed to retained backup versions when a new version is created.
  2. Starting with the now-oldest backup version and ending with the third-newest version, DFSMShsm calculates the age of the version to determine if the version should be expired. If a RETAINDAYS value was specified when the version was created, then the age is compared to the retain days value. If RETAINDAYS was not specified, then the age is compared to the value of the RETAIN DAYS EXTRA BACKUPS attribute in the management class. If the age of the version meets the expiration criteria, then the version is expired.
    The second-newest version is treated as if it had been created on the same day as the newest backup version. Therefore, the second-newest version (newest EXTRA backup copy) is not expired until the number of retention days specified by the RETAINDAYS value or the number of days specified in RETAIN DAYS EXTRA BACKUPS attribute in the management class have passed since the creation of the newest backup version. (The management class value is only used if RETAINDAYS was not specified for the version).
    
    If only one backup version exists for the data set, it is not deleted by the EXPIREBV.
- If the data set is deleted, the management class used is the one (if any) that was associated with the data set when the last backup version was made.
  If this is the first time EXPIREBV has found this data set to be deleted:
  1. DFSMShsm compares the number of backup versions that exist with the value of the NUMBER OF BACKUPS (DATA SET DELETED) attribute in the management class. If there are more versions than requested, the excess versions are deleted if the versions do not have a RETAINDAYS value or the RETAINDAYS value has been met, starting with the oldest. The excess versions are kept as excess active versions if they have an unmet RETAINDAYS value. These excess versions will then be changed to retained backup versions when a new version is created.
  2. Starting with the now-oldest backup version and ending with the third-newest version, DFSMShsm calculates the age of each cataloged version to determine if the version should be expired. If a RETAINDAYS value was specified when the version was created, then the age is compared to the retain days value. If RETAINDAYS was not specified, then the age is compared to the value of the RETAIN DAYS EXTRA BACKUPS attribute in the management class. If the age of the version meets the expiration criteria, then the version is deleted.
    The second-newest version is treated as if it had been created on the same day as the newest backup version. Therefore, the second-newest version (newest EXTRA backup copy) will not be expired until the retention days specified by the RETAINDAYS value or the number of days specified in RETAIN DAYS EXTRA BACKUPS attribute have passed since the creation of the newest backup version. (The management class value is only used if RETAINDAYS was not specified for the version).
  If the scratch date has been set by prior EXPIREBV processing:
  1. DFSMShsm compares the number of backup versions to the value of the NUMBER OF BACKUPS (DATA SET DELETED) attribute in the management class. If there are more versions than requested, the excess versions are deleted if the versions do not have a RETAINDAYS value or the RETAINDAYS value has been met, starting with the oldest. The excess versions are kept as excess active versions if they have an unmet RETAINDAYS value. These excess versions will then be changed to retained backup versions when a new version is created.
  2. Starting with the now-oldest backup version and ending with the third-newest version, DFSMShsm calculates the age of each cataloged version to determine if the version should be expired. If a RETAINDAYS value was specified when the version was created, then the age is compared to the retain days value. If RETAINDAYS was not specified, then the age is compared to the value of the RETAIN DAYS EXTRA BACKUPS attribute in the management class. If the age of the version meets the expiration criteria, then the version is deleted.
    The second-newest version is treated as if it had been created on the same day as the newest backup version. Therefore, the second-newest version (newest EXTRA backup copy) will not be expired until the retention days specified by the RETAINDAYS value or the number of days specified in RETAIN DAYS EXTRA BACKUPS attribute have passed since the creation of the newest backup version. (The management class value is used only if RETAINDAYS was not specified for the version).
  3. If the RETAIN DAYS EXTRA BACKUP attribute is NOLIMIT and the RETAIN DAYS ONLY BACKUP attribute is other than NOLIMIT, DFSMShsm calculates the difference between the current date and the scratch date, then compares the result to the value of the RETAIN DAYS ONLY BACKUP (DATA SET DELETED) attribute. If the difference between the current date and the scratch date is greater than the specified value for the attribute, DFSMShsm deletes all of the remaining backup versions that do not have an unmet RETAINDAYS value.
  4. If all of the extra backups are deleted, DFSMShsm calculates the difference between the current date and the scratch date and compares the result to the value of the RETAIN DAYS ONLY BACKUP (DATA SET DELETED) attribute. If the difference between the current date and the scratch date is greater than the specified value for the attribute, DFSMShsm deletes the single remaining backup version if it does not have an unmet RETAINDAYS value.
It determines the disposition of the MCB record and the MCBR record.
If you specified the EXECUTE parameter in the EXPIREBV command, DFSMShsm can change the MCB record in the BCDS as follows:
- If all backup versions are being deleted or no backup version existed when the EXPIREBV command first read the MCB record, DFSMShsm deletes the MCB record (only for SMS-managed data sets).
- DFSMShsm updates the MCB record if either of the following is true:
  - The scratch date field has been changed.
  - One or more backup versions, but not all versions, are being deleted
  If all active copies have been deleted and there are one or more retained copies, then the most recent retained copy will be moved from the MCBR record to the MCB record so that the MCB record has at least one valid backup version.
If you specified the EXECUTE parameter in the EXPIREBV command, DFSMShsm can change or delete the MCBR record in the BCDS as follows:
- If all backup versions are being deleted or no backup version existed when the EXPIREBV command first read the MCBR record, DFSMShsm deletes the MCBR record.
- DFSMShsm updates the MCBR record for the following:
  - One or more backup versions, but not all versions, are being deleted
  - A version is moved from the MCBR record to the MCB record.
If you specified the DISPLAY parameter for EXPIREBV, DFSMShsm updates the MCB record only if the scratch date field has been changed (updates only that field in the record).
It deletes the eligible backup versions.
If you specified the EXECUTE parameter in the EXPIREBV command, DFSMShsm deletes a backup version as follows:
- If the backup version resides on an ML1 volume, the version is scratched (with the appropriate erase-on-scratch indication) and the MCM and MCC records are deleted. In addition, if a discrete backup profile is associated with a deleted version, the profile is also deleted.
- If the backup version resides on a non-removable DASD backup volume, the version is scratched (with the appropriate erase-on-scratch indication), and the MCC record is deleted. In addition, if a discrete backup profile is associated with a deleted version, the profile is also deleted.
- If the backup version resides on a removable DASD volume, the backup version is invalidated at this time, but it is not scratched until the backup volume is selected for spill or cleanup processing. If the erase option is in effect for the version, the MCC record is updated to reflect that the data set should be erased when it is scratched. If the erase option is not in effect for the version, the MCC record is deleted.
- If the backup version resides on a tape backup volume, the MCC record is deleted and the TTOC entry for the data set is invalidated.
It reports on the eligibility of backup versions.
If the DISPLAY parameter was specified in the EXPIREBV command, DFSMShsm creates an output line for every backup version that is eligible to be deleted. The expired retained backup versions are appended to the end of active backup versions. The difference in the output data set between the active backup versions and the retained backup version is that the generation number of retained backup version is displayed as "***" rather than generation number.
If the EXPIREBV command specified EXECUTE, DFSMShsm sends ARC0734I messages to the backup activity log under control of the SETSYS ACTLOGMSGLVL value:
- FULL specifies that an ARC0734I message is sent for each backup version for which deletion is attempted, whether deletion is successful or not.
- EXCEPTIONONLY specifies that an ARC0734I message is sent only when a failure occurs in attempting to delete a backup version.
- REDUCED has the same effect as EXCEPTIONONLY.
If DFSMShsm is running in DEBUG mode when the EXPIREBV command is initiated, the output created is identical to the output when DFSMShsm is not in DEBUG mode, but no backup versions are deleted even if EXECUTE is specified.

Note: During the scan of the BCDS, backup versions associated with a data set name of “prefix.BACK” may be skipped and not expired. The prefix qualifier is set based on the BACKUPPREFIX parameter of the SETSYS command or the UID specified in the startup procedure. Because backup versions with high level qualifiers of “prefix.BACK” may not be expired and deleted, do not create data sets using this naming convention. Data sets not deleted during EXPIREBV processing are still eligible for deletion during rolloff of backup versions, or when a BDELETE or HBDELETE command is issued.