Bei Ausfall eines Systems innerhalb des Shared-Pubset-Verbundes müssen die von ihm reservierten Ressourcen freigegeben oder Recovery-Maßnahmen eingeleitet werden. Alle am Shared-Pubset-Verbund beteiligten Systeme werden vom Subsystem MSCF überwacht.
Zur Systemüberwachung dienen zwei Kontrollmechanismen:
die sog. Watch-Dog-Datei $TSOS.SYS.PVS.SHARER.CONTROL, in die alle Sharer periodisch Zeitstempel hineinschreiben (Lebendmeldungen). Fällt ein Sharer aus, kann diese Tatsache von einem anderen Sharer am Ausbleiben von dessen Lebendmeldung erkannt und entsprechende Maßnahmen eingeleitet werden.
Beim Ausbleiben der Lebendmeldung wird die Systemverbindung überprüft, indem ein Auftrag an den betroffenen Sharer gesendet wird; dieser muss innerhalb eines bestimmten Zeitintervalls quittiert werden.
Ein Partner-Ausfall wird nur dann angenommen, wenn das Ausbleiben der Lebendmeldung durch eine erfolglose Netzwerk-/LAN-Überprüfung bestätigt wird.
Bei Ausfall des Eigentümer-Systems wird an allen abhängigen Systemen eine pubset-spezifische Jobvariable gesetzt.
Ausfall eines Pubset-Slaves
Erkennt ein Pubset-Master den Ausfall eines beteiligten Pubset-Slaves, so werden alle vom ausgefallenen Pubset-Slave reservierten Ressourcen freigegeben.
Ausfall eines Pubset-Masters
Bei Ausfall des Pubset-Masters findet, angestoßen durch den Watch-Dog-Mechanismus, ein Master-Wechsel statt. Voraussetzung für den Master-Wechsel ist, dass ein aktiver Pubset-Slave im SVL des Shared-Pubsets als Backup-Master eingetragen ist, der die neuen Master-Funktionen übernehmen soll.
Der Backup-Master wird mit dem Kommando SET-PUBSET-ATTRIBUTES BACKUP-MASTER=... im DMS-Record des SVL eingetragen. Falls kein Backup-Master eingetragen ist oder der eingetragene Backup-Master nicht aktiv ist, entscheidet der Wert des Operanden ALTERNATE-BACKUP, ob der erste aktive Pubset-Slave im SVL zum Pubset-Master wird oder der Operator explizit über das Kommando IMPORT-PUBSET SHARER-TYPE=*MASTER(MASTER-CHANGE=*YES) einen der aktiven Pubset-Slaves zum neuen Pubset-Master bestimmt oder ob der Master-Wechsel mit einem alternativen Backup-Master unterbunden werden soll.
Wenn kein Backup-Master vorgesehen ist oder die Funktion des Master-Wechsels aus einem anderem Grund scheitert, dann ist eine der folgenden Aktionen nötig:
Alle beteiligten Pubset-Slaves nehmen den Shared-Pubset außer Betrieb und bauen den Shared-Pubset-Verbund komplett neu auf.
Mit dem Kommando SET-PUBSET-ATTRUBUTES wird die Erlaubnis für einen nachträglichen Master-Wechsel gegeben und dieser mit dem Kommando IMPORT-PUBSET SHARER=*MASTER(MASTER-CHANGE=*YES) angestoßen.
Gründe für ein Scheitern des Master-Wechsels können sein:
Der eingetragene Backup-Master ist nicht aktiv.
Eine Verbindung zu einem der beteiligten Pubset-Slaves ist unterbrochen.
Eines der am Shared-Pubset-Verbund beteiligten Systeme verwendet eine nicht-verbundkompatible Version von HIPLEX MSCF oder einen abweichenden Korrekturstand.
Nach einem erfolgreich durchgeführten Master-Wechsel können alle beteiligten Pubset-Slaves normal weiterarbeiten. Der Master-Wechsel selbst läuft für die Benutzer weitestgehend unerkannt ab.