Restrictions due to new functions

A number of restrictions on reverting to ARCHIVE are caused by the following new HSMS-specific functions:

• New protection mechanisms

• Updating (continuation) of save volumes

• Backup to S1 pubsets or volume sets

• Introduction of version backup

• Introduction of migrated files

• Backing up node files of the BS2000-UFS (POSIX) or of remote nodes S0 via POSIX

• Backup/restoration of files for which there are co-owners

• Saving files on Net-Storage

The restrictions governing reversion to ARCHIVE usually depend on the ARCHIVE version involved. They are described below.

Restrictions due to different protection mechanisms

Since HSMS save requests are processed by a privileged server task under TSOS (and not, as in ARCHIVE, by a subtask under the user’s own ID), access to save copies of files under the user’s own ID is not possible without further action.

Provided the user is working under the ID under which the directory file is cataloged or under TSOS, ARCHIVE can be used to restore files from that directory file. Otherwise, ARCHIVE can access only those save files in a directory file under TSOS that were created as shareable files (see “HSMS Vol. 2” [1], BACKUP-FILES statement, USER-ACCESS=*ALL-USER operand).

This means that a directory file created by HSMS under the user ID SYSHSMS may have to be copied to TSOS.

Restrictions due to tape continuation

With tape backups in SEVERAL-SVID format and generally in long-term archiving and migration, HSMS creates backup files in a way that they can consist of more than one save version. This affects the possibility of reverting to ARCHIVE.

There are no restrictions on read access to the save volumes under the user ID TSOS. However, an SVID must be specified when accessing volumes containing more than one save version. The LIST statement can only be used if the SVIDs on the volume are in ascending alphabetical order.

Directory file processing is supported in IMPORT/EXPORT runs only. Multiple save copies of a file in one and the same save file can be accessed directly and restored using IMPORT.

ARCHIVE does not support the continuation of save files with more than one save version.

Restrictions due to backup to pubsets

HSMS permits backup to (S1) pubsets. This has the following consequences for reverting to ARCHIVE:

With a directory file, restoring and listing are possible without restrictions, if the backup has been performed under HSMS with the setting SAVE-FILE-PROCESSING=*HSMS-V9-COMPATIBLE.
Access to a save file without a directory file is possible only if the save file resides on the home pubset. If this is not the case, it must first be copied to it. 

Restrictions due to file migration

HSMS introduces the concept of file migration. This has the following consequences for reverting to ARCHIVE:

Any EXPORT referring to a migrated file or any SAVE referring to a user ID != TSOS is rejected with an error message.
The catalog entries of migrated files can only be saved under the user ID TSOS; renaming during the restore is not permitted. The SPACE operand is ignored.

Restoring files from node S0:

HSMS is an essential requirement to restore files of the BS2000-UFS (POSIX) or of remote nodes S0 (e.g. UNIX workstations) which were mounted via POSIX and saved with HSMS (BACKUP-NODE-FILES, ARCHIVE-NODE-FILES).

Saving Net-Storage files

When HSMS is saved you can define which files are to be saved at statement level:

• files on pubset, Net-Storage and private disk

• only files on pubset and private disk

• only files on Net-Storage

In ARCHIVE this behavior cannot be controlled at statement level. The STORAGE-TYPE parameter in the parameter file SYSPAR.ARCHIVE offers the following options for controlling the entire ARCHIVE session:

• STORAGE-TYPE=ANY or no parameter specified

  If the FROM operand was not specified in the FILES statement, all the files specified in the NAME operand are saved which reside on pubset, private disk, or Net-Storage. Only the catalog entries of tape files are saved.

  If FROM=PUBLIC was specified, only files which are specified in the NAME operand and which reside on public volumes or on Net-Storage are saved.

• STORAGE-TYPE=PUBLIC-SPACE

  If the FROM operand was not specified in the FILES statement, all the files specified in the NAME operand are saved which reside on pubset or private disk. Only the catalog entries of tape files are saved.

  If FROM=PUBLIC was specified, only files which are specified in the NAME operand and which reside on public volumes are saved.

  As files on Net-Storages are excluded from the backup in both cases, data security for these files can only be provided in this case by backing up the file system concerned to the net server itself.

The same applies for the TO operand of the FILES statement for reconstruction:

• If STORAGE-TYPE = ANY is specified and the TO operand is missing, the files are restored to their original media. When TO=PUBLIC, all files, including files from private volumes, are written back to public volumes. In this case files that were saved from Net-Storage are restored to Net-Storage. Files on Net-Storage are public files.

• If STORAGE-TYPE = PUBLIC-SPACE is specified, all files are restored on the defined pubset, irrespective of the medium they have been saved from. ARCHIVE does not save the SAM structure of SAM node files, therefore, these files can only be restored on Net-Storage with the node file type. ARCHIVE outputs a message into the log file for each file that could not be processed on the public volume due to this.