Mit den nachfolgend beschriebenen Parametern lässt sich das Verhalten von MSCF steuern. Da innerhalb einer BS2000-Session mehrere MSCF-Sessions (Zeitraum zwischen START-SUBSYSTEM MSCF und STOP-SUBSYSTEM MSCF) stattfinden können, wird unterschieden zwischen Systemparametern (Festlegung im Startup-Parameterservice), die für die gesamte BS2000-Session gelten, und solchen Parametern, die lediglich für eine MSCF-Session gültig sind (Festlegungen über das Kommando SET-MSCF-ENVIRONMENT).
Systemparameter MCXSPXCS
MCXSPXCS legt fest, ob einem Rechner grundsätzlich die Möglichkeit zuerkannt wird, an einem XCS-Verbund teilzunehmen und wie die XCS-Ressourcen verwaltet werden.
MCXSPXCS=N (Standardwert)
Der Rechner ist nicht zur Teilnahme am XCS-Verbund vorgesehen.
Die XCS-Ressourcen werden lokal verwaltet und nur der lokale Rechner kann auf XCS-Ressourcen zugreifen.
Die lokale Verwaltung der Ressourcen kann nicht beendet werden. Der Rechner kann deshalb für die Dauer der gesamten BS2000-Sitzung an keinem XCS-Verbund teilnehmen. Ein in der MSCF-Konfigurationsdatei angegebener XCS-Name führt zum Abbruch des MSCF-Starts.MCXSPXCS=Y
Der Rechner ist zur Teilnahme am XCS-Verbund vorgesehen.
XCS-Ressourcen können global oder lokal verwaltet werden. Sie können erst zugeteilt werden nachdem das Subsystem MSCF gestartet wurde. Ob XCS-Ressourcen lokal oder global verwaltet werden hängt vom Wert des Operanden XCS-NAME des Kommandos SET-MSCF-ENVIRONMENT in der MSCF-Konfigurationsdatei ab.XCS-NAME=*NONE (Voreinstellung)
MSCF wird im CCS-Modus gestartet. Die XCS-Ressourcen werden lokal verwaltet und nur der lokale Rechner hat Zugriff auf die XCS-Ressourcen. Ab jetzt wird wie bei MCXSPXCS=N verfahren.XCS-NAME=*SUSPEND
MSCF wird im CCS-Modus gestartet.
Es werden keine XCS-Ressourcen zugeteilt. Das Subsystem MSCF kann aber in der aktuellen BS2000-Sitzung auch im XCS-Modus gestartet werden, um einen Zugriff auf die XCS-Ressourcen zu erhalten.XCS-NAME=<alphanum-name 1..8>
MSCF wird im XCS-Modus gestartet.
XCS-Ressourcen werden global verwaltet. Alle XCS-Teilnehmer haben Zugriff auf die Ressourcen.
MCXSPXCS=V
Der Rechner ist zur Teilnahme am XCS-Verbund vorgesehen.
XCS-Ressourcen werden ausschließlich global verwaltet. Sie werden nur zugeteilt, wenn das Subsystem MSCF im XCS-Modus gestartet ist. Innerhalb einer BS2000-Sitzung ist ein beliebiger Wechsel zwischen CCS- und XCS-Modus möglich.
MSCF-Konfigurationsparameter ABORT-LIMIT
Der MSCF-Konfigurationsparameter ABORT-LIMIT legt fest, wie lange ein Abbruch der Verbundteilnahme (ABORT) für einen Shared-Pubset- oder XCS-Verbund auf dem lokalen Rechner dauern darf. Kann der Abbruch innerhalb des festgelegten Zeitintervalls nicht durchgeführt werden, so wird die BS2000-Session auf dem Rechner beendet. Auf diese Art kann im restlichen Teil des Verbunds die FAIL-Rekonfiguration zu Ende geführt und die Funktionsfähigkeit des Verbunds wieder hergestellt werden. Der Abbruch der Verbundteilnahme kann z.B. dann nicht zu Ende geführt werden, wenn vom System beim Export die DVS-Belegung eines Pubsets nicht aufgehoben werden kann.
Standardmäßig wird keine Beendigung der ABORT-Verarbeitung durch abnormale Systembeendigung erzwungen.
MSCF-Konfigurationsparameter HOST-PRIORITY
Bei automatischem Start der Rekonfiguration (siehe MSCF-Rekonfigurationsparameter Globale Steuerungsparameter (HIPLEX MSCF V21.0 2021-11, #61) =*AUTOMATIC / *SECURE) wird bei Verbindungsausfall im XCS-Verbund auf einem der beiden vom Verbindungsausfall betroffenen Rechner HIPLEX MSCF automatisch abnormal terminiert, um durch eine FAIL-Rekonfiguration die Funktionsfähigkeit des Rechnerverbunds wieder voll herzustellen. Über den Konfigurationsparameter HOST-PRIORITY kann ein Rechner im XCS-Verbund nach seiner Wichtigkeit klassifiziert und dadurch die Auswahl des beim Verbindungsausfall terminierenden Rechners gesteuert werden: Die HOST-PRIORITY bestimmt die Rangfolge der Rechner gemäß ihrer Wichtigkeit. Rechner mit einem kleineren Zahlenwert von HOST-PRIORITY haben eine höhere Priorität. Standardmäßig ist der Wert 16 zugeordnet. Ist den beiden vom Verbindungsausfall betroffenen Rechnern eine unterschiedliche HOST-PRIORITY zugeordnet, so wird der Rechner mit dem höheren Zahlenwert von HOST-PRIORITY aus dem XCS-Verbund entfernt. Haben die beiden Rechner die gleiche HOST-PRIORITY, so wird der Rechner aus dem XCS-Verbund entfernt, der dem Verbund später beigetreten ist (höherer Wert von JOINING ORDER). Bei gleichzeitigem Ausfall mehrerer Verbindungen wird dieser Vorgang nacheinander für jede ausgefallene Verbindung einzeln durchgeführt.
MSCF-Konfigurationsparameter LEAVE-LIMIT
Der MSCF-Konfigurationsparameter LEAVE-LIMIT legt fest, nach Ablauf welcher Zeitspanne der koordinierte Austritt eines Rechners aus einem XCS-Verbund (LEAVE) in einen Abbruch der Verbundteilnahme (ABORT) umgewandelt wird. Ziel dieser Umwandlung ist, Situationen zu entschärfen, die den Abschluss des Austritts verzögern oder verhindern, und auf diese Art den restlichen XCS-Verbund wieder in einen funktionsfähigen Zustand zu versetzen. LEAVE-LIMIT beginnt erst nach Beendigung der Benutzertasks bzw. nach Ablauf von "USER-TERM-LIMIT" zu laufen.
Standardmäßig wird ein koordinierter Austritt nicht in einen Abbruch umgewandelt.
MSCF-Konfigurationsparameter LOCAL-PASSWORD
Die Angabe des MSCF-Konfigurationsparameters LOCAL-PASSWORD kann den Rechner über ein Kennwort vor dem Aufbau von illegalen MSCF-Verbindungen schützen. Das für den Rechner festgelegte Kennwort muss angegeben werden, wenn außerhalb der MSCF-Konfigurationsdatei das Kommando START-MSCF-CONNECTION für CCS-Verbindungen verwendet wird. Der Partner-Rechner muss das Kennwort ebenfalls kennen; andernfalls kommt keine (CCS-)Verbindung zu Stande.
MSCF-Konfigurationsparameter NOTIFY-BY-MAIL
Der MSCF-Konfigurationsparameter NOTIFY-BY-MAIL legt fest, ob in kritischen Situationen Benachrichtigungen per E-Mail an eine Benutzerkennung verschickt werden sollen, siehe Kapitel „E-Mail-Benachrichtigung bei kritischen Zuständen“. Beim Versenden einer E-Mail wird die E-Mail-Adresse aus dem EMAIL-ADDRESS-Feld des entsprechenden Benutzereintrags übernommen.
MSCF-Konfigurationsparameter XCS-NAME
Mit der Angabe eines XCS-Namens wird festgelegt, dass der Rechner am entsprechenden XCS-Verbund teilnehmen soll. Beim Start von HIPLEX MSCF tritt der Rechner in den Verbund ein.
Der MSCF-Konfigurationsparameter XCS-NAME wird über das in der MSCF-Konfigurationsdatei hinterlegte Kommando SET-MSCF-ENVIRONMENT festgelegt. Eine Änderung dieses Konfigurationsparameters im laufenden XCS-Betrieb ist nicht möglich.
MSCF-Konfigurationsparameter TRACE-FILE
Durch Angabe des Operanden TRACE-FILE im Kommando SET-MSCF-ENVIRONMENT wird festgelegt, ob und - wenn ja - in welche Datei die Traces des Subsystems MSCF geschrieben werden. Die MSCF-Traces stellen für die Diagnose von Fehlersituationen eine wichtige Unterlage dar. Über das Kommando MODIFY-MSCF-ENVIRONMENT kann jederzeit die Datei, in die geschrieben wird, neu festgelegt oder das Schreiben in eine Datei unterbunden werden.
MSCF-Konfigurationsparameter FAIL-DETECTION-LIMIT
Über den Konfigurationsparameter FAIL-DETECTION-LIMIT wird festgelegt, innerhalb welcher Zeit (in Sekunden) der Rechner einen Fehler im MSCF-Verbund (wie Partner- oder Verbindungsausfall) erkennen muss. Der festgelegte Wert wird auf ein Vielfaches von 44 aufgerundet, standardmäßig sind 176 Sekunden (= minimaler Wert) festgelegt.
Aus dem FAIL-DETECTION-LIMIT wird die Zeit für die internen Überwachungszyklen abgeleitet (Zykluszeit = aufgerundeter Wert von FAIL-DETECTION-LIMIT / 11).
Ein Rechnerausfall wird durch die Überwachungsmechanismen nach 1-3 Zyklen entdeckt. Bedingt durch die maximale Dauer eines BCAM-Verbindungsaufbaus kann sich bei Ausfall der BCAM-Verbindungen die Zeit jedoch verlängern.
Bei der Festlegung der Fehlererkennungszeit ist zu berücksichtigen, dass unter Sonderbedingungen das Betriebssystem für längere Zeit angehalten wird, siehe Kapitel „Blockade der Plattenüberwachung“. Zu kurze Überwachungszyklen führen dann zu einer fehlerhaften Ausfallerkennung. Dies muss unbedingt vermieden werden.
Zur Vermeidung einer fehlerhaften Ausfallerkennung bzw. Systembeendigung ist es notwendig, RECOVERY-START=*BY-OPERATOR / *CONSISTENT-BY-OPERATOR / *SECURE festzulegen oder für FAIL-DETECTION-LIMIT einen entsprechend hohen Wert anzugeben. Dabei ist zu berücksichtigen, dass der Rechner nicht länger angehalten werden darf als das Ergebnis von FAIL-DETECTION-LIMIT / 11 ausmacht.
Nach einer automatischen Ausfallerkennung wird noch ein Sicherheitsintervall abgewartet, bevor die Ausfallrekonfiguration gestartet wird. Dem als ausgefallen betrachteten Partner-Rechner wird damit Gelegenheit zu einer Notfallterminierung gegeben, um einer „fehlerhaften Ausfallerkennung“ vorzubeugen.
Der Wert von FAIL-DETECTION-LIMIT sollte kleiner als die Wiederanlaufzeit (ca. 15 Minuten) eines BS2000-Systems gewählt werden. Der Grund hierfür ist, dass der Ausfall eines Rechners auf dem Partner-Rechner erkannt und eine Fail-Rekonfiguration durchgeführt werden muss. Erst wenn die Fail-Rekonfiguration auf dem Partner-Rechner abgeschlossen ist, kann der (ausgefallene) Rechner in seiner neuen BS2000-Session in einen CCS-, Shared-Pubset- oder XCS-Verbund eintreten.
Wird der Rechner nach seinem Ausfall sogleich wieder gestartet und möchte er in den Verbund eintreten, obwohl die Fail-Rekonfiguration auf dem Partner-Rechner noch nicht abgeschlossen ist, so ist dem Partner-Rechner der Host-Name des Rechners (noch) bekannt. Dem Rechner wird deshalb das Eintreten in den Verbund verweigert (Meldung MCS1005 bzw. MCS0009).
MSCF-Konfigurationsparameter RECOVERY-START
Mit dem Konfigurationsparameter RECOVERY-START kann das Verhalten der Partnerüberwachung in vielfältiger Weise beeinflusst werden:
Ein- und Ausschalten der MSCF-Partnerüberwachung
Partner können mit MSCF durch die Verbindungsüberwachung und die Plattenüberwachung überwacht werden. Ein Partner wird überwacht, wenn die Überwachung über mindestens einen der beiden Überwachungspfade eingeschaltet ist (Ausnahmen siehe unten):
Verbindungsüberwachung: Sie wird im Allgemeinen beim Aufbau einer CCS-Verbindung eingeschaltet und beim Abbau (nicht bei Störung) einer CCS-Verbindung ausgeschaltet.
Plattenüberwachung: Sie wird beim Import eines gemeinsamen Shared-Pubsets eingeschaltet und beim Export des letzten gemeinsamen Shared-Pubsets ausgeschaltet.
XCS-Partner werden immer überwacht. Ein Ausschalten der Überwachung eines XCS-Partners ist nur durch Ausscheiden des Partners aus dem XCS-Verbund möglich.
Ein CCS-Partner, der kein Shared-Pubset-Partner ist, wird überwacht, wenn zu ihm eine CCS-Verbindung mit RECOVERY-START !=*STD aufgebaut ist. Solange kein gemeinsames Shared-Pubset mit dem Partner importiert wurde, kann durch Änderung von RECOVERY-START auf =*STD bzw. !=*STD die Überwachung aus- bzw. eingeschaltet werden.
Ein Shared-Pubset-Partner wird nicht überwacht, solange keine CCS-Verbindung zu ihm aufgebaut wurde. Mit dem erstmaligen Aufbau einer CCS-Verbindung zu einem Shared-Pubset-Partner wird die Verbindungsüberwachung und die Plattenüberwachung gemeinsam eingeschaltet. Ebenso wird die Verbindungsüberwachung und die Plattenüberwachung gemeinsam eingeschaltet, wenn für einen CCS-Partner mit RECOVERY-START=*STD erstmals ein mit dem lokalen Rechner gemeinsames Shared-Pubset importiert wird. Zum Ausschalten der Überwachung müssen beide Überwachungspfade durch Abbau der CCS-Verbindung und Export aller Shared-Pubsets abgebaut werden.
Verbot des automatischen Starts einer Fail-Rekonfiguration
Wenn die Partnerüberwachung den Ausfall eines Partners erkannt hat, ist es zur Wiederherstellung der Verbundfunktionalität erforderlich, für den ausgefallenen Rechner eine Fail-Rekonfiguration durchzuführen. Die Einstellung des Konfigurationsparameters RECOVERY-START legt fest, ob der Start dieser Fail-Rekonfiguration automatisch erfolgt, oder ob MSCF am Bedienplatz die Frage MSC1100 (Keine Aktivitaet des Verbundpartners erkennbar, Ausfall bestaetigen?) stellt und die Fail-Rekonfiguration erst nach Beantwortung der Frage beginnt.
Unabhängig von den RECOVERY-START-Einstellungen wird diese Ausfallfrage auch dann gestellt, wenn gerade ein MSCF-Konfigurationsparameter RECOVERY-START geändert wird.
Ein Verbot des automatischen Starts einer Fail-Rekonfiguration kann mit allgemeiner und/oder partnerspezifischer Wirkung eingestellt werden:
allgemeine Einstellung:
Die allgemeine Einstellung ist für alle Partner gültig. Sie wird mittels der Kommandos SET-MSCF-ENVIRONMENT bzw. MODIFY-MSCF-ENVIRONMENT vorgenommen.partnerspezifische Einstellung:
Die partnerspezifische Einstellung ist nur für einen bestimmten Partner gültig. Sie wird mittels der Kommandos START- bzw. MODIFY-MSCF-CONNECTION vorgenommen.
Die partnerspezifische Einstellung RECOVERY-START=*STD bedeutet, dass für diesen Partner die allgemeine Einstellung wirksam werden soll. Wenn die partnerspezifische Einstellung weder *STD noch gleich der allgemeinen Einstellung ist, dann ergibt sich der für einen Partner wirksame Wert von RECOVERY-START aus der folgenden Tabelle:
erste Einstellung 1 | zweite Einstellung 1 | lokal wirksame Einstellung |
*AUTOMATIC | *BY-OPERATOR | *BY-OPERATOR |
*AUTOMATIC | *CONS-BY-OPERATOR | *CONS-BY-OPERATOR |
*AUTOMATIC | *SECURE | *SECURE |
*BY-OPERATOR | *CONS-BY-OPERATOR | *CONS-BY-OPERATOR |
*BY-OPERATOR | *SECURE | *BY-OPERATOR |
*CONS-BY-OPERATOR | *SECURE | *CONS-BY-OPERATOR |
1Die Kombination von allgemeiner und partnerspezifischer Einstellung resultiert stets in der gleichen lokal wirksamen Einstellung.
Wenn die lokal wirksame Einstellung für einen Partner RECOVERY-START=*BY-OPERATOR / *CONSISTENT-BY-OPERATOR ist, dann darf die Fail-Rekonfiguration nur nach Beantworten der Ausfallfrage MCS1100 gestartet werden; der automatische Start ist verboten. Die Einstellung von RECOVERY-START auf dem Partner ist in diesen Fall ohne Bedeutung.
Wenn die lokal wirksame Einstellung für einen Partner RECOVERY-START=*SECURE ist und der Live-Monitor den Ausfall dieses Partners meldet oder bestätigt, dann startet MSCF die Fail-Rekonfiguration automatisch. Die Einstellung von RECOVERY-START auf dem Partner ist in diesem Fall ohne Bedeutung.
Wenn die lokal wirksame Einstellung für einen Partner RECOVERY-START=*AUTOMATIC ist, dann liegt die Entscheidung über den Start der Fail-Rekonfiguration beim Partner:
Wenn die auf dem Partner wirksame Einstellung für den eigenen Rechner RECOVERY-START=*CONSISTENT-BY-OPERATOR / *SECURE war, dann darf die Fail-Rekonfiguration erst nach Beantworten der Ausfallfrage MCS1100 gestartet werden
Wenn die auf dem Partner wirksame Einstellung für den eigenen Rechner RECOVERY-START=*AUTOMATIC / *BY-OPERATOR war, dann ist ein automatischer Start der Fail-Rekonfiguration erwünscht. Die Partnerüberwachung kann sich jedoch in folgenden Fällen über den Ausfall des Partners nicht sicher sein:
Ausfall des letzten Überwachungspfades, wenn dieser nicht „gleichzeitig“ mit einem weiteren Überwachungspfad ausfällt
Ausfall des Partners während eines SNAPSHOT-Dumps
Ausfall des Partners, während der Cluster Recovery Lock (CRL, siehe Kapitel "Blockade der Plattenüberwachung") gesetzt ist
Wenn einer dieser Fälle vorliegt, dann stellt MSCF ebenfalls die Ausfallfrage MCS1100, und die Fail-Rekonfiguration beginnt erst nach Beantworten der Frage.
Fehlerbehandlung bei Verbindungsausfall im XCS-Betrieb
Fällt zwischen zwei Rechnern im XCS-Verbund die MSCF-Verbindung aus, so ist die Verbundfunktionalität gestört.
Die Maßnahme zur Behebung der Störung wird automatisch getroffen, wenn für beide vom Verbindungsausfall betroffenen Rechner die allgemeine RECOVERY-START-Einstellung *AUTOMATIC und für die partnerspezifische Einstellung für den jeweiligen Partner *AUTOMATIC oder *STD spezifiziert wurde. In diesem Fall wird nach den Regeln, die bei MSCF-Konfigurationsparameter "Globale Steuerungsparameter (HIPLEX MSCF V21.0 2021-11, #61)" beschrieben sind, HIPLEX MSCF auf einem der beiden Rechner abnormal beendet und aus dem XCS-Verbund herauskonfiguriert.
Andernfalls wird die Systembetreuung durch die Meldung MCS1101 aufgefordert, die Verbindungsstörung zu beseitigen.
Steuerung der erlaubten Systemabbrüche
Siehe hierzu auch Kapitel „Abnormale Beendigung von HIPLEX MSCF“.
Systembeendigungen MCS1300 (um eine irrtümliche Ausfallerkennung durch die Partner zu verhindern), können allgemein und partnerspezifisch verboten werden. Die allgemeine bzw. partnerspezifische Einstellung eines Rechners *BY-OPERATOR verhindert diesen Systemabbruch bei allen Partnern bzw. bei einem bestimmten Partner wegen irrtümlicher Ausfallerkennung durch den lokalen Rechner.
Die Einstellung *CONSISTENT-BY-OPERATOR verhindert diesen Systemabbruch zusätzlich beim lokalen Rechner wegen irrtümlicher Ausfallerkennung durch einen beliebigen bzw. einen bestimmten Partner.Der Systemabbruch MCS1301 (um die Rekonfiguration bei den MSCF-Partnern zu ermöglichen) wird nur ausgeführt, wenn die allgemeine RECOVERY-START-Einstellung des Rechners *AUTOMATIC / *SECURE ist.
MSCF-Konfigurationsparameter USER-TERM-LIMIT
Der Konfigurationsparameter legt die Zeit fest, die den Benutzer-Tasks ab dem Zeitpunkt der Einleitung der XCS-Beendigung zur Verfügung steht, um sich zu beenden. Spätestens nach Ablauf dieser Zeitspanne werden die registrierten Funktionen beendet.
Falls in Ausnahmesituationen die XCS-Funktionalität lokal nicht vollständig abgebaut werden kann, wird das Subsystem MSCF erst bei Systembeendigung entladen.
MSCF-Konfigurationsparameter NUMBER-OF-SERVERS
Der Konfigurationsparameter bestimmt die Anzahl der Servertasks, die auf dem Rechner bereitgestellt werden sollen. Standardmäßig werden 4 Servertasks bereitgestellt, maximal können 10, minimal 2 Servertasks angefordert werden. Die Anzahl kann sich im Verlauf der MSCF-Session ständig erhöhen. Bei Bedarf erzeugt MSCF zusätzliche Servertasks; beendet sie aber auch wieder, wenn sie nicht mehr benötigt werden.
Die über das Kommando START-SUBSYSTEM festgelegte Servertask-Anzahl hat Vorrang vor der über Kommando SET-MSCF-ENVIRONMENT festgelegten Anzahl.
MSCF-Konfigurationsparameter SERVER-TASK-LIMIT
Eine übermäßige Last durch eine zu große Anzahl der MSCF-Servertasks kann ein System (z.B. über PAGING SATURATION) zum Stillstand bringen. Um dies zu verhindern, wird die Anzahl der MSCF-Servertasks begrenzt. Der Wert des MSCF-Konfigurationsparameters SERVER-TASK-LIMIT („MAXIMUM“ bei der SM2-Ausgabe unter „TASK LIMITS”) dient dafür als Maßzahl.
Eine MSCF-Servertask ist im Zustand „occupied“, wenn sie sich in einer (rechnerübergreifenden) Deadlock-gefährdeten Situation befindet. Wann genau dies zutrifft, wird von den MSCF-Servertasks nutzenden Systemkomponenten entschieden.
Überschreitet die Anzahl der MSCF-Servertasks im Zustand „occupied“ eine obere Grenze (= 75% von SERVER-TASK-LIMIT; „FLOW SET“ bei der SM2-Ausgabe unter TASK LIMITS), so wird der Status des lokalen Rechners auf „FLOW“ gesetzt. Partner-Rechner werden entsprechend informiert und senden daraufhin nur noch zwingend erforderliche (die „occupation“ eines MSCF-Servertasks auflösende) Nachrichten an den Rechner. Hat sich die Anzahl der MSCF-Servertasks im Zustand „occupied“ wieder auf eine untere Grenze reduziert (= 50% von SERVER-TASK-LIMIT; „FLOW RESET“ bei der SM2-Ausgabe unter „TASK LIMITS“), so wird der Status „FLOW“ aufgehoben. Die Partner-Rechner werden über die geänderte Situation informiert und senden daraufhin wieder Nachrichten beliebigen Typs an den Rechner.
Da sich die Begrenzung an der Anzahl der MSCF-Servertasks im Zustand „occupied“ orientiert, können bei stoßartiger Spitzenlast auch mehr Servertasks erzeugt werden als im Konfigurationsparameter SERVER-TASK-LIMIT angegeben sind.