The DMS interfaces used for data processing are supplemented by the interfaces of HSMS (Hierarchical Storage Management System). HSMS manages the storage of files on the three storage levels of BS2000 and the movement of files between them:
processing level (S0)
background level 1 (S1) with online access
background level 2 (S2) without online access
HSMS implements migration, backup and archiving of files and job variables on the basis of these storage levels.
The "archive definition" and "directory" metadata that HSMS requires is not linked to a pubset (with the exception of system-managed pubsets discussed in the section below). The archive definitions are stored on the default pubset of the HSMS administrator’s ID, i.e. as a rule on the home pubset of the processor. The storage location of a directory can be freely selected.
All the functions of the HSMS interface, too, are available in the shared SF pubset environment (SM pubsets are dealt with in the next section). Jobs for data objects on a shared SF pubset are executed on the master processor, irrespective of which processor the job is assigned to in the network. Jobs which embrace files from several shared pubsets are only accepted if all the pubsets have the same master processor. After a master processor crashes, interrupted backup jobs cannot be moved elsewhere. Re-startable jobs can, however, be continued on the crashed processor when it is available again, even if, after the system is restarted, it only participates in the MSCF network in slave mode.
The "concurrent copy" (CCOPY) function is available to reduce the time window of backup runs. It enables a consistent status of a file set to be backed up. The files can then be processed in any way in parallel after an initialization phase once the backup is logically terminated. A consistent status can be provided for the backup as follows:
Before changes are made to a block of a file in the backup set, a copy (“before image”) of this block is copied to a working file
If additional, freely configurable mirror volumes are available, these additional mirrors can be detached when the backup is initialized. The backup can then be made from these mirrors.
CCOPY is also supported in the shared pubset network. Here you should note the following:
CCOPY with “before images”:
For files on a shared pubset, the copy process to create a "before image" is always carried out on the master processor and an appropriate copy job is transmitted from the slave processor to the master processor. If the connection is lost from a slave processor to the master processor, however, the slave cannot send the job to the master processor and this results in the backup being aborted. After a master processor crash, the backup run cannot be restarted because backup jobs initiated with CCOPY are not re-startable. The backup run must be restarted from scratch.CCOPY with mirror disks:
Shared pubset networks are supported.
When the backup is complete, the mirroring is resumed.
Backup jobs with mirror disks are re-startable.
For further information on HSMS, see the “HSMS” manual [8 (Related publications )].
The functions for mirror disks are described in the “SHC-OSD” manual [18 (Related publications )].