Master mode

• Interpretation of wildcards

  Objects residing on more than one pubset can be specified in HSMS statements by means of specifications such as *ALL, *OWN or using wildcards combined with the pubset ID. Entries of this kind are always interpreted as applying to all imported pubsets. If the imported pubsets include shared pubsets imported in slave mode, however, the latter are ignored when the wildcards are interpreted. The system displays a message to this effect.

  Examples

  • FILE-NAMES = *ALL / *OWN / wildcards via catalog ID
    JV-NAMES = *ALL / *OWN / wildcards via catalog ID
    ADD-FILE-NAMES = *ALL / *OWN / wildcards via catalog ID

    in the HSMS statements

    ARCHIVE-FILES, BACKUP-FILES, EXPORT-FILES, MIGRATE-FILES, RECALL-MIGRATED-FILES, SELECT-FILE-NAMES and UPDATE-EXPORT-SAVE-FILE.

  • Specification of PUBSET-ID = *ALL in the HSMS statement SHOW-PUBSET-USAGE

• Processing HSMS requests

  When reference is made in HSMS statements to shared pubsets that are imported in slave mode, the statements are processed as described in the overview table in section "Overview".

• Recommendations concerning HSMS support for a shared pubset

  • For each shared pubset, the HSMS administrator should create a separate system archive for backup, version backup, archival, and migration.

  • The backup system archive of a shared pubset should be created with the same operands on all the sharers of the pubset, i.e. with the same name, the same archive directory, the same operands for tape or disk processing, etc.
    The same applies to the system archives for archival, version backup and migration.

  • The backup system archive of a shared pubset should be assigned the same operands for TAPE-CONTROL (i.e. the same tape sessions, etc.) on all the sharers of the pubset.
    The same applies to the system archives for archival, version backup and migration.

  • In shared pubsets, the archive directory of the system archive for backup, version backup, archival and migration should reside on the pubset.

  • The S1 pubset assigned to a shared S0 pubset must be the same for all sharers of the S0 pubset and be shareable.

  • The tape pool assigned to a shared pubset’s system archive for backup, version backup, archival and migration must be accessible at least for the master of the pubset (via MAREN).

  • For HSMS processing, the master of a shared pubset must have access to a sufficient number of tape devices.

  • When using a BACKUP server (in HSMS-V10.0 or higher with the SAVE-FILE-PROCESSING=*HSMS-V10-COMPATIBLE parameter) that does not match the master, the BACKUP server must have access to a sufficient number of tape devices. The master only needs a few tape devices (for //RESTORE-FILES, //RECALL-MIGRATED-FILES, ...)

• Restrictions and drawbacks

  • An archive’s standard save file can only be continued as long as the master is not changed between two runs. Since the standard save file is part of the archive definition and the archive definition is local for each host.
    This restriction does not apply to shared SM pubsets in which the archive definition is local to each SM pubset.

  • Private disk files cataloged on a shared pubset can be saved in the backup system archive only if the files are assigned to a shared private disk which the master can access. Private disk files that do not meet this requirement must be saved in a particular storage archive, which the sharers concerned can process.

  • The HSMS statements ARCHIVE-FILES, BACKUP-FILES, BACKUP-FILE-VERSIONS and MIGRATE-FILES need not be restarted after a change of master.

  • BACKUP-FILES and BACKUP-FILE-VERSIONS statements relating to files on a shared pubset cannot be issued to a slave if any of the files are being processed in a Concurrent Copy session.

  • If a large number of shared pubsets have the same master/backup server, HSMS processing may overload this host.

  • If a master/backup server crashes during processing of an HSMS statement or during an implicit recall triggered by a /SECURE-RESOURCE-ALLOCATION for migrated files, the HSMS statement or /SECURE-RESOURCE-ALLOCATION command must be issued again.
    Only an implicit recall caused by an OPEN will be repeated automatically on the backup master following a change of master.

  • If a higher HSMS version is running on the master/backup server than on the other sharers, certain messages that are written to the output file may be undefined. In this case you can only read the message number and the inserts in the output file. You can use the /HELP-MSG command to view the explanatory and help texts on the master or on any sharer which is running an HSMS version in which this message is defined.

• Advantages of master mode

  Master mode offers better performance than local mode since little communication is required between the slave sharer and the master.