- To ensure that DFSMShsm does not select the volume being recovered
as a target volume for migration, issue the DFSMShsm ADDVOL command
with the DRAIN parameter. Issue the command in all DFSMShsm hosts.
- Restore the latest dump copy of the volume. This restores the
DASD migration volume to its level when the dump copy was created.
Issue the following DFSMShsm command to request a full volume restore
of the volume.
RECOVER * TOVOLUME(volid) UNIT(unittype) FROMDUMP
- If the migration volume contains SDSP data sets and you have your
own procedures to back up these data sets more frequently than you
dump the volume, recover the most recent backup of the SDSP data set
to the migration volume being recovered.
- After the volume has been successfully restored, issue the FREEVOL
command. This leaves data on the migration volume that is no longer
valid, migrated data. It also enables you to easily obtain a list
of the data sets that still need to be recovered (those that the MCDS
indicates are still on the migration volume). The FREEVOL command
process is driven off of the volume table of contents (VTOC) and includes
all data sets in an SDSP data set on the volume that are currently
migrated. Use the AGE(0) parameter to indicate that all data sets
must be migrated. You can specify either ML1 or ML2 as the target
migration level when you want to process a ML1 volume. Use the following
command as an example:
FREEVOL MIGRATIONVOLUME(volser) TARGETLEVEL(MIGRATIONLEVEL1) AGE(0)
- Request from DFSMShsm a list of all the migrated data
sets that are indicated as being on the volume being recovered. These
data sets represent the data sets that were migrated to the volume
after the most recent dump copy was created. The migration copies
of the data sets have been lost, so the data sets must be recovered
from backup versions. Use the following LIST command to request this
list of data sets:
LIST DATASETNAME MIGRATIONCONTROLDATASET -
SELECT(VOLUME(volser)) OUTDATASET(dsname)
The OUTDATASET parameter is
highly recommended so that the output from the LIST command is written
to the data set whose name is given by dsname.
This allows you to use a text editor to modify the output to easily
perform the remaining steps:
- Make one more copy of the output data set, dsname.
- For each data set in the output from 5, perform
steps 8 and 9 . You cannot
perform these steps concurrently for the same data set. By using two
copies of the list of data sets from step 5, you
can modify each of the two lists to perform steps 8 and 9 for all of the data sets at one time. Use a text editor
and its global change command to add and remove the necessary text
around each data set name.
- Delete the migrated data set. This uncatalogs the
data set and deletes the MCDS data set record and any associated MCL,
MCA, and MCO records. Do this with the following DFSMShsm command:
DELETE dsname
- Recover the latest backup version for each data set.
Do this with the following DFSMShsm command:
RECOVER dsname REPLACE
Note: The backup
copy that is recovered may not be the most current version of a data
set if the data set was migrated to the ML1 volume before it was backed
up.
- If the recovered volume is an ML1 volume, there might be backup
versions that were restored to the migration volume. Some of these
may represent valid backup versions. These can exist if data set backup
requests were processed between the time automatic backup last ran
on the primary DFSMShsm host before the volume was dumped and the
time when the volume was dumped. You can use the following procedure
to assist you in recovering the backup versions, see Recovering backup versions from a damaged migration level 1 volume.
- After all valid, DFSMShsm-owned data sets have been removed from
the volume, you can reinitialize the volume. DFSMShsm no longer requires
access to it. You can also remove the volume from DFSMShsm’s control
with the DELVOL command.
The data sets will probably migrate the next time automatic primary
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 unless you rename
the data set. Therefore, the recovered data sets will probably have
a high inactive age.