Handling of generation data sets

If each generation of a non-SMS-managed generation data group is on a volume managed by DFSMShsm, each generation is, with some exceptions, managed the same as any other data set.
Note: SMS-managed data sets are managed according to the management class to which they are assigned.

You cannot specify a relative generation data group generation (+ 1) on a command. You can only specify the full generation data group generation (for example, G0011V01).

Because all generation data group data sets have Gnnnn Vnn as their last qualifiers, the next to the last qualifier is an indicator of the type of data set being processed. Therefore, when DFSMShsm searches the compaction names tables to determine which encode or decode tables to use, DFSMShsm uses the next to the last qualifier of the data set name to search the compaction names table if the data set is a generation data group data set.

Each generation of a generation data group appears to DFSMShsm as a unique data set. There is no correlation from one generation of a generation data group to another. As a result, you might want to control the number of generations to be kept for a user. For example, if a user is allowed five generations and you have defined five backup versions with the VERSIONS parameter of the SETSYS or ALTERDS commands, the user can have as many as 25 (five versions multiplied by five generations) backup versions of the same generation data group if each generation has been updated five times.

If a generation is created that exceeds the limit of generations to be kept, the oldest generation is deleted at the end of the step or job, unless the oldest generation is protected by:
  • A password
  • An expiration date that has not yet passed
  • RACF® (when the user is not authorized to scratch the generation)
In these cases, the oldest generation is not scratched.

If the oldest generation is deleted or uncataloged, the delete operation scratches the oldest generation without recalling it.