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


Scratching of rolled-off generation data sets

z/OS DFSMShsm Implementation and Customization Guide
SC23-6869-01

Scratching of rolled-off generation data sets is performed by DFSMSdfp and DFSMShsm. The generation data set SCRATCH or NOSCRATCH option and the existence of an expiration date control whether DFSMSdfp and DFSMShsm can scratch rolled-off members:
  • If you want to scratch rolled-off members of GDGs with DFSMSdfp and DFSMShsm, define your GDGs with the SCRATCH option.
    • DFP scratches nonmigrated generations when they roll off.
    • DFSMShsm scratches migrated generations when they roll off if no expiration date exists for the data set.
    • DFSMShsm scratches migrated generations as they roll off if they have an expiration date and if that expiration date has passed. If migrated generations roll off and their expiration date has not passed, the generations are deleted as a part of migration cleanup after the expiration date has passed. For performance reasons, the expiration date should come after the date that you expect the generation to roll off. If the data set has expired but not rolled off, extra catalog processing is required each time migration cleanup runs until that data set rolls off.
  • If you do not want to scratch rolled-off members of GDGs at all, define the GDGs with the NOSCRATCH option and do not specify expiration dates for the generations.
    • DFP does not scratch nonmigrated rolled-off generations because of the NOSCRATCH option.
    • DFSMShsm does not scratch the migrated rolled-off generations because it is not notified that they are to be scratched and because they never expire.
  • If you want to scratch rolled-off members of GDGs when they are defined with the NOSCRATCH option, you need to specify expiration dates for the generations.

    DFSMShsm scratches migrated rolled-off generations during migration cleanup if the data set has an expired expiration date, even if you specify the NOSCRATCH option. For performance reasons, the expiration date should come after the date that you expect the generation to roll off. If the data set has expired but has not rolled off, extra catalog processing is required each time migration cleanup runs until the data set rolls off.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014