Backing up cataloged and uncataloged data sets with the same name

Although DFSMShsm and DFSMSdss do not migrate uncataloged data sets, DFSMShsm can back them up, either automatically or by command. Therefore, DFSMShsm can back up several different uncataloged data sets that have the same data set name but reside on different volumes. Depending on the record length that is used to define the BCDS, DFSMShsm can maintain up to 29, or up to 100, backup versions for any specific data set name. After the number of backup versions reaches that limit, backup versions of cataloged data sets take precedence over backup versions of uncataloged data sets of the same name. When DFSMShsm backs up the data set again, DFSMShsm deletes the backup version of an uncataloged data set first. In the case of data sets that are indirectly cataloged to SYSRES, those on the inactive SYSRES pack are considered uncataloged by backup processing, but are considered cataloged if backed up while running backup from their own system. For this reason, they cannot be protected by incremental backup. The results of a recover command are unpredictable due to the mixture of indirectly cataloged and uncataloged data sets with the same name.

To avoid potential confusion, do not give cataloged and uncataloged data sets the same data set name.

DFSMShsm keeps backup versions of a data set name in the following order:

All backup versions of a cataloged data set, arranged by date. The most recently created backup version is first. The number of backup versions DFSMShsm keeps is the limit of versions that existed the last time DFSMShsm backed up the data set.
All backup versions of all uncataloged data sets having the same name, arranged by date. The most recently created backup version is first. The number of backup versions DFSMShsm keeps is the limit of versions that existed the last time DFSMShsm backed up the data set.

Although the limit specified by the VERSIONS parameter of the SETSYS command applies to cataloged and uncataloged data sets separately, the maximum number of versions (based on the BCDS record size) applies to the sum of the backup versions of both cataloged and uncataloged data sets with the same name. When the sum of the current backup versions is greater than the BCDS-related limit, DFSMShsm creates a new version and deletes the oldest backup version of the uncataloged data sets. For example, assume the following:

The maximum BCDS record size allows DFSMShsm to maintain 29 backup versions for any data set.
A cataloged data set and several uncataloged data sets have the same data set name.
The cataloged data set currently has 24 backup versions.
The uncataloged data sets currently have four backup versions.
You specified a limit of 24 with the VERSIONS parameter.
DFSMShsm backs up one cataloged data set and two uncataloged data sets with the same name.

Because DFSMShsm (in this example) tracks only 29 backup versions, here are the results:

Twenty-four backup versions of the cataloged data set.
Five backup versions of the uncataloged data sets. DFSMShsm keeps the five most recently created backup versions of these data sets.

You can identify backup versions of an uncataloged data set by associating the data set name with the volume serial number of the source volume for the backup version. DFSMShsm considers this association of the data set name and the source volume serial number a unique identification.