The term shared pubset network (SPVS network) denotes a function network of up to 16 processors which use direct hardware paths to the same pubset and have imported that pubset at the same time.
Within a shared pubset network, one processor is nominated the owner of the pubset (master processor) (via the SET-PUBSET-ATTRIBUTES or IMPORT-PUBSET command) which processes the management functions for the files on the pubset, the user IDs, and the accesses for the other processors (slave processors). There must be CCS type connections between the master processor and each slave processor. While all management requests from the slave processors, which require accesses to the DMS metadata (file catalog, file lock table etc.) are directed via HIPLEX MSCF to the master processor, the read and write accesses to the user data are made via direct hardware paths. In other words, input and output operations with the user data are processed by each sharer, irrespective of whether master or slave processor, via its direct hardware path without having to access the master processor.
A shared pubset can be an SM or an SF pubset. In a shared pubset network, processors are grouped, so to speak, around a shared pubset. A processor can participate in several shared pubset networks. It can be the master processor in one shared pubset at the same time as being a slave processor in other shared pubsets. In addition to the shared pubsets, each processor can also import exclusive pubsets.
The participants in the shared pubset network monitor each other to ensure uninterrupted functioning. If a sharer fails, a network recovery is initiated. If the failed processor was the master processor, provided the system is set accordingly, another sharer assumes the master role (see section “Failure of a processor in a shared pubset network”).
Disk monitoring
Beside being monitored through the CCS connection, the participants of a shared pubset network are monitored via the pubset itself. When a pubset is imported to the master processor in shared mode, the DMS automatically sets up the watchdog file on the pubres of the SF pubset or the volres of the SM pubsets.
Each sharer (both as master and as slave processor) periodically writes an incremental counter (= vital-sign message) to the watchdog file and reads the vital-sign messages of the other sharers (disk log). A potential failure of the sharer is detected by the fact that it ceases to write vital-sign messages, i.e. its counter stops making the increments.
Control groups
Monitoring groups are formed dynamically and automatically from the current shared pubset configuration.
If several partners fail at the same time, all partners belonging to the same control group are reconfigured together. Fail reconfigurations for partners from different control groups are started independent of one another. This ensures that the master change which is automatically triggered by the fail reconfiguration is not blocked by a failed partner that has not yet been reconfigured.
Partner monitoring
Partner monitoring is partner-related. It is based on the following, mutually independent mechanisms:
connection monitoring - see "CCS network " and section “Failure of BCAM connections”
disk monitoring - see section "Disk monitoring" in chapter "Shared pubset network ".
While the connection monitoring takes place in the CCS network on which the shared pubset network is based (LCS networks are ignored), the disk log runs in each shared pubset network in which the local processor and the partner both participate. The failure of a sharer is only assumed if it writes no more vital-sign messages on any common shared pubsets and no longer replies via the MSCF connection. This also means that in the event of a partner failure, the recovery measures are introduced simultaneously for all common shared pubsets.
Connection, partner type
Before a shared pubset network can be set up, CCS connections must exist between the master processor and all slave processors. An CCS connection between two slave processors is not mandatory or the connection may be an LCS type. If the network is then reconfigured, however, the reconfiguration is subject to certain restrictions (in particular, no master change can be carried out if there is no CCS connection between the designated master processor and the slave processor).
No special partner type has been introduced for a shared pubset network. The partner type output in the SHOW-MSCF-CONFIGURATION command is based on the participation of the partner in the other network (types).
Applications (functions)
In addition to the functionality of the CCS network, the following functions are also supported in the shared pubset network:
File management, including security functions
Virtually all of the DMS interfaces are available in a shared pubset network; the associated security functions (SECOS) are also supported throughout the network.Storage management and backup functions
All of the interfaces for managing the background storage facility, in particular migration and backup (also with "Concurrent Copy") are available in the shared pubset network.