The reactions of MSCF can be controlled with the parameters described below. Because several MSCF sessions (i.e. the time between START-SUBSYSTEM MSCF and STOP-SUBSYSTEM MSCF) can take place within a BS2000 session, a distinction is made between system parameters (defined in the startup parameter service) which apply to the overall BS2000 session and those parameters that purely apply to an MSCF session (defined via the SET-MSCF-ENVIRONMENT command).
System parameter MCXSPXCS
MCXSPXCS defines whether a processor is basically authorized to participate in an XCS network and how the XCS resources are managed.
MCXSPXCS = N (default)
The processor cannot participate in the XCS network.
The XCS resources are locally managed and only the local processor can access the XCS resources.
Local resource management cannot be terminated. Therefore, the processor cannot participate in any XCS network for the duration of the entire BS2000 session. If an XCS name is specified in the MSCF configuration file, this causes the MSCF start to abort.MCXSPXCS = Y
The processor can take part in an XCS network.
XCS resources can be locally or globally managed. They can only be assigned after the MSCF subsystem is started. Whether the XCS resources are locally or globally managed depends on the value of the XCS-NAME operand of the SET-MSCF-ENVIRONMENT command in the MSCF configuration file.XCS-NAME=*NONE (default)
MSCF is started in CCS mode. The XCS resources are managed locally and only the local processor can access them. From this point on, the same procedure applies as for MCXSPXCS=N.XCS-NAME=*SUSPEND
MSCF is started in CCS mode.
No XCS resources are allocated. However, the MSCF subsystem can also be started in XCS mode in the current BS2000 session in order to gain access to the XCS resources.XCS-NAME=<alphanum-name 1..8>
MSCF is started in XCS mode.
XCS resources are managed globally. All XCS participants have access to the resources.
MCXSPXCS=V
The processor is intended to participate in the XCS network.
XCS resources are managed globally only. They are only allocated if the MSCF subsystem is started in XCS mode. Within a BS2000 session it is possible to switch optionally between CCS mode and XCS mode.
MSCF configuration parameter ABORT-LIMIT
The MSCF configuration parameter ABORT-LIMIT defines the maximum duration of a network-participation abort for a shared pubset network or XCS network on the local processor. If the abort cannot be performed within the specified time, the BS2000 session on the processor is terminated. In this way the fail reconfiguration can be completed in the rest of the network and the operability of the network can be restored. The network-participation abort cannot be completed if, for example, the system cannot remove the DMS occupation of a pubset during export.
By default, abnormal system termination does not force termination of abort processing.
MSCF configuration parameter HOST-PRIORITY
When reconfiguration is started automatically (see MSCF reconfiguration parameter RECOVERY-START=*AUTOMATIC / *SECURE on "Global control parameters"), HIPLEX MSCF is automatically terminated abnormally on one of the two processors affected by the connection failure to allow full restoration of the operability of the processor network by means of a fail reconfiguration when a connection fails in the XCS network. With the HOST-PRIORITY configuration parameter you can classify a processor in the XCS network according to its importance and thus control the selection of which processor is to terminate when the connection fails. The HOST-PRIORITY determines the processor order according to their importance. Processors with a lower value of HOST-PRIORITY have the higher priority. The default value is 16. If the two processors affected by the connection failure have different HOST-PRIORITY values, the one with the higher value is removed from the XCS network. If both processors have the same HOST-PRIORITY value, the one that entered the network later is removed (higher value for JOINING ORDER). If several connections fail at the same time, this procedure is carried out for each one individually.
MSCF configuration parameter LEAVE-LIMIT
The MSCF configuration parameter LEAVE-LIMIT specifies the interval after which the coordinated exit of a processor from an XCS network (LEAVE) will be converted into a network-participation abort. The aim of this conversion is to defuse situations which delay or prevent completion of the exit and thus to make the rest of the XCS network operable again. LEAVE-LIMIT only starts after the user tasks have been terminated or after the USER-TERM-LIMIT ("Global control parameters") has expired.
By default a coordinated exit is not converted into an abort.
MSCF configuration parameter LOCAL-PASSWORD
Specification of the MSCF configuration parameter LOCAL-PASSWORD can protect the processor from illegal MSCF connections being generated by means of a password. The password defined for the processor must be specified when the START-MSCF-
CONNECTION command is used for CCS outside the MSCF configuration file. The partner processor must also know the password, otherwise no (CCS) connection is established.
MSCF configuration parameter NOTIFY-BY-MAIL
The MSCF configuration parameter NOTIFY-BY-MAIL defines whether email notifications are to be sent to a user ID in critical situations, see section “Email notification about critical states”). When an email is sent, the email address is taken from the EMAIL-ADDRESS field of the corresponding user entry.
MSCF configuration parameter XCS-NAME
Specification of an XCS name defines that the processor is to participate in the respective XCS network. The processor enters the network when HIPLEX MSCF is started.
The MSCF configuration parameter XCS-NAME is defined via the SET-MSCF-ENVIRONMENT command deposited in the MSCF configuration file. This configuration parameter cannot be modified once the XCS is up and running.
MSCF configuration parameter TRACE-FILE
Specifying the TRACE-FILE operand in the SET-MSCF-ENVIRONMENT command defines whether and - if so - to which file the traces of the MSCF subsystem are written. The MSCF traces represent an important document for the diagnosis of error situations. The file that is to be written to can be redefined or writing to a file can be suppressed by the MODIFY-MSCF-ENVIRONMENT command.
MSCF configuration parameter FAIL-DETECTION-LIMIT
The configuration parameter FAIL-DETECTION-LIMIT defines the time (in seconds) within which the processor must detect a failure in the MSCF network (such as a partner or connection failure). The defined value is rounded up to a multiple of 44; the default setting is 176 seconds (=minimum value).
The time for internal monitoring cycles is derived from this failure detection time (cycle time = rounded-up value of FAIL-DETECTION-LIMIT / 11).
Processor failures are detected by the monitoring mechanisms after 1-3 cycles. But this can be longer if the BCAM connections fail, depending on the maximum duration of a BCAM connection setup.
When defining the failure detection time, bear in mind that under certain conditions, the operating system is halted for long periods of time, see the section “Disk monitoring blocks”. Monitoring cycles that are too short then result in incorrect failure detection. This must be avoided at all costs.
To avoid an erroneous failure detection or system termination, you must either specify RECOVERY-START=*BY-OPERATOR / *CONSISTENT-BY-OPERATOR / *SECURE or define a higher value for FAIL-DETECTION-LIMIT. Note that the processor cannot be suspended for longer than the result of FAIL-DETECTION-LIMIT / 11.
After an automatic failure detection, the system waits for a certain security interval before initiating the fail reconfiguration. The partner processor seen as crashing is thus given the opportunity to terminate if the failure detection was mistaken.
The value of FAIL-DETECTION-LIMIT should be selected to be less than the restart time (about 15 minutes) of a BS2000 system. The reason for this being that the failure of a processor must be detected on the partner processor and a fail reconfiguration carried out. Only when the fail reconfiguration is completed on the partner processor can the (crashed) processor enter its new BS2000 session in a CCS, shared pubset or XCS network.
If the processor is restarted immediately after its crash and if it wants to enter the network before the fail reconfiguration is finished on the partner processor, the host name of the processor will (still) be known to the partner processor. The processor is therefore refused entry to the network (messages MCS1005 and MCS0009).
same FAIL-DETECTION-LIMIT.
MSCF configuration parameter RECOVERY-START
The behavior of partner monitoring can be influenced in a variety of ways using the RECOVERY-START configuration parameter:
Activating and deactivating MSCF partner monitoring
Partner can be monitored by MSCF through connection monitoring or disk monitoring.
A partner is monitored if monitoring via at least one of the two monitoring paths is activated (for exceptions see below):
Connection monitoring: generally activated when a CCS connection is generated and deactivated when the CCS connection is closed down (not when it fails).
Disk monitoring: activated when a common shared pubset is imported and deactivated when the last common shared pubset is exported.
XCS partners are always monitored. Monitoring an XCS partner can only be deactivated by removing the partner from the XCS network.
A CCS partner which is not a shared pubset partner is monitored when a CCS connection is generated to it using RECOVERY-START !=*STD. As long as no shared pubset is imported with the partner monitoring can be deactivated by modifying RECOVERY-START to =*STD or !=*STD.
A shared pubset partner is only monitored while the CCS connection is established. Connection monitoring and disk monitoring are both activated together when the CCS connection to the shared pubset partner is initially generated. Similarly, connection monitoring and disk monitoring are also both activated together when a shared pubset which is shared with the local processor is imported for the first time for the CCS partner with RECOVERY-START=*STD. In order to deactivate monitoring, both monitoring paths must be closed down by terminating the CCS connection and exporting all shared pubsets.
Inhibiting the automatic start of fail reconfiguration
When partner monitoring detects that a partner has failed, it is necessary to perform fail reconfiguration for the failed processor to restore network functionality. The setting of the configuration parameter RECOVERY-START defines whether this fail reconfiguration is started automatically or whether MSCF asks the question MSC1100
(No activity of partner detectable. Start fail-reconfiguration?) on the console and fail reconfiguration begins only after this question has been answered.
Independent of the RECOVERY-START setting, this query will also be issued if an MSCF configuration parameter has just modified RECOVERY-START.
Inhibiting an automatic start of fail recovery can be set with network-wide or partner-specific effect:
network-wide setting:
The network-wide setting applies for all partners. It is implemented using the SET-MSCF-ENVIRONMENT or the MODIFY-MSCF-ENVIRONMENT command.partner-specific setting:
The partner-specific setting only applies to a specific partner. It is implemented using the START- or MODIFY-MSCF-CONNECTION command.
The partner-specific setting RECOVERY-START=*STD means that the general setting should become effective for this partner. If the partner-specific setting is neither *STD nor the same as the general setting, the value of RECOVERY-START which is effective for the partner is derived from the table below:
First setting 1 | Second setting 1 | Locally effective setting |
*AUTOMATIC | *BY-OPERATOR | *BY-OPERATOR |
*AUTOMATIC | *CONS-BY-OPERATOR | *CONS-BY-OPERATOR |
*AUTOMATIC | *SECURE | *SECURE |
*BY-OPERATOR | *CONS-BY-OPERATOR | *CONS-BY-OPERATOR |
*BY-OPERATOR | *SECURE | *BY-OPERATOR |
*CONS-BY-OPERATOR | *SECURE | *CONS-BY-OPERATOR |
1The combination of a general and a partner-specific setting always results in the same locally effective setting.
If the setting which is effective locally for a partner is
RECOVERY-START=*BY-OPERATOR / *CONSISTENT-BY-OPERATOR, fail reconfiguration may be started only after the question MCS1100 has been answered; automatic start is forbidden. In this case the RECOVERY-START setting on the partner is meaningless.
If the setting which is effective locally for a partner is RECOVERY-START=*SECURE and the Live Monitor reports or confirms the failure of this partner, MSCF starts fail reconfiguration automatically. In this case the RECOVERY-START setting on the partner is meaningless.
If the setting which is effective locally for a partner is RECOVERY-START=*AUTOMATIC, the partner will take the decision regarding the start of fail reconfiguration:
If the setting which is effective on the partner for the partner’s own computer was RECOVERY-START=*CONSISTENT-BY-OPERATOR / *SECURE, fail reconfiguration may be started only after the question MCS1100 has been answered.
If the setting which is effective on the partner for the partner’s own computer was RECOVERY-START=*AUTOMATIC / *BY-OPERATOR, automatic start of fail reconfiguration is required. However, partner monitoring cannot be certain of the failure of the partner in the following cases:
Failure of the last monitoring path if this does not fail “simultaneously” with another monitoring path
Failure of the partner during a SNAPSHOT dump
Failure of the partner while the Cluster Recovery Lock (CRL, see "Cluster Recovery Lock (CRL) ") is set
If one of these cases has occurred, MSCF also poses the question MCS1100, and fail reconfiguration begins only after the question has been answered.
Error recovery when a connection fails in XCS mode
If the MSCF connection between two processors in an XCS network fails, the network functionality is disrupted.
Measures are automatically initiated to eliminate the failure if *AUTOMATIC / *SECURE is specified for the general RECOVERY-START setting and *AUTOMATIC / *SECURE or *STD is specified for the relevant partner-specific setting. In this case the rules described under “MSCF configuration parameter HOST-PRIORITY“ (see "Global control parameters ") apply and HIPLEX MSCF is aborted on one of the two processors and removed from the XCS network configuration.
Otherwise, the message MCS1101 prompts systems support to eliminate the connection failure.
Controlling allowed system aborts
See also section “Abnormal termination of HIPLEX MSCF”.
System termination with MSC1300 (to avoid erroneous failure detection through the partner) can either be generally or partner-specifically prohibited. A processor’s general or partner-specific setting *BY-OPERATOR stops the system abort due to erroneous failure detection by the lokal processor on all partners or on a specific partner. The *CONSISTENT-BY-OPERATOR setting also stops the system abort on the local processor due to erroneous failure detection by an optional or specific partner.
The MCS1301 system abort (to allow reconfiguration on the MSCF partners) is only executed if a processor’s general RECOVERY-START setting is *AUTOMATIC / *SECURE.
MSCF configuration parameter USER-TERM-LIMIT
This configuration parameter defines the time available to the user tasks for termination, counting from the moment the XCS termination is initiated. When this time elapses, the registered functions are terminated.
If, in rare situations, the XCS functionality cannot be completely cleared locally, the MSCF subsystem is not unloaded until the system is terminated.
MSCF configuration parameter NUMBER-OF-SERVERS
This configuration parameter determines the number of server tasks that are to be provided on the processor. The default value is four server tasks, but up to ten and as few as two can be requested. The number can increase continually during the MSCF session. If necessary, MSCF will generate new server tasks, but it will also terminate them again when they are no longer needed.
The number of server tasks defined by the START-SUBSYSTEM command has priority over the number defined in the SET-MSCF-ENVIRONMENT command.
MSCF configuration parameter SERVER-TASK-LIMIT
Too heavy a load due to too many MSCF server tasks can bring a system to a standstill (e.g. due to PAGING SATURATION). To prevent this happening, the number of MSCF server tasks is limited. The value of the MSCF configuration parameter SERVER-TASK-LIMIT ("MAXIMUM" in the SM2 output under "TASK LIMITS") serves as a yardstick.
An MSCF server task is in "occupied" state when it is in a deadlock-threatened situation that affects all processors. The system components using the MSCF server tasks decide when this applies.
If the number of "occupied" MSCF server tasks exceeds an upper limit (= 75% of SERVER-TASK-LIMIT; "FLOW SET" in the SM2 output under TASK LIMITS), the status of the local processor is set to "FLOW". Partner processors are informed accordingly and respond by then sending only absolutely essential messages to the processor (which resolve the "occupied" state of an MSCF server task). Once the number of "occupied" MSCF server tasks has decreased again to a lower limit (= 50% of SERVER-TASK-LIMIT; "FLOW
RESET" in the SM2 output under "TASK LIMITS"), the "FLOW" status is cancelled. The partner processors are informed about the changed situation and after that resume sending messages of any type to the processor.
Since the limit is based on the number of "occupied" MSCF server tasks, at times of sudden peak loads, more server tasks may be generated then specified in the configuration parameter SERVER-TASK-LIMIT.