The XCS network is a grouping of up to 16 processors to form a performance (also called a load network) and availability network.
A processor can only participate in one XCS, although it can also participate in different LCS, CCS and shared pubset networks.
The basic feature of the XCS network is the global consistency of the XCS configuration, i.e. all distributed system functions on all processors recognize the same processor as a participant of the same XCS network. Each of the processors in the XCS network must therefore be connected with every other processor of the same XCS network via a CCS connection so that all XCS participants can communicate with each other as and when required.
In addition, there must be at least one XCS pubset in the XCS network. This is a selected shared pubset which is automatically imported by the system to all the participants of the XCS network - and only to them (the pubset must not be imported explicitly). In other words, XCS pubsets are only available to the processors of the same XCS network and can be used as global data repositories for that network. An XCS network is also always a shared pubset network in terms of the XCS pubsets.
An XCS pubset can be an SM or an SF pubset.
Connection, partner type
A CCS connection must exist between any two processors of the same XCS network. Connections to other processors (that do not belong to the XCS network) can be LCS or CCS connections.
A partner processor within the same XCS network is called an XCS partner. Outside the XCS network (including members of other XCS networks), the partner type is defined by the respective network type.
Applications (functions)
In addition to all of the functions available in the shared pubset network, the following functions are also supported in an XCS network:
DLM
Lock management for all processors for the coordination of accesses by applications to global objects.Shared File System
File access for all processors also in shared update mode, both for XCS and shared pubsets, assuming UPAM, FASTPAM or DIV access methods.Shared PLAM
Parallel accesses from different processors to libraries on shared pubsets. Shared PLAM is supported.XTS (XCS Time Synchronisation)
Synchronizes XCS time and adjusts the local processor clocks to a common time.
The "lock management for all processors" and "shared file system" functions permit the support and implementation of distributed database systems in the XCS network.
Configuration Manager (XCM)
The configuration of an XCS network, i.e. the number of processors belonging to the network, can change dynamically during an XCS session because processors can enter the network in any order, exit the network or cancel their XCS participation as a result of anerror. The global consistency must, however, be guaranteed during all changes in the configuration. This is the job of the XCS Configuration Manager (XCM), a component of HIPLEX MSCF. XCM monitors the XCS participants and initiates the reconfiguration of the existing system functions distributed to the participants each time the configuration
changes. The failure of a connection or disk log and thus the potential crash of a partner are reported to the XCM by both the connection monitoring and the disk monitoring mechanisms (independently of each other).
When the XCM then definitively determines that the partner has actually crashed, possibly after clarification of the situation by the systems support, it initiates the reconfiguration of the XCS network. Each change in the configuration is made known to all distributed system functions which automatically adapt to the new situation. When they do this, reconfiguration units are defined to the XCM which are called "registered functions".
From the point of view of the XCM, a registered function is a coherent unit which is established on all of the processors participating in the network, and whose cooperation on all processors is supported by XCM. If HIPLEX MSCF is started on a processor, XCM initializes and starts the registered functions; when HIPLEX MSCF is terminated, XCM terminates the registered functions. If a participant in the XCS network crashes, the registered functions are called on the processors that remain in the network in order to restore the network.
The following functions are known to the XCM as reconfiguration units for ensuring global consistency:
NSM - Node Synchronization Manager
The NSM is the global part of the Distributed Lock Management. On entry to the XCS network, the processor is included in the global lock assignment and removed from it on exit. When a processor fails, the locks held by it are made available again to the other processors in the XCS network.
The long connections of the BCAM applications $MCSNLX and $MCSNSM "belong" to the NSM.XTS - XCS Time Synchronization
Creates the synchronized XCS time and ensures that the local clocks all have the same time.XPM - XCS Pubset Manager
XPM handles the availability of the XCS pubsets. All of the XCS pubsets are imported when the XCS network is started, and exported when it is terminated. In the event of a processor in the XCS network crashing, it is removed from all of the XCS pubset networks.
The number of the XCS pubsets can be changed during the XCS session via XPM (SET-XCS-PUBSET command).
On entry, exit or failure of an XCS participant, XPM guarantees the necessary automatic import, export or recovery processing.CPM - Shared Pubset Manager
Manages all imported shared pubsets that are not defined as XCS pubsets. If a processor crashes, the CPM initiates the recovery of the shared pubset networks concerned.DAB - Disk Access Buffer
SHC - Symmetrix Host Component
Provides the functionality of external disk storage systems in BS2000. As a registered function, it is informed of all configuration changes and malfunctions.
XCS configuration
The entire number of processors participating in an XCS network form the XCS configuration which is identified by a configuration number (XCS CONFIGURATION). When it is generated, the XCS network is assigned the configuration number 1. Each time thereafter that the configuration is changed by any processor in the XCS network, i.e. after each entry, exit or failure of an XCS participant, the configuration number is increased by one. It is used as the reconfiguration number also for the unique designation of the configuration change that results in an XCS configuration of the same name.
The reconfiguration number of a processor’s join reconfiguration is called the JOINING ORDER and defines the order in which the processors reenter the network.
The XCS configuration is managed consistently by the XCM on each processor, i.e. allregistered functions of the processor recognize the same XCS configuration for the same configuration number. The XCS network is consistent if the configuration numbers agree on all of the processors in the XCS network, or in other words, describe the same XCS configuration. The XCS network is globally consistent (i.e. network-wide) when all of the processors have understood the same configuration at the same time, when there is no disruption due to a lost connection or an XCS participant dropping out the network, and no network entry or exit is being processed.
Reconfigurations in the XCS network are based on the principle of:
detecting a change in the XCS configuration on the individual processors
coordinating the participating processors
updating the configuration on all processors
resuming XCS operation.
Reconfigurations must be carried out together by all registered functions on all the processors participating in the XCS network. This happens when the XCM used on the processor concerned requests the registered functions to replace the configuration valid up until then with the new one. Coordinated with their partner systems, each registered function then carries out the reconfiguration of its XCS functionality and informs the XCM when the reconfiguration is successfully completed. The transition to the new configuration is made virtually simultaneously on the individual processors and in the individual functions. The XCS reconfiguration is finished when all XCS functions have executed the reconfiguration on all processors participating in the XCS network.
A distinction is made between the following three reconfiguration types:
Join reconfiguration
This reconfiguration is carried out when a processor enters the XCS networkLeave reconfiguration
This reconfiguration is carried out when a processor exits the XCS networkFail reconfiguration
This reconfiguration is carried out when a processor that has broken off its participation in the XCS network is removed from the XCS network.
The XCM only initiates an XCS reconfiguration if CCS connections are established between all the processors participating in the XCS network. Join and leave reconfigurations are carried out separately one after the other, i.e. the next join or leave reconfiguration is not processed until the previous XCS reconfiguration is completed. A fail reconfiguration interrupts a join or leave reconfiguration. Crashes of several processors are groupedtogether in one fail reconfiguration block.
If XCS operations are disrupted by a processor (e.g. failure of a registered function), the interruption is remedied by the fact that the participation of the processor in question in the XCS network is broken off and the remaining processors in the XCS network carry out a fail reconfiguration. Incomplete join and leave reconfigurations are aborted and replaced by a fail reconfiguration for the processor concerned.
If the connection between two processors has fails, the processor with the lower priority level (higher HOST-PRIORITY value or, if the same, higher JOINING ORDER value) breaks off its participation in the XCS network in automatic mode and is subsequently configured out of the network. A fail reconfiguration is initiated on the processors that remain in the network.
The fail reconfiguration of each individual processor is not complete until the target configuration (i.e. the processors remaining in the XCS network) has been fully generated.