Shared pubset mode requires the following conditions to be met:
The pubset must be on devices to which the processors have direct hardware paths.
The configuration must be a balanced one.
A low-performance master with possibly several powerful slaves which furthermore generate a high DMS management load (e.g. Open/Close), can only be regarded as an incorrectly configured shared pubset network. For performance reasons, the processor expected to handle the high DMS management load should, if possible, be defined as the master processor.Number of MSCF server tasks
A high DMS management load can result in the multiplication of MSCF server tasks. To prevent the number of server tasks escalating out of hand, a maximum value must be defined. When this limit is reached, the DMB management load is automatically restricted by the system, a fact that becomes noticeable by the significantly poorer performance. Powerful configurations permit a higher limit for the number of server tasks. This is set in the MSCF configuration file with the SET-MSCF-ENVIRONMENT command, SERVER-TASK-LIMIT operand. When deciding on the maximum number of server tasks (see “MSCF configuration parameter SERVER-TASK-LIMIT” (Global control parameters )), a decisive factor is the number of tasks or system tasks permitted in the overall system.Reliability of disk monitoring
The permissible disks (with respect to disk inputs/outputs) should always be used as shared pubsets.
A separate disk log is kept for each shared pubset irrespective of whether the shared pubset is an SF or an SM pubset. Each shared pubset is thus a separate monitoring path, a fact that makes the disk monitoring function highly reliable.The SM pubset concept permits all the shared pubsets to be grouped into a single shared pubset. This solution, however, runs contrary to the requirement for a reliable, fail-safe disk monitoring function. We recommend using at least two physically separate shared pubsets (i.e. separate channel paths, disk controllers etc.).
For all processors that access a shared pubset we recommend setting identical storage space saturation levels (in the MRSCAT) because otherwise a master change can result in problems.
System parameter TEMPFILE
If the processor is to work with temporary files (TEMPFILES) or job variables, then all of the processors in the network must work with them. If they work with TEMPFILES, the same prefixes must be defined.System parameter FSHARING
This access protection for pubsets must agree on all the processors that access a shared pubset (see the the “Introduction to System Administration [5 (Related publications)]).SYSEAM on shared pubsets
Whether SYSEAM files on shared pubsets are supported depends on the setting of the system parameter EAMSPVS:
setting "00": SYSEAM files on shared pubsets can only be created by the master processor of the pubset
setting "01": SYSEAM files can be created on all shared pubsets.VM mode with shared pubsets
If a shared pubset is imported to guest systems of the same hypervisor, the volumes of the shared pubset must be defined in the VM as "shared". This means that each input/output on these disks causes two hypervisor interruptions. When there is a high input/output load, the performance of the entire VM processor can be seriously affected.System files on shared pubsets
Message files, SDF syntax files, SM2 monitoring files and POSIX file systems (except for /root and /var) can be stored on shared pubsets.
Other files that are occupied by system tasks (e.g. accounting files) should not be placed on a shared pubset because they could prevent the export of a shared pubset and thus the reconfiguration of the shared pubset network.