Procedure 2

Rule: Do not start any step until the previous steps have completed.

  1. Determine which data sets were on the migration volume. To do this, use the following command:
    LIST DSN MCDS SELECT(VOLUME(volser)) -
    OUTDATASET(dsname)

    For volser, specify the volume serial number of the migration volume. DFSMShsm writes the list in the data set whose name is dsname. You can issue this command from a console, terminal, or batch job.

  2. Do a LISTCAT command if you want to save information about the data sets that you are going to delete in the next step. You may want to know, for example, whether the status of a generation data set (GDS) is DEFERRED or ACTIVE before it is deleted, because after being deleted it is always recovered with a status of DEFERRED.
  3. Delete the MCDS data set record. This uncatalogs the data set and deletes the MCDS data set record and any associated MCL, MCA, and MCO records. To do this, use the following command for each data set on the migration volume:
    DELETE dsname

    When you use a text editor such as ISPF, you can edit the data set produced by the LIST command (step 1) so it contains one line for each data set. Each line contains the data set name. Replicate this data set once because you will need a copy for the next step. Then, use a global change command to precede each data set name with the characters HSENDCMD DELETE. A DFSMShsm-authorized user can then run the data set as a command procedure (CLIST). However, if you have many data sets, include the necessary JCL in the data set and submit the data set as a batch job.

  4. Recover the latest backup version for each data set that migrated to the migration volume. To do this, issue the following DFSMShsm command:
    RECOVER dsname

    When you use a text editor such as ISPF, you can edit the copy of the data set containing the name of each data set on a separate line. Then, use a global change command to precede each data set name with the characters HSENDCMD RECOVER. A DFSMShsm-authorized user can then run the data set as a command procedure (CLIST). If you have many data sets, include the necessary JCL in the data set and submit the data set as a batch job.

  5. Issue the IDCAMS ALTER ROLLIN command if you want to change the status of a recovered GDS from DEFERRED to ACTIVE.

    The catalog status of a recovered GDS is dependent upon its catalog status before being recovered. If the GDS is not cataloged before recovery, its catalog status after recovery is DEFERRED. If the GDS is cataloged before recovery, its catalog status after recovery remains the same, with the following exception: when DFSMShsm is used as a data mover to recover a rolled-off GDS, the cataloged status of the GDS, after it is recovered, is DEFERRED.

  6. Follow the procedure titled Recovering backup versions from a damaged migration level 1 volume if the volume being recovered is an ML1 volume and there are backup versions that must be recovered or replaced.

The data sets will probably migrate the next time automatic space management occurs on the DFSMShsm-managed volumes. This happens because when DFSMShsm recovers a data set, the data set VTOC entry is restored exactly as it was when the backup version being recovered was created. DFSMShsm does not reset the date-last-referenced field to the current date when it recovers the data set. Therefore, the recovered data sets will probably have a high inactive age.

Related reading

For more information about the LISTCAT command, see z/OS DFSMS Access Method Services Commands.