HIPLEX MSCF is terminated either directly via the STOP-SUBSYSTEM MSCF command or indirectly in the course of the shutdown procedure. Termination not only clears down the MSCF connections, it also removes the processor from all networks and exports all shared pubsets. If the processor was the master processor for a shared pubset, a master change is initiated by the processors remaining in the network. XCS processors exit the XCS network.
If HIPLEX MSCF is terminated on a processor, the processor is removed from the MSCF network and all tasks of the processor must return their HIPLEX MSCF resources. For this reason, the STOP-SUBSYSTEM command is rejected if shared pubsets are still imported on the processor (message MCS0021 is output). If MSCF termination is forced by the command STOP-SUBSYSTEM MSCF, SUBSYSTEM-PARAMETER='FORCED=YES', all user tasks still using shared pubset or XCS functionality are aborted with CANCEL-JOB before the processor is disconnected from the network.
The MSCF subsystem does not terminate until the entire HIPLEX MSCF functionality has been shut down in full on the processor, because only then is the processor permitted to reenter the network.
If HIPLEX MSCF terminates automatically (e.g. due to a configuration error), the processor disconnects from the network and all shared pubsets are exported by force. HIPLEX MSCF is unloaded after the last shared pubset has been exported successfully.
Notes
If serious errors occur within the MSCF network, the MSCF subsystem terminates automatically. The processor disconnects from the network, and message MCS1003 is output.
The MSCF network is based on BCAM. BCAM commands can therefore be used for HIPLEX MSCF.
Issuing the BCAM command BCOUT for a processor connected to the MSCF network disconnects this processor from the network.
When the BCAM command BCEND is executed, BCAM checks whether MSCF is still running. If it is, first the STOP-SUBSYSTEM MSCF, SUBSYSTEM-
PARAMETER='FORCED=YES' command is executed, and then BCAM delays further processing of BCEND until either MSCF has terminated or the maximum wait time set in the BCAM parameter MAX-MSCF-DELAY (see "BCAM dependencies") has elapsed.If BCAM commands are executed, the functionality of the commands STOP-MSCF-CONNECTION and STOP-SUBSYSTEM MSCF does not come into play, which can have serious consequences for the multiprocessor system and in particular for shared pubset or XCS operation (risk of erroneous crash detection, DMS return codes on the slave processors of a shared pubset).
When HIPLEX MSCF is terminated, all shared pubsets are exported; the system waits for the release of DMS occupation. This can cause a delay in the unloading of MSCF if applications which occupy the shared pubset are not terminated before shutdown. UTM applications that use shared pubsets are terminated automatically by the export processing.
When a system shutdown is to take place on multiple processors in an MSCF network, it is recommended that these shutdowns should be initiated one after the other on the processors concerned and that completion of an initiated shutdown should be waited for to give the other processors which are (still) in the MSCF network the opportunity to register the exit from the MSCF network of a processor which is shutting down.
When multiple processors in an MSCF network are to be terminated more or less simultaneously, this can lead to blocks when a system is shut down. Such blocks are cleared only by shutting down BCAM and subsequent abnormal termination of HIPLEX MSCF (after 10 minutes).