Der Einsatz von HIPLEX MSCF setzt die Existenz eines von BCAM verwalteten Netzes voraus.
Das Transportsystem BCAM dient HIPLEX MSCF als Basis für die Abwicklung elementarer Funktionen der Nachrichtenübertragung (siehe Handbuch „BCAM“ [13]).
Protokolle
HIPLEX MSCF beherrscht alle Transportprotokolle, die BS2000 OS DX bzw. BCAM kennt (ISO-Klasse-4-, NEA-Protokolle und TCP/IP).
Zur Vermeidung von Verbund-Problemen sollten alle BCAM-Steuerdateien (z.B. APPLICATION-TABLE, SOCKETHOST-TABLE und PROCESSOR-TABLE, siehe Handbuch openNet Server [13]), im Home-Pubset katalogisiert sein.
Unabhängige Überwachungsverbindungen
Bei der Überwachung des Partners über zwei unabhängige Überwachungsverbindungen kann auch ohne Shared-Pubset ein Partnerausfall automatisch erkannt werden. Dazu muss zusätzlich die partnerspezifische Einstellung RECOVERY-START=*AUTOMATIC spezifiziert werden.
Die Überwachungsverbindungen müssen als physikalisch unabhängige Kommunikationspfade (redundante Netztopologie) jeweils zwischen den gleichnamigen MSCF-Applikationen $MRSAPP4 und $MRSAPP5 auf dem lokalen Rechner und auf dem Partner-Rechner mittels BCMAP-Kommandos konfiguriert werden. Die Kommunikationspfade sollten möglichst über geographisch unterschiedliche Routen laufen, damit nicht beide gleichzeitig durch ein und dasselbe äußere Ereignis gestört werden können (z.B. Bauarbeiten).
Durch die Angabe NUMBER-OF-CTRL-CONN=2 in den Kommandos START-MSCF-CONNECTION bzw. MODIFY-MSCF-CONNECTION wird bestätigt, dass zwei physikalisch unabhängige Überwachungsverbindungen zwischen den Partnern eingerichtet wurden. Die Angabe kann durch MSCF nicht verifiziert werden. Eine falsche Angabe kann daher zu einer fehlerhaften Ausfallerkennung und Verlust der Datenintegrität führen.
Abgestimmte Netzgenerierung
Aus Sicht von HIPLEX MSCF ist die Netzgenerierung dann abgestimmt, wenn jeweils Processor- und Host-Name jedes am Verbund beteiligten Rechners übereinstimmen und der entsprechende Name auch auf den Partner-Rechnern verwendet wird. Bei mehreren Routen zwischen zwei Rechnern wird empfohlen, mit Alternativ-Router zu arbeiten (siehe Handbuch „openNet Server - BCAM“ [13]), nicht jedoch mit unterschiedlichen Processor-Namen (siehe auch Kapitel „Rechneridentifikation“).
Aus Sicherheitsgründen sollten MSCF-Verbindungen über ein Netz hergestellt werden, das die Systemadministration als sicher einstuft. Die Konfiguration der MSCF-Verbindung über eine bestimmte Verbindung, erfolgt über die Definition des Leitungsanschlusses, des Processor-Namens und des entsprechenden Routen-Namens zu den Partnern. Details zur Konfiguration entnehmen Sie bitte ebenfalls dem Handbuch "openNet Server - BCAM"[13].
Startzeitpunkt
Wird HIPLEX MSCF während des BS2000-Startups gestartet (CREATION-TIME= *BEFORE-SYSTEM-READY), so muss auch BCAM während des BS2000-Startups gestartet werden. Letzteres kann durch den Startup-Parameterservice (Parametersatz BCAM) veranlasst werden, z.B.:
/BS2000 PARAMS /BEGIN BCAM DCSTART <dcstart parameter>, LWRESD=NO /EOF /END PARAMS
Wartezeit für MSCF beim Kommando BCEND
Mit dem BCAM-Kommando BCTIMES, Operand MAX-MSCF-DELAY können Sie eine Verzögerungszeit für die Beendigung von MSCF bei Eingabe des BCAM-Kommandos BCEND einstellen, siehe Handbuch „openNet Server - BCAM“ [13]. Standardwert ist 60 Sekunden.
Informationen über den aktuellen Wert erhalten Sie mit dem BCAM-Kommando SHOW-BCAM-ATTRIBUTES SELECT=*TIMER(*ALL / MAX-MSCF-DELAY)
Die Auswirkungen von BCEND auf MSCF sind im Kapitel "Beenden von HIPLEX MSCF " beschrieben.