Once the preparations have been completed, Snapset mode (in the example for pubset A) can commence, i.e. systems support or HSMS administration can create pubset copies (=Snapsets) at the planned times.
Example
Pubset A is to be saved twice each workday (e.g. at midday and in the evening).
Creating a Snapset
At the required save time systems support or HSMS administration uses the CREATE-SNAPSET command to create a Snapset:
/CREATE-SNAPSET PUBSET=A
This command can be entered on all systems involved in shared pubset mode. Only one CREATE-SNAPSET command can be issued at a time for a pubset. Parallel calls are serialized.
The default for this command is that the oldest Snapset is implicitly deleted when the Snapset limit is reached. Optionally the DELETE-EARLIEST operand can also be used to specify that the oldest Snapset should always be implicitly deleted or that it should never be implicitly deleted.
The newly created Snapset is automatically placed in service and is then available to all users for restoration purposes.
Snapset identification
Each newly generated Snapset is assigned a unique Snapset identification. Firstly the lower case letters “a” through “z”, then the upper case letters “A” to “Z” in alphabetical order are used here for the 52 maximum possible Snapsets. After “Z” has been reached, assignment begins again with “a” (the chronological order of Snapset creation consequently does not always match the alphabetical order of the Snapset IDs). Case sensitivity must be observed at the command interface.
Each snap unit contains a VSN which is formed from the VSN of the original disk and the Snapset identification.
Example illustrating the mapping rule
VSN in PUB notation and Snapset ID as lowercase letter, e.g. "a": PUBX12 --> PaaX12
VSN in PUB notation and Snapset ID as uppercase letter, e.g. "A": PUBX12 --> aaBX12
VSN in dot notation and Snapset ID as lowercase letter, e.g. "a": AB.123 --> ABa123; ABC.12 --> ABCa12; ABCD.1 --> ABCDa1
VSN in dot notation and Snapset ID as uppercase letter, e.g. "A": AB.123 --> AB123a; ABC.12 --> aABC12; ABCD.1 --> AaBCD1
Managing and starting up Snapsets
Each newly created Snapset has a unique Snapset identification (see "Snapset identification"). The descriptions of all the Snapsets of a pubset are kept and managed in the Snapset catalog. The Snapset catalog is stored in the associated pubset under the name $TSOS.SYSCAT.SNAPSET and contains the following information:
the processing environment for the pubset’s Snapsets, such as the usage of remote replication and details of the save pool
Descriptions of the various Snapsets with details such as the Snapset identification, creation date and MNs of the snap units in the local storage system and, if required, also of the snap units in the remote storage system.
If the Snapset catalog does not yet exist, it is configured when the Snapset is created. In the case of an SM pubset the Snapset catalog is located on the Volres of the control volume set, and in the case of an SF pubset on the associated Pubres.
Starting and shutting down Snapsets
Existing Snapsets are generally started when the associated pubset is imported.
They are not started if the SHC-OSD subsystem is not yet active at the time the pubset is imported (existing Snapsets of the home pubset in particular are not automatically started when the system starts up). As soon as SHC-OSD is active, the Snapsets are activated retroactively by issuing the SHOW-SNAPSET-CONFIGURATION command.
When Snapsets cannot be placed in service implicitly because of hardware or configuration problems, they initially remain in the "not available" status. After the error has been corrected, these Snapsets can be made accessible again using the CHECK-SNAPSET-CONFIGURATION command.
When a Snapset is created with the CREATE-SNAPSET command, it is automatically placed in service.
The following actions are performed in this case:
Open the Snapset catalog (by means of GCF)
Assign all snap units (ATTACH)
In a configuration with remote replication, the “suitable” snap units are assigned. In the normal status with active remote replication, these are the snap units in the local storage system. In the case of split mirrors, the selection is made on the basis of the imported original pubset:In the case of the pubset on the local storage system, only the snap units on the local storage system are used.
In the case of the pubset on the remote storage system, only the snap units on the remote storage system are used.
Under VM2000, constraints must be observed for implicit device assignment, see section “Note for VM2000” in chapter "Preparing Snapset mode".
Creating a Snapset in the storage system
Set up a CCOPY session for the Snapset
When a pubset is exported, the associated Snapsets are shut down. The actions performed during the import are performed in reverse order.
Deleting a Snapset
Irrespective of snap creation, systems support or HSMS administration can also explicitly delete an existing Snapset for an imported pubset:
/DELETE-SNAPSET PUBSET=A[,SNAPSET=*EARLIEST]
Here the oldest Snapset of pubset A is deleted. The specification SNAPSET=*EARLIEST can also be omitted (default).
The Snapset to be deleted can also be specified by means of its Snapset identification or as a relative specification relating to the current status of the pubset (with -n, where -1 designates the latest Snapset). Deleting a Snapset means that the associated pubset backup status is no longer available. Restore operations which are currently active for a Snapset which is to be deleted are aborted when the Snapset is deleted.
When operating with ETERNUS DX/AF, only the oldest Snapset can be deleted. This must be borne in mind when a Snapset to be deleted is specified explicitly by means of the Snapset ID or the relative age.
Terminating Snapset mode
The SNAPSET=*ALL specification causes all Snapsets to be deleted and Snapset mode to be terminated for the pubset. This call incorporates the following measures:
Delete all Snapsets
Close and delete the Snapset catalog
Set the pubset’s Snapset limit to zero
Displaying Snapsets
The SHOW-SNAPSET-CONFIGURATION command displays information on the relevant Snapsets, see the "Commands" manual [27]:
/SHOW-SNAPSET-CONFIGURATION PUBSET=<cat-id>,SNAPSET=*ALL
In this case both cross-pubset and Snapset-specific information is displayed.
If the privileged user (privilege TSOS, OPERATING, HSMS administrator) requests information on a particular Snapset, the VSNs of the pubset volumes and the MNs of the assigned snap units of the local storage system are also output (in the case of remote replication, possibly also for the remote storage system).
Notes and restrictions
No Snapset mode
Snapset mode for a pubset – like all other replication functions offered via SHC-OSD – is not compatible with DAB write caching for this pubset. The CREATE-SNAPSET command is rejected in the event of DAB write caching.
Snapset mode and DRV mirroring for a pubset are mutually exclusive: DRV operation cannot be started on a pubset in Snapset mode (Snapset limit not equal to 0) and vice versa.
Snapset mode with remote replication
When Snapsets are also to be operated on the remote storage system (see section “Snapset mode in the case of disaster protection with remote replication” in chapter "Preparing Snapset mode"), the following restrictions must be borne in mind:
Snapset operation on the remote storage system is not possible if remote replication is interrupted (either by the HOLD-REMOTE-COPY command or as a result of interrupted links) if the remote mirror has not yet been synchronized or in the case of asynchronous remote replication.
If Snapset creation fails on one of the storage systems involved (local or remote), no Snapset is created on the other storage system either.
When access to the pubset’s disks is switched dynamically between the source and target systems (e.g. by SHC-OSD commands), access to the Snapsets allocated to the pubset is not also switched automatically.
The ADAPT-SNAPSET-ACCESS command ensures that the allocated Snapsets are still available after such a switchover without the pubset having to be exported.When the command is called, a check is made to see whether access to the allocated Snapsets takes place in the same controller as access to the pubset’s disks. If this is not the case, the switchover for the Snapsets allocated to the pubset is emulated:
The Snapsets currently attached are taken out of service.
The Snapsets of the local controller are then attached.
Resource bottleneck and its consequences
The storage space required for the original data to be saved is initially provided by the respective snap units and, if necessary, by the save pool. Information on this and the possible consequences in the event of an overflow is provided in section "Preparing Snapset mode".
The measures below should be taken to avoid high memory requirements for the original data to be saved:
Do not generate paging files in pubsets which use Snapset mode
Reorganize the pubset as little as possible using the software product SPACEOPT
Changing the pubset configuration
Before one of the following changes to the pubset configuration is performed, Snapset mode must be terminated (this means deleting all Snapsets):
before a pubset is renamed
before an SF pubset is transferred to a volume set of an SM pubset
before switching to other pubset disks, i.e. when switching from K to NK format, or in the event of a physical relocation using FDDRL (save/restore)
When the pubset is extended by the addition of further disks, the set of suitable pubsets must be extended accordingly (see section "Preparing Snapset mode").
When the pubset is reduced by removing disks, existing Snapsets become invalid. They can no longer be used for restoration. After the remote disks have been reinitialized, the Snapsets will be removed from the Snapset catalog the next time the pubset is imported. Existing Snapsets must therefore be saved before disks are removed from the configuration using HSMS if the data stored on them is still required. A new Snapset should be created immediately after a configuration change so that it is still possible to restore files and job variables and also the entire pubset.
Migrated files
To ensure that migrated files are still usable after Snapsets have been restored, the associated tapes must still exist. They may not have been released or already have been reused.
When existing Snapsets cover a period of n days for restoration, restoration of the migrated files using HSMS should always only be performed for a period preceding these n days.