HIPLEX MSCF wird entweder direkt über das Kommando STOP-SUBSYSTEM MSCF beendet oder aber indirekt im Zuge der Shutdown-Bearbeitung. Das Beenden hat nicht nur den Abbau der MSCF-Verbindungen zur Folge, es führt auch zum Austritt des Rechners aus allen Verbunden sowie zum Exportieren aller Shared-Pubsets. War der Rechner Master-Rechner für einen Shared-Pubset, so wird von den im Verbund verbleibenden Rechnern ein Master-Wechsel durchgeführt. Ein XCS-Rechner tritt aus dem XCS-Verbund aus.
Wird HIPLEX MSCF auf einem Rechner beendet, so verlässt der Rechner den MSCF-Verbund und alle Tasks des Rechners müssen ihre HIPLEX-MSCF-Ressourcen zurückgeben. Aus diesem Grund wird das Kommando STOP-SUBSYSTEM abgewiesen, solange noch Shared-Pubsets auf dem Rechner importiert sind (Meldung MCS0021 wird ausgegeben). Bei einer zwangsweisen MSCF-Beendigung über das Kommando STOP-SUBSYSTEM MSCF, SUBSYSTEM-PARAMETER='FORCED=YES' werden vor dem Verbundaustritt des Rechners alle Benutzer-Tasks per CANCEL-JOB abgebrochen, die noch Shared-Pubset- oder XCS-Funktionalität nutzen.
Das Subsystem MSCF beendet sich erst nach dem vollständigen Abbau der gesamten HIPLEX-MSCF-Funktionalität auf dem Rechner, denn nur dann ist ein Wiedereintritt des Rechners in den Verbund zulässig.
Beendet sich HIPLEX MSCF (z.B. wegen eines Konfigurationsfehlers) selbstständig, bricht also der Rechner seine Teilnahme am Verbund ab, so werden alle Shared-Pubsets zwangsweise exportiert. Nach erfolgreichem Exportieren des letzten Shared-Pubsets wird HIPLEX MSCF entladen.
Hinweise
Bei schwer wiegenden Fehlern innerhalb des MSCF-Verbunds beendet sich das Subsystem MSCF selbstständig. Der Rechner bricht seine Teilnahme am Verbund ab, die Meldung MCS1003 wird ausgegeben.
Der MSCF-Verbund basiert auf BCAM. BCAM-Kommandos können sich deshalb auf HIPLEX MSCF auswirken.
Die Ausführung des BCAM-Kommandos BCOUT führt für einen dem MSCF-Verbund angehörenden Rechner zum Verlust aller Verbindungen zu diesem Rechner.
Bei Ausführung des BCAM-Kommandos BCEND prüft BCAM, ob MSCF noch läuft. Wenn dies der Fall ist, dann wird zuerst das Kommando /STOP-SUBSYSTEM MSCF, SUBSYSTEM-PARAMETER='FORCED=YES' ausgeführt. Anschließend verzögert BCAM die weitere Bearbeitung von BCEND, bis sich entweder MSCF beendet hat oder bis die im BCAM-Parameter MAX-MSCF-DELAY (siehe "BCAM-Abhängigkeiten") eingestellte maximale Wartezeit abgelaufen ist.
Die Ausführung der BCAM-Kommandos kann die Funktionalität der dafür vorgesehenen Kommandos STOP-MSCF-CONNECTION und STOP-SUBSYSTEM MSCF unterlaufen und schwer wiegende Folgen für das Mehrrechnersystem und insbesondere für einen etwaigen Shared-Pubset- oder XCS-Betrieb haben (Risiko einer fehlerhaften Ausfallerkennung, DVS-Returncodes auf den Slave-Rechnern eines Shared-Pubsets).
Beim Beenden von HIPLEX MSCF werden alle Shared-Pubsets exportiert, die Freigabe der DVS-Belegung wird abgewartet. Dies kann dazu führen, dass das Entladen von MSCF aufgehalten wird, wenn Anwendungen, die den Shared-Pubset belegen, nicht vor dem Shutdown beendet werden.
UTM-Anwendungen, die Shared-Pubsets verwenden, werden automatisch durch die Exportverarbeitung beendet.Wenn auf mehreren Rechnern innerhalb eines MSCF-Verbundes eine Systembeendigung (Shutdown) erfolgen soll, dann wird empfohlen, diesen Shutdown nacheinander an den betroffenen Rechnern einzuleiten und die Fertigstellung des eingeleiteten Shutdown abzuwarten, um den restlichen (noch) im MSCF-Verbund verbleibenden Rechnern die Möglichkeit geben, den Austritt des zu beendenden Rechners aus dem MSCF-Verbund zu registrieren.
Wenn mehrere Rechner eines MSCF-Verbundes quasi gleichzeitig beendet werden, dann kann dies zu Blockaden beim Beenden eines Systems führen. Solche Blockaden werden erst durch die Beendigung von BCAM mit nachfolgender abnormaler Terminierung von HIPLEX MSCF (nach 10 Minuten) aufgelöst.