Master-Modus

• Auflösung von Wildcards

  In HSMS-Anweisungen können Objekte, die sich auf mehreren Pubsets befinden, über Angaben wie *ALL, *OWN oder durch Wildcards in Verbindung mit der Pubsetkennung angegeben werden. Grundsätzlich werden solche Angaben über alle importierten Pubsets aufgelöst. Wenn unter diesen importierten Pubsets Shared-Pubsets sind, die im Slave-Modus importiert sind, werden diese Shared-Pubsets bei der Auflösung nicht in die Auswertung aufgenommen. Das System gibt dann eine entsprechende Meldung aus.

  Beispiele

  • FILE-NAMES = *ALL/*OWN/Wildcards über Katalogkennung
    JV-NAMES = *ALL/*OWN/Wildcards über Katalogkennung
    ADD-FILE-NAMES = *ALL/*OWN/Wildcards über Katalogkennung

    bei den HSMS-Anweisungen

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

  • Angabe von PUBSET-ID = *ALL bei der HSMS-Anweisung SHOW-PUBSET-USAGE

• Bearbeitung von HSMS-Anweisungen

  Wenn in HSMS-Anweisungen auf Shared-Pubsets Bezug genommen wird, die im Slave-Modus importiert sind, dann werden diese Anweisungen so abgearbeitet, wie es in der Übersichtstabelle auf "Übersicht" beschrieben ist.

• Empfehlungen für die HSMS-Unterstützung für einen Shared-Pubset

  • Der HSMS-Verwalter sollte für jeden Shared-Pubset ein eigenes Systemarchiv für Sicherung, Versions-Backup, Langzeitarchivierung und Verdrängung anlegen.

  • Auf allen Sharern eines Shared-Pubsets sollte das Sicherungs-Systemarchiv dieses Pubsets mit denselben Operanden angelegt werden, d.h. mit demselben Namen, demselben Archivverzeichnis, denselben Operanden für die Band- bzw. Plattenverarbeitung usw.
    Das Gleiche gilt für die Systemarchive für Langzeitarchivierung, Versions-Backup und Verdrängung.

  • Auf allen Sharern eines Shared-Pubsets sollten dem Sicherungs-Systemarchiv dieses Pubsets dieselben Operanden für TAPE-CONTROL (d.h. dieselben Bandverarbeitungszeiten usw.) zugewiesen werden.
    Das Gleiche gilt für das Systemarchiv für Langzeitarchivierung, Versions-Backup und Verdrängung.

  • Bei einem Shared-Pubset sollte das Archivverzeichnis des Systemarchivs für Sicherung, Langzeitarchivierung, Versions-Backup und Verdrängung auf diesem Pubset liegen.

  • Der S1-Pubset, der einem gemeinsam benutzbaren S0-Pubset zugewiesen ist, muss für alle Sharer des S0-Pubsets derselbe sein und gemeinsam benutzbar sein.

  • Der Band-Pool, der dem Systemarchiv für Sicherung, Langzeitarchivierung, Versions-Backup und Verdrängung eines Shared-Pubsets zugewiesen ist, muss mindestens für den Master dieses Pubsets zugreifbar sein (über MAREN).

  • Der Master eines Shared-Pubsets muss für die HSMS-Bearbeitung auf genügend Bandgeräte zugreifen können.

  • Bei Verwendung eines BACKUP-Servers (ab HSMS-V10.0 mit Parameter SAVE-FILE-PROCESSING=*HSMS-V10-COMPATIBLE), der nicht dem Master entspricht, muss der BACKUP-Server auf genügend Bandgeräte zugreifen können. Der Master benötigt nur wenige Bandgeräte (für //RESTORE-FILES, //RECALL-MIGRATED-FILES, ...) 

• Einschränkungen und Nachteile

  • Die Standard-Sicherungsdatei eines Archivs kann nur fortgesetzt werden, wenn zwischen zwei Läufen der Master nicht gewechselt wird. Die Standard-Sicherungsdatei ist nämlich Teil der Archivdefinition und die Archivdefinition ist für jeden Host lokal.
    Diese Einschränkung gilt nicht für Shared-SM-Pubsets, bei denen die Archivdefinition lokal zum SM-Pubset ist.

  • Private Plattendateien, die auf einem Shared-Pubset katalogisiert sind, können nur dann in das Sicherungs-Systemarchiv gesichert werden, wenn die Dateien einer gemeinsam benutzbaren, privaten Platte zugeordnet sind, die für den Master zugreifbar sein muss. Private Plattendateien, die diese Bedingung nicht erfüllen, müssen in ein besonderes Sicherungsarchiv gesichert werden, das von betroffenen Sharern bearbeitet werden kann.

  • Die HSMS-Anweisungen ARCHIVE-FILES, BACKUP-FILES, BACKUP-FILE-VERSIONS und MIGRATE-FILES müssen nach einem Wechsel des Masters nicht erneut gestartet werden.

  • Die Anweisungen BACKUP-FILES and BACKUP-FILE-VERSIONS für Dateien auf einem Shared-Pubset kann nicht an einem Slave erteilt werden, wenn eine Concurrent-Copy-Sitzung für einige dieser Dateien abläuft.

  • Wenn zahlreiche Shared-Pubsets denselben Master/Backup-Server haben, kann dieser Hostrechner durch die HSMS-Bearbeitung überlastet sein.

  • Wenn ein Master/Backup-Server während der Bearbeitung einer HSMS-Anweisung abstürzt oder während eines impliziten Recalls, der durch ein /SECURE-RESOURCE-ALLOCATION für verdrängte Dateien ausgelöst wurde, dann muss die HSMS-Anweisung bzw. das SECURE-RESOURCE-ALLOCATION-Kommando nochmals gegeben werden.
    Nur ein impliziter Recall, der durch einen OPEN verursacht wurde, wird auf dem Backup-Master automatisch nach einem Wechsel des Masters wiederholt.

  • Wenn auf dem Master/Backup-Server eine höhere HSMS-Version als auf anderen Sharern läuft, können einige Meldungen undefiniert sein, die in die Ausgabedatei geschrieben werden. In diesem Fall können Sie nur die Meldungsnummer und die Inserts in der Ausgabedatei lesen. Die Bedeutungs- und Hilfetexte können Sie mit dem Kommando /HELP-MSG entweder auf dem Master ansehen oder auf jedem Sharer, auf dem eine HSMS-Version läuft, in der diese Meldung definiert ist.

• Vorteile des Master-Modus

  Bessere Performance als im Lokalen Modus, da nur geringe Kommunikation zwischen dem Slave-Sharer und dem Master erforderlich ist.