With migrated files, HSMS can only administer the required backup data if all the data of the migrated files is included in the backup. This is essential if data lost is to be restored without problems.
HSMS handles migrated files as follows during the restore:
Version control
When RESTORE is used (for example, during the restore, activation or importation) by a nonprivileged user, migrated files are always brought to storage level S0.
Recovering from an S0 crash
The HSMS administrator can opt to restore only the catalog entries of migrated files. This can be carried out using the operand MIGRATED-FILES=*CATALOG-ONLY in the RESTORE-FILES statement. This modifies the catalog entries so that they point to the most recent appropriate data in the migration archive (this is an implicit EXCHANGE).
If the migration archive contains no appropriate data for a file, the system indicates an error. The catalogue entry remains. The system outputs an error message of this kind in connection with files which have been restored or deleted since the last backup, provided the migration area was reorganized after the restoration or deletion. Any such residual inconsistencies can be corrected by
restoring the affected files to S0 or a specified migration level. Therefore the HSMS statement REPAIR-CATALOG-BY-RESTORE is provided.
deleting the catalog entry.
Recovering from an S1 crash
Different approaches can be taken:
The REPAIR-CATALOG-BY-EXCHANGE statement, provided copies of the data exist in storage level S2 or any other migration archive..
The REPAIR-CATALOG-BY-RESTORE statement, provided backups of the data migrated to S1 exist in the backup archive.
The two approaches can be combined. First, the identifying information of those files for which the migration archive contains data is updated to select the appropriate save files (using the REPAIR-CATALOG-BY-EXCHANGE statement). Then, those files for which the migration archive no longer contains data but which have data in the backup archive are restored from the backup archive using REPAIR-CATALOG-BY-RESTORE. Both statements affect only those migrated files which have the same file status (CFID) in the backup file, which became invalid and is in repair.
Recovering from an S2 crash
Various approaches can be taken to recover from an S2 crash or destruction of a save file in the migration archive:
The REPLACE-SAVE-FILE-BY-EXCHANGE statement, provided the migration archive contains a copy of the save file.
The REPLACE-SAVE-FILE-BY-RESTORE statement, provided the backup archive contains backups of the save file data.
The COPY-SAVE-FILE statement issued from an long-term archive and followed by a REPAIR-CATALOG-BY-EXCHANGE or REPLACE-SAVE-FILE-BY-EXCHANGE.
Recovering from a crash on S0 and the migration levels
The storage level S0 can be restored first using the operand MIGRATED-FILES= *CATALOG-ONLY of the RESTORE-FILES statement. The HSMS statements REPAIR-CATALOG-BY-EXCHANGE and REPAIR-CATALOG-BY-RESTORE can subsequently be used to activate or restore the data on the migration level.
For the troubleshooting of S1 and S2 crashes, it is always required to keep copies of the migrated data. At the time of migration this is guaranteed by the global, respectively SM pubset-specific, HSMS parameter BACKUP-MANDATORY=*YES only being able to migrate files that have been saved before. The backups created here are generally shared after the expiration of the retention period in the backup (//MODIFY-ARCHIVE ... SAVE-FILES = *DELETE(...) ) and are then unavailable as backup copy. It is therefore crucial to also save the migrated data from time to time. This is done using //BACKUP-FILES ... SAVE-OPTIONS=*PARAMETERS(SAVE-DATA=*S2-S1-S0)