Mode without master change
If the command SET-PUBSET-ATTRIBUTES with BACKUP-MASTER=*NONE, ALTERNATE-BACKUP=*NONE is executed, a master change is fundamentally precluded (irrespective of the MASTER operand).
Targeted master change between two processors
The command SET-PUBSET-ATTRIBUTES with MASTER=<sysid1>,BACKUP-MASTER=<sysid2>,ALTERNATE-BACKUP=*NONE (and corresponding handling of the IMPORT-PUBSET command) can be used to ensure that, without explicit actions, only the processors with <sysid1> and <sysid2> can become master processors of a shared pubset. If sysid1 is the master processor and sysid2 the active slave processor of the shared pubset at the time of a master change, <sysid2> is the backup master and becomes the new master as a result of the master change. If conversely <sysid2> is the master processor and <sysid1> the active slave processor, <sysid1> is the backup master which becomes the new master as a result of a master change if <sysid2> crashes. In other words, the role of master is assumed alternately by the two processors. If one of the two processors is the master processor but the other is not an active slave processor, no master change takes place. The specification of MASTER-CHANGE=*YES in the commands EXPORT-PUBSET and IMPORT-PUBSET ensures that in emergency situations, a third processor can assume the master role.
Operation with relevant and non-relevant partners
The partner monitoring function in a shared pubset network is partner-based (see "Shared pubset network"). The partners are divided into two categories: "monitored partners" and "non-monitored partners".
Only those shared pubset partners are monitored to which here is a CCS connection or to which there was a CCS connection at any given time within the current MSCF session. The other partner processors are not monitored (see also section “Activating and deactivating MSCF partner monitoring” (Global control parameters )).
There has to be a CCS connection between processors in a master/slave relationship, i.e. the processors monitor each other. There should also be a CCS connection between processors in a backup master/slave relationship, since a master change would otherwise not be possible.
No CCS connection is required between processors that are in a slave/slave relationship regarding all shared pubsets that they use together. The processors do not monitor each other and can therefore be operated independently of one another, i.e. in a decentralized mode. The following example describes a configuration in which two centrally operated processors alternately take on the role of master and backup master processor and in which other, decentrally operated processors are always in the role of slave processors of the shared pubsets.
Example
Processors R1 and R2 on which the production is running, are operated centrally. They are alternately master processor and backup master for shared pubsets A and B. The centrally operated processors S1 and S2 are departmental processors or test systems; from time to time these processors have to access central data on shared pubsets A and B.
All four processors form shared pubset networks in relation to the two shared pubsets. For a successful master change to be possible, CCS connections must exist between processor R1 and all the other processors and between processor R2 and all the other processors but not between processors S1 and S2. In our example there is no CCS connection between processors S1 and S2, i.e. they do not monitor each other. A failure of processor S2 would not affect S1. In particular, the shared pubset functionality with R1and R2 remains intact.
The situation is a different one if there is a CCS connection between S1 and S2. Then the two processors monitor each other and S2 has to react to the failure of S1 by starting a fail reconfiguration.
If the fail reconfiguration is not started, e.g. because MCS1100 is not answered, then S2 cannot import pubsets A and B after it has been restarted. But if the fail reconfiguration is performed and S2 it subsequently transpires that S2 had not failed at all, MSCF will abort on S1. Without partner monitoring between S1 and S2 this problem cannot occur.