In addition to the considerations discussed for volume recovery from backup versions for SMS-managed volumes, the following considerations apply for non-SMS-managed volumes.
If a catalog exists on the volume being recovered, you must recover the catalog before you use DFSMShsm for the volume recovery. DFSMShsm catalogs any data sets that were cataloged when DFSMShsm backed them up, but that are not cataloged when DFSMShsm recovers them. If a data set was uncataloged when DFSMShsm backed it up, DFSMShsm recovers the data set, but does not catalog it.
If a catalog existed on the volume the last time DFSMShsm backed up the volume, DFSMShsm recovers the base entry for each generation data group cataloged. Therefore, if you want DFSMShsm to recover the base entry for each generation data group cataloged, the catalog must exist.
DFSMShsm recovers the generation data groups that are on the volume being recovered. If the generation data group base was not on the same volume as the generation data sets, you must ensure that the base entry exists before the volume is recovered. You may have to recatalog valid generation data group data sets that are on other volumes.
DFSMShsm tries only one time to recover generation data group base entries. The recovery is handled the same way as with VTOC copy data sets. If DFSMShsm uses the next-latest VTOC copy data set to recover the volume because DFSMShsm cannot use the latest VTOC copy data set, DFSMShsm recovers the next-latest copy of the generation data group base entries.
DFSMShsm considers non-SMS uncataloged data sets to be unique by reason of the volume on which they reside. This is because multiple uncataloged data sets with the same name may exist on different volumes. Backup versions of uncataloged data sets are only recovered to the volume from which they were backed up.
DFSMShsm considers a cataloged data set to be the same data set regardless of the volume on which it is currently cataloged. Therefore, DFSMShsm recovers the most current backup version of a cataloged data set regardless of the volume on which it was cataloged when it was backed up.
Table 1 shows the process of backup version data set selection for volume recovery.
| First Criterion | Second Criterion | Result |
|---|---|---|
| If only backup versions of cataloged data sets exist, | and if the data set is currently cataloged on the target volume, | then the cataloged backup copy is recovered. |
| and if the data set is not currently cataloged, | then recovery of this data set fails. | |
| and if the data set is cataloged but not on the target volume, | then recovery is not attempted, and for APPLYINCREMENTAL, the data set is scratched from the volume. | |
| If only backup versions of uncataloged data sets exist, | and if the data set is currently cataloged on the target volume, | then recovery fails. |
| and if the data set is not currently cataloged, | then the uncataloged backup version, made from this volume, is recovered. | |
| and if the data set is cataloged but not on the target volume, | then the uncataloged backup version, made from this volume, is recovered. | |
| If backup versions of cataloged and uncataloged data sets exist, | and if both backup versions are from the target volume, | then DFSMShsm recovers the most recent backup copy. Recovery continues, depending on whether the data set was cataloged, as previously discussed. |
| and if the backup version of a cataloged data set was made from a different volume, and the data set is currently cataloged on a volume other than the target volume, | then DFSMShsm attempts to recover the uncataloged backup version. | |
| and if the backup version of a cataloged data set was made from a different volume, but the data set is currently cataloged on the target volume, | then DFSMShsm attempts to recover the backup version of the cataloged data set. | |
| and if the backup version of a cataloged data set was made from a different volume, but the data set is not currently cataloged, | then DFSMShsm attempts to recover the uncataloged backup version. |
If a data set is a candidate for recovery, backup versions of the cataloged data set exist, and the data set is currently uncataloged, then DFSMShsm does not recover the data set because it appears to DFSMShsm that the data set was deleted after the backup version was created. For recovery of uncataloged data sets, a backup version of each data set is recovered to reflect the VTOC copy at the time of backup. It is up to you to delete any recovered uncataloged data sets that are unwanted.
If a data set is currently cataloged as MIGRAT, and a backup version of the cataloged data set was selected for recovery, then recovery is not performed because the data set migrated since backup.
If a data set was migrated from the target volume after the selected backup version of the uncataloged data set was created, then the recovery is not attempted because the uncataloged data set was deleted before the creation of the cataloged data set that was migrated.
If the volume you are recovering contains both a catalog and unmovable data sets, you could have a problem. After DFSMShsm recovers the catalog, DFSMShsm tries to recover the unmovable data sets. However, the allocation for the unmovable data sets can fail because the catalog could be allocated to the space where the unmovable data set must go. To solve this problem, perform the following steps:
After DFSMShsm has recovered a volume, you can use the VOLUME parameter of the AUDIT command to verify the status of data sets on the volume.