The master/slave principle is used for implementing the shared pubset network. A system within the network is named as the temporary pubset owner (“pubset master”) and handles all metadata management functions centrally. All remaining systems in the network (the pubset slaves or “slave sharers”) direct their management requirements to the pubset master via MSCF functions.
Assigning the system ID
The system ID (sysid) identifies the systems in a shared pubset network. In the case of shared pubset mode the system ID must be unique in a computer network.
When a system ID is assigned which is used internally as a synonym for the BCAM name of the system, the pubset notation must be distinguished:
With a VSN in PUB notation (see "VSN in PUB notation"), the system ID is identical to the single-character catalog ID (sysid=catid).
With a VSN in point notation (see "VSN in point notation"), the system ID can be a numeric value between 65 and 192. The default setting on the system is 250 (i.e. it is invalid).
The system ID is assigned when the home pubset is set up with SIR via the SYS-ID operand of the DECLARE-PUBSET statement. If the home pubset exists, the system ID can be reassigned with the SET-PUBSET-ATTRIBUTES command but the change is only effective after the next system start.
Selecting the pubset master
The desired pubset master of a shared pubset can be entered via the SET-PUBSET-ATTRIBUTES command. This command can also be used to enter a backup master which then takes over the function of the pubset master if this should fail. This process is known as a master change.
In the DMS record of the SVL of the Pubres of the SF pubset and, in the case of SM pubsets, in the DMS record of the SVL of the control volume set there are two fields which provide information on the desired pubset master and the current pubset master. These fields are evaluated when the shared pubset is activated, and selection takes place in the following order:
If a pubset master is currently entered, this external system is taken to be the pubset master and the system of the user is then inevitably a pubset slave.
Notification was made during startup that the own system is to be the pubset master.
The pubset entered in the SVL as the desired owner is made the pubset master.
If none of the above conditions are fulfilled, the first system to activate the shared pubset is made the pubset master.
The SHOW-PUBSET-ATTRIBUTES command displays the settings of the desired, current and backup masters.
Setting up and clearing down a pubset network
A shared pubset network is set up in two steps:
The MSCF subsystem is first started on all participating systems and the necessary connections are made. At least the connection between the future pubset master and pubset slave must exist and, to cater for a possible master change, the additional connection between the backup master and pubset slave.
The shared pubset is activated on all participating systems. The pubset master is selected after the owner selection described above. Startup of the pubset slave can only be fully completed after it is completed on the pubset master.
A shared pubset network is cleared down implicitly when the shared pubset is exported.
Configuration changes
The configuration of the shared pubset network can change dynamically. The causes of such a change are:
an additional pubset slave has connected itself by activating the shared pubset
a pubset slave has disconnected itself by deactivating the shared pubset
a pubset slave or the pubset master has failed and the master change was concluded successfully.