Der Abbau oder Ausfall einer MSCF-Verbindung (Meldungen MCS0014 und MCS0015 werden ausgegeben) zwischen den Teilnehmern eines Shared-Pubset-Verbunds beeinträchtigt die Verbundfunktionalität. Von unmittelbarer Auswirkung auf die Nutzer eines Shared-Pubsets ist nur die Unterbrechung der MSCF-Verbindung zwischen Master- und Slave-Rechner. In diesem Fall wird der MRSCAT-Eintrag des Pubsets am Slave-Rechner in den Zustand QUIET versetzt. DVS-Metaoperationen am Slave-Rechner können nicht ausgeführt werden, solange die Verbindung zum Master-Rechner nicht wieder aufgebaut ist. Der Verbindungsverlust zwischen zwei Slave-Rechnern ist für die anderen Teilnehmer des Shared-Pubset-Verbunds ohne Belang. Der Pubset bleibt für die Rechner uneingeschränkt verfügbar.
Ist der Shared-Pubset ein SM-Pubset, so kann es bei einem Verbindungsausfall während einer Konfigurationsänderung zu Inkonsistenzen zwischen dem auf den Slave-Rechnern im MRSCAT mitgeführten Abbild der Pubset-Konfiguration und der vom Master-Rechner aktualisierten Pubset Configuration File kommen. Betroffen hiervon sind lediglich die Auskunftsfunktionen, die veraltete Informationen anzeigen. Mit dem Kommando RESUME-PUBSET-RECONFIGURATION kann nach dem Wiederaufbau der MSCF-Verbindung die Pubset-Konfiguration eines SM-Pubsets im MRSCAT anhand der Information aus der Pubset Configuration File aktualisiert werden.
Neben der Beeinträchtigung der Verfügbarkeit des Pubsets wirkt sich der Verbindungsverlust zwischen Master- und Slave-Rechner auch auf die Rekonfigurationsfähigkeit und die Überwachung des Shared-Pubset-Verbunds aus. Folgende Fälle sind zu unterscheiden:
Export des Pubsets ohne Master-Wechsel
Ist die MSCF-Verbindung zwischen Master- und Slave-Rechner unterbrochen, so wird der Export des Pubsets auf dem exportierenden Rechner ohne Mitwirkung des Partner-Rechners durchgeführt.
Wird der Pubset auf dem Slave-Rechner exportiert, so werden seine Locks auf dem Master-Rechner nicht freigegeben. Wird der Pubset vom Master-Rechner exportiert, so bleibt er auf dem Slave-Rechner importiert.
Am Ende des Exports vermerkt der Rechner den Status „EXPORT“ in den ihm zugeordneten Kontrollblöcken der Watch-Dog-Datei und gibt den Pubset frei. Die Plattenüberwachung des Partner-Rechners kann daraus die Statusänderung des Rechners erkennen und die bislang unterbliebenen Maßnahmen nachziehen:
Beim Export durch einen Slave-Rechner setzt der Master-Rechner die Locks des Slave-Rechners durch eine Slave-Crash-Rekonfiguration zurück, beim Export durch den Master-Rechner exportiert der Slave-Rechner den Pubset ebenfalls.Kann der EXPORT-Status nicht in die Watch-Dog-Datei geschrieben werden (Ursache: Schreibfehler oder Volume wurde entzogen), so kann der Partner-Rechner den erfolgten Pubset-Export erst dann erkennen, wenn die MSCF-Verbindung wieder aufgebaut ist. Erst dann kann der Master-Rechner die Locks des Slave-Rechners zurücksetzen bzw. der Slave-Rechner den Pubset exportieren.
Master-Wechsel wegen Export oder Ausfall
Das Verhalten beim Master-Wechsel, ausgelöst durch Export mit Master-Wechsel oder Ausfall des Master-Rechners, entspricht dem Verhalten bei nicht voll vermaschtem Verbund und ist im Kapitel „Ausfall eines Teilnehmers im Shared-Pubset-Verbund“ bzw. „Abbau des Shared-Pubset-Verbunds“) beschrieben.
Wartezeit auf Wiederherstellung der MSCF-Verbindung
Will eine Task auf ein Pubset im Zustand QUIET zugreifen (siehe Kapitel „Verbindungsverlust im LCS-/CCS-Verbund“), so wartet sie zunächst darauf, dass die MSCF-Verbindung wiederhergestellt wird. Die maximale Wartezeit wird über die Operanden BATCH-WAIT-TIME und DIALOG-WAIT-TIME der Kommandos ADD-MASTER-CATALOG-ENTRY bzw. MODIFY-MASTER-CATALOG-ENTRY festgelegt bzw. geändert. Standardwerte sind 28800 Sekunden (=8 Stunden) für Stapelaufträge und 30 Sekunden für Dialogaufträge.
Falls die Task nach 600 Sekunden immer noch wartet, wird an der Bedienstation die Meldung DMS03A8 ausgegeben, um die Systembetreuung auf den Verbindungsausfall aufmerksam zu machen und ihm die Möglichkeit zu geben, den Wartezustand vorzeitig zu beenden. Im Regelfall erkennt die Task Zustandsänderungen selbstständig, zieht die Frage zurück und läuft weiter: Ist der Pubset wieder verfügbar, so wird die laufende Operation normal fortgesetzt, ist der Pubset exportiert worden und ist die Meldung DMS03A8 dahingehend beantwortet worden, dass die Verarbeitung abgebrochen werden soll, oder ist die Wartezeit abgelaufen, so wird die laufende Operation abgebrochen und eine Meldung (zumeist DMS0502) ausgegeben.
Hat der Verbindungsausfall interne Abläufe des Systems an ungünstiger Stelle unterbrochen, so kann es vorkommen, dass die Meldung unbedingt beantwortet werden muss, damit die Task weiterlaufen kann, auch dann, wenn die Verbindung zwischenzeitlich wiederhergestellt oder der Pubset exportiert worden ist. Um beispielsweise im unbedienten Betrieb zu vermeiden, dass die zu beantwortende Meldung DMS03A8 überhaupt ausgegeben wird, empfiehlt es sich, beide Wartezeiten im MRSCAT-Eintrag auf weniger als 600 Sekunden einzustellen.