Betrieb ohne Master-Wechsel
Wird das Kommando SET-PUBSET-ATTRIBUTES mit BACKUP-MASTER=*NONE, ALTERNATE-BACKUP=*NONE ausgeführt, so wird ein Master-Wechsel generell ausgeschlossen (unabhängig vom Operanden MASTER).
Gezielter Master-Wechsel zwischen zwei Rechnern
Durch das Kommando SET-PUBSET-ATTRIBUTES mit MASTER=<sysid1>,BACKUP-MASTER=<sysid2>,ALTERNATE-BACKUP=*NONE (und entsprechende Handhabung des Kommandos IMPORT-PUBSET) wird erreicht, dass ohne explizite Eingriffe nur die Rechner mit <sysid1> und <sysid2> Master-Rechner eines Shared-Pubsets werden können.
Ist zum Zeitpunkt eines Master-Wechsels <sysid1> der Master-Rechner und <sysid2> aktiver Slave-Rechner des Shared-Pubsets, so ist <sysid2> der Backup-Master und wird durch den Master-Wechsel zum neuen Master-Rechner. Ist umgekehrt <sysid2> der Mas-ter-Rechner und <sysid1> aktiver Slave-Rechner, so ist <sysid1> der Backup-Master, der beim Ausfall von <sysid2> durch den Master-Wechsel zum neuen Master-Rechner wird. Die Masterrolle wird also alternierend von den beiden Rechnern eingenommen. Ist einer der beiden Rechner der Master-Rechner, der andere jedoch nicht aktiver Slave-Rechner, so findet kein Master-Wechsel statt. Durch Angabe von MASTER-CHANGE=*YES in den Kommandos EXPORT-PUBSET bzw. IMPORT-PUBSET kann in Ausnahmesituationen ein dritter Rechner die Master-Rolle übernehmen.
Betrieb mit überwachten und nicht-überwachten Partnern
Die Partnerüberwachung in einem Shared-Pubset-Verbund erfolgt partnerbezogen (siehe "Shared-Pubset-Verbund "). Die Partner werden dazu in zwei Kategorien eingeteilt: in „überwachte Partner“ und „nicht-überwachte Partner“.
Überwacht werden nur solche Shared-Pubset-Partner zu denen eine CCS-Verbindung besteht oder zu irgendeinem Zeitpunkt im Laufe der aktuellen MSCF-Session bestanden hat. Alle anderen Partner-Rechner werden nicht überwacht (siehe auch Abschnitt „Ein- und Ausschalten der MSCF-Partnerüberwachung“ (Globale Steuerungsparameter )).
Zwischen Rechnern, die zueinander in einer Master-Slave-Beziehung stehen, muss eine CCS-Verbindung vorhanden sein, die Rechner überwachen sich also gegenseitig. Auch zwischen Rechnern, die zueinander als Backup-Master und Slave in Beziehung stehen, sollte eine CCS-Verbindung bestehen, da sonst kein Master-Wechsel möglich ist.
Zwischen Rechnern, die bezüglich aller gemeinsamen Shared-Pubsets zueinander ausschließlich in einer Slave-Slave-Beziehung stehen, muss keine CCS-Verbindung bestehen. Diese Rechner überwachen sich dann nicht und können deshalb unabhängig voneinander, also dezentral bedient werden. Das folgende Beispiel beschreibt eine solche Konfiguration, in der zwei zentral bediente Rechner abwechselnd Master-Rechner und Backup-Master und andere, dezentral bediente Rechner, immer nur Slave-Rechner der Shared-Pubsets sind.
Beispiel
Die Rechner R1 und R2, auf denen die Produktion abläuft werden zentral bedient. Sie sind abwechselnd Master-Rechner und Backup-Master für die Shared-Pubsets A und B. Die dezentral bedienten Rechner S1 und S2 sind Abteilungsrechner oder Testanlagen; zeitweise muss von diesen Rechnern auf zentrale Daten, die auf den Shared-Pubsets A und B liegen, zugegriffen werden.
Bezüglich der beiden Shared-Pubsets bilden alle vier Rechner Shared-Pubset-Verbunde. Um eine erfolgreiche Durchführung des Master-Wechsels zu ermöglichen, müssen zwischen dem Rechner R1 und allen anderen Rechnern sowie zwischen dem Rechner R2 und allen anderen Rechnern CCS-Verbindungen bestehen, nicht aber zwischen den Rechnern S1 und S2. Im Beispiel besteht zwischen S1 und S2 keine CCS-Verbindung, sie überwachen sich also nicht. Ein Ausfall von S2 hat keine Auswirkung auf S1 (und umgekehrt). Insbesondere bleibt die Shared-Pubset-Funktionalität mit R1 und R2 erhalten.
Anders ist die Situation wenn eine CCS-Verbindung zwischen S1und S2 besteht. Die Rechner überwachen sich dann gegenseitig, und auf einen Ausfall von S2 muss S1 mit dem Start einer Fail-Rekonfiguration reagieren.
Unterbleibt dies, weil z.B. die Ausfallfrage MCS1100 nicht beantwortet wird, so ist ein Import der Pubsets A und B durch den Rechner S2 nach dessen Neustart nicht möglich. Wird die Fail-Rekonfiguration jedoch durchgeführt, und S2 stellt sich nachträglich als nicht ausgefallen heraus, wird MSCF auf S1 abnormal beendet. Bei einem Betrieb ohne Partnerüberwachung zwischen S1 und S2 können diese Komplikationen nicht auftreten.