Before automatic secondary space management starts migration cleanup, it determines if there is any migration cleanup task running in another DFSMShsm host. If there is, the migration cleanup will not be performed on this DFSMShsm host. This avoids any unexpected results that might be created by running two migration cleanup tasks against the same MCDS at the same time.
When migration cleanup starts, it checks to see if any internal TAPECOPY processing is needed, and if so, schedules the internal TAPECOPY MWEs. Internal TAPECOPY processing could be needed because of duplexing errors or ABARS recovery of ML2 volumes.
- Expired migrated data sets. Migration cleanup deletes the data
sets if:
- For both SMS-managed and non-SMS-managed data sets, the data set has passed the expiration date indicated in the data set's VTOC entry and the EXPIREDDATASETS(SCRATCH) parameter is specified in the SETSYS command.
- For SMS-managed data sets, the data set does not have an expiration date but has passed the expiration attributes specified in the management class to which it is associated.
- For an SMS-managed NOSCRATCH GDS, the data set rolled off while on a level 0 volume and migrated, with rolled off GDG=EXPIRE in the management class and no expiration date in the VTOC.
See Specifying expiration attributes and Specifying how to scratch expired data sets for details on SMS-managed data sets.
- Migration copies of the data sets recalled from SDSP data sets.
Because multiple recall tasks can access the small data set packing
data sets concurrently, recall does not erase the migration copy.
Even though SDSP data sets used during migration cleanup are periodically released when not in use, and SDSP data sets needed by recall or aggregate backup are released when needed, it is recommended that you do not run secondary space management when automatic primary space management is running in order to avoid contention for SDSP data sets.
Every 30 seconds, migration cleanup checks to determine if recall or aggregate backup needs an SDSP data set. The value 30 is stored in the MCVT#CHK field and can be patched to any other desired value.
- MCDS data set (MCD) records for nonreconnectable data sets that are older than the number of days that are specified by the recalldays value of the SETSYS MIGRATIONCLEANUPDAYS command.
- MCDS data set (MCD) records for reconnectable data sets that have passed their predicted remigration date by the number of days that are specified by the reconnectdays value of the SETSYS MIGRATIONCLEANUPDAYS command. This occurs only if the recalldays criterion is also met.
- Daily statistics records and volume statistics records that are older than the number of days specified by the statdays value from the SETSYS MIGRATIONCLEANUPDAYS command.
- Migration copies not scratched during recall, deletion, or GDG roll-off of non-SMS-managed migrated data sets. These copies exist if an error occurred during recall or deletion, or if a generation data set had not passed its expiration date when the roll-off occurred.
Migration cleanup example
Figure 1 shows an example of SMS-managed volumes after migration cleanup has occurred for the conditions shown in Figure 1. Data set STANDMC.ML.F2 is deleted from the ML1 volumes because it has passed the EXPIRE AFTER DAYS NON-USAGE and EXPIRE AFTER DATE/DAYS values from management class STANDMC. Data set LARGEMC.ML.G1 is deleted from the ML2 tapes because it has passed the EXPIRE AFTER DAYS NON-USAGE and the EXPIRE AFTER DATE/DAYS values from the management class LARGEMC.
