As soon as Snapset mode has started for a pubset, the pubset copies on the created Snapsets are available for all users to restore. The Snapsets are operable if the pubset has been imported. The nonprivileged user has access to files and job variables in accordance with the DMS access rights.
Users obtain information on all the operable Snapsets by means of the SHOW-SNAPSET-CONFIGURATION command; Privileged users are also provided with more detailed information on Snapset disks:
/SHOW-SNAPSET-CONFIGURATION PUBSET=A[,SNAPSET=*ALL]
Before a file or job variable is restored, the user can determine which save status, i.e. which Snapset, is to be used.
Displaying information on saved files/job variables
Users obtain a list of the files and job variables which are contained in a Snapset backup and can therefore be restored from this backup using the LIST-FILE-FROM-SNAPSET or LIST-JV-FROM-SNAPSET command. These commands can be executed in parallel and synchronously on all pubset sharers.
Nonprivileged users obtain information on files and job variables which they can access in accordance with their DMS rights (comparable to SHOW-FILE-ATTRIBUTES and SHOW-JV-ATTRIBUTES). Systems support has extended rights.
Partial qualification and the specification of wildcards in file/job variable names are permitted when selecting a set of files/job variables, but not in the catalog and/or user ID.
The information output contains not only the name, but also the attributes required for permitting the restore operation: size, special identifier for migrated files and tape files, creation date and date of the last access (or expiration date in the case of job variables), plus the file status. The file status indicates whether the file was open in write mode at the time it was saved (STATE=OPENED or CLOSED). STATE=NOREST is displayed in the case of files which cannot be restored (e.g. files with the save frequency BACKUP-CLASS=E or special system files).
Restoring files/job variables
Users can restore files and job variables from a Snapset using the RESTORE-FILE-FROM-SNAPSET or RESTORE-JV-FROM-SNAPSET command. These commands can be executed in parallel and synchronously on all pubset sharers.
Nonprivileged users can access files and job variables in accordance with their DMS rights (read authorization for the original file and owner rights for the target file). Systems support has extended rights.
Partial qualification and the specification of wildcards in file/job variable names are permitted when selecting a set of files/job variables, but not in the catalog and/or user ID.
The files/job variables specified are restored from a particular Snapset (the latest Snapset is preset by means of the SNAPSET=*LATEST operand). However, a range of Snapsets (SNAPSET=*INTERVAL operand) or all Snapsets (SNAPSET=*ALL operand) can also be included in the restore operation. In this case the files/job variables are restored to their most recent status among these Snapsets.
As with HSMS restoration from backup archives, files and job variables are restored with their original catalog attributes. In particular, the creation and modification times and also the protection attributes are the same as those of the original at the time it was saved, i.e. at the time the Snapset was created. Optionally a log can list either just the files/job variables which were not restored owing to errors or also all the files/job variables which were restored.
Additional options for restoration
When a Snapset is generated, all the files and job variables of the pubset are saved simultaneously. All the pages of a file are also saved simultaneously. Consequently files which are open in write mode are saved crash-consistently. By default these files are not restored (except for files with the ONLINE-SAVE indicator). Restoration of such files can be requested explicitly (RESTORE-OPEN-FILES=*YES operand). In the case of ISAM files, postprocessing with the REPAIR-DISK-FILE command may be necessary. System files for SRPM, GUARDS and GCF which are constantly open are made consistent when the Snapset is created in order to permit proper restoration later.
Files and job variables can be restored under a new name (NEW-FILE-NAME or NEW-JV-NAME operand). They are renamed either by specifying a different user ID or a file name prefix. Nonprivileged users can specify a different user ID if they are co-owners of the ID concerned. They can specify their own user ID when they want to restore a foreign file (read access is required) on their own ID.
Existing files and job variables are by default not overwritten, i.e. not restored. Restoration of these files/job variables can be explicitly requested (REPLACE=*YES operand). Delete authorization (e.g. write password) is required to overwrite them. Privileged callers can explicitly ignore the write protection (IGNORE-PROTECTION=*YES operand).
Restrictions
Individual file generations cannot be restored, only entire file generation groups can.
Only the catalog entries are restored for migrated files and tape files. Renaming is not possible in this case (exception: a privileged user under TSOS can specify a different user ID when a tape file is involved).
Restoring PLAM library members
In LMS, the OPEN-LIBRARY statement enables a PLAM library on a Snapset to be opened in read mode. Members of this library can then be displayed, copied or selected using the relevant LMS statements.
Saving a Snapset to a backup archive
The HSMS statement BACKUP-FILES enables files/job variables which have been saved to a Snapset to be transferred to a backup archive. With the BACKUP statement below you can, for example, transfer all the files and job variables of the user ID USER1 which were saved in the last Snapset backup of pubset A to a backup archive:
//BACKUP-FILES FILE-NAMES=$USER1., JV-NAMES=$USER1.,
ARCHIV-NAME=<archiv>,CONCURRENT-COPY=*YES(
WORK-FILE-NAME=*FROM-SNAPSET(PUBSET-ID=A,SNAPSET-ID=-1)
This function is also available to nonprivileged users.
A Snapset can be transferred to a backup archive at any time between the creation and deletion of the Snapset. This takes place practically “offline” with regard to the ongoing pubset operation. The new save version generated in HSMS is then not assigned the current date of the BACKUP-FILES call as the Save time, but the creation date of the Snapset. However, no newer save version may exist in the backup archive.