A shared pubset network comprises a master processor and a maximum of 15 slave processors with hardware paths to a shared pubset.
The prerequisite for starting the shared pubset network is that HIPLEX MSCF is loaded on all participating processors and the necessary MSCF connections are established between the processors. The minimum requirement is one CCS connection (see "CCS network") between the master and slave processor. For automatic master changes and comprehensive network monitoring, CCS connections must also exist between all slave processors.
The shared pubset network is established when the pubset is imported on the master processor. The network is cleared down when the pubset is exported from the last sharer.
MRSCAT entries (catalog IDs) must be created on the processors for the shared pubset involved. The HIPLEX MSCF requirements for the associated SYSIDs of the home pubsets are explained on "Processor identification". The BCAM dependencies that must be taken into account in relation to the shared pubset network are described on "BCAM dependencies".
Importing a shared pubset
The shared pubsets provided for the shared pubset network must be imported on all processors of the network. The shared pubsets are imported explicitly using the command IMPORT-PUBSET PUBSET=<catid>,USE=*SHARE,SHARER-TYPE=*MASTER (import to master processor) or IMPORT-PUBSET ... ,SHARER-TYPE=*SLAVE (import to slave processor). If the operand SHARER-TYPE is not specified, its value is determined implicitly using the value of CURRENT-MASTER currently entered in the SVL for the pubset and the defined DESIGNATED-MASTER (for more information, see section “Generation of the shared pubset network”).
The following preconditions must be fulfilled to import the shared pubset:
The processor must have direct hardware paths to the devices on which the pubset resides.
All devices which contain the pubset to be imported must be "attached" (ATTACH-DEVICE command on the console or corresponding generation).
The pubset to be imported must be declared as "shared" in the SVL entry (on the pubres) (SET-PUBSET-ATTRIBUTES command).
The pubset to be imported must be declared as "shared" in the MRSCAT entry (ADD- or MODIFY-MASTER-CATALOG-ENTRY command).
The pubset must not be the home pubset or the paging pubset of the processor.
The status of the pubset in the MRSCAT must be "inaccessible". For a slave import, "remote accessible" is also permitted.
The pubset must not already be imported exclusively on other processors (if necessary, export from there).
HIPLEX MSCF must be loaded and a connection must be established to the current master processor (CCS connections must exist between the master processor and all slave processors). If this is not the case, a slave import is pended (message DMS037C); a master import is rejected with message DMS037B.
In VM2000 operation, the devices containing the pubset must be assigned to the VM of the importing guest system. This assignment is implemented on the monitor system with the VM2000 command ADD-VM-DEVICES. The operand TYPE=*SD is required if the pubset is to be imported to several guest systems of the same VM system, and should only be used in this case.
Master import of a pubset
When the pubset is imported to the master processor, the processor establishes the shared pubset network. At this time, there need be no MSCF connections to the slave processors. However, the pubset can only be imported to the master processor if it is not imported on any other processor. If the previous pubset session was not terminated properly, i.e. if processors which might still be accessing the pubset are still entered on the pubset, the import procedure will be discontinued and systems support will be requested to intervene.
If the pubset session during which the pubset was imported exclusively was not terminated properly, message NKA0019 is output. If it is guaranteed that the respective sharer is no longer accessing the pubset, the sharer can be removed from the sharer list using the UNLOCK-DISK command. Following the appropriate response to message NKVD072 for UNLOCK-DISK, the master import is continued automatically.
If the pubset was previously imported as "shared" and if the former master processor is still entered, message DMS13C7 is output and a response must be given. If it is guaranteed that the processor is no longer accessing the pubset, the message can be answered with "<tsn>.FORCE-MASTER-IMPORT" and the master import thus implemented by force. The import procedure is aborted if "<tsn>.N".
If the pubset was previously imported as "shared" and if slave processors are still entered and it is determined that the pubset is still imported on at least one of these, the import process is aborted. A master import of this pubset is only possible if one of the remaining slave processors performs a master change (see “Importing a shared pubset with master change” on the next section) or if all slave processors that are still active export the pubset.
If the pubset was previously imported as "shared" and if slave processors are still entered in the SVL and it cannot be determined whether or not the pubset is still imported on these processors, the DMS13D3 message, which requires a response, is output for each slave processor. If it is guaranteed that the processor is no longer accessing the pubset, the message can be answered with “<tsn>.Y”, thus forcing the master import. If the answer “<tsn>.N” is given, the import process is aborted.
Slave import of a pubset
If the shared pubset is imported on the slave processor, this means that the processor wants to join an existing shared pubset network. The following conditions must be fulfilled in this case:
HIPLEX MSCF must be loaded.
A master processor must be established.
A CCS connection must exist to the master processor.
If any of these conditions is not fulfilled, the slave import is halted until all conditions are fulfilled. Only then can the processor connect to the network.
The status of a shared pubset can be queried using the commands SHOW-MASTER-CATALOG-ENTRY, SHOW-PUBSET-PARAMETER and possibly SHOW-SHARED-
PUBSET. If a pubset is imported as a shared pubset, the master processor is also specified in the output of the SHOW-MASTER-CATALOG-ENTRY command (on the master processor: MASTER-HOST=OWN-HOST, on the slave:
MASTER-HOST=<processor-name of master-processor>).
Importing a shared pubset with master change
In addition to the master and slave import, there is also the special case of "import with master change".
If a master change fails, the cause of the error that led to the failure must first be eliminated. The shared pubset can then be imported on the slave processor which is to be the new master processor using the IMPORT-PUBSET PUBSET=<catid>,SHARER-TYPE=*MASTER(MASTER-CHANGE=*YES) command. The processor is thereby established as the new master processor for the shared pubset. However, the command can only be applied in this form after a master change has failed or has not be initiated (i.e. the pubset is in the INACC,QUIET state).
Differences from exclusively imported pubsets
Modifications to the user catalog via the commands ADD-USER, MODIFY-USER-ATTRIBUTES, LOCK-/UNLOCK-USER and REMOVE-USER can only be implemented from the current master processor.
SCA (Speed Catalog Access) for a shared pubset can only be started and stopped on the current master processor of the shared pubset.