The CLUSTER statement is used to configure a UTM cluster application. The operands of the CLUSTER control statement can be split over several CLUSTER statements.
If you specify the same operand in several CLUSTER statements, the first specification is taken as the valid one. No message is issued.
If a cluster statement is specified, you must also specify at least two CLUSTER-NODE statements. If a CLUSTER statement is specified, KDCDEF implicitly generates a BCAMAPPL entry with the BCAMAPPL name specified in the CLUSTER statement.
If you change specifications in the CLUSTER statement or the CLUSTER-NODE statements with a new generation, you must create new UTM cluster files and a new KDCFILE (OPTION GEN=CLUSTER, KDCFILE) and use this file to apply the changes.
Exception:
The size of the cluster page pool can be increased during operation, i.e. without it being necessary to generate new UTM cluster files. When this is done, the number of cluster page pool files must not be changed.
|
|
| CLUSTER-FILEBASE=cluster_filebase | |||||||||||||
Name prefix or directory for the UTM cluster files. Some of the UTM cluster files are generated by KDCDEF (see list below) while others are not generated until runtime. The operand CLUSTER-FILEBASE is only evaluated if GEN=CLUSTER or GEN=(CLUSTER,...) is specified in the OPTION statement. In this case, KDCDEF generates the following files:
In this case, these files must not already exist. Mandatory operand. cluster_filebase defines the directory in which the UTM cluster files are to be stored. The directory must be created before the KDCDEF run. The UTM cluster files are created under the file names The files can be copied to a different directory to operate the UTM cluster application. Specify the name which is then valid in the start parameters when the application is started. The name can be up to 42 characters in length and must comply with the syntax for file names. | |||||||||||||
BCAMAPPL= | cluster_applname Name of the communication end point for cluster-internal communication. The name specified here must be different from the names specified for TRANSPORT-SELECTOR under MAX APPLINAME, in other BCAMAPPL statements or in ACCESS-POINT statements. In addition, the name specified here must not be used by other applications on the computers of the UTM cluster application as the name of a communication end point. The name generated here must not be referenced in other statements (e.g. in the PTERM statement) as the BCAMAPPL name. The name can be up to 8 characters in length. Mandatory operand. | ||||||||||||
LISTENER-PORT= | port_number Port number for cluster-internal communication. This operand specifies the port number on which the local application listens for external connection requests. Enter any port number between 1 and 65535. Note that the port number specified here must not be used anywhere else on the computers of the UTM cluster. The port number must also differ from the other port numbers used by this application. KDCDEF does not, however, check this. Mandatory operand. | ||||||||||||
USER-FILEBASE= | user_filebase Name prefix or directory for the current cluster user file of a UTM cluster application. The operand USER-FILEBASE is only evaluated if GEN=KDCFILE, GEN=(KDCFILE,ROOTSRC) or GEN=ROOTSRC is specified in the OPTION statement.
Mandatory operand. The name can be up to 42 characters in length and must comply with the syntax for file names. | ||||||||||||
ABORT-BOUND-SERVICE | |||||||||||||
This parameter determines how UTM behaves when a user who has an open service in a node application signs on. | |||||||||||||
NO | If there is a node-bound service for a user on sign-on (see note), then the user can only sign on at the node application to which the open service is bound; Sign-on attempts at any other node application are rejected. Default in UTM-S applications. This value is not permitted in UTM-F applications. | ||||||||||||
YES | If when a user signs on at a node application, there is a node-bound service for this user that is bound to another node application that has been terminated, then the user is able to sign on provided that no transaction of the open service has the state PTC. No service restart is performed The open service is terminated abnormally the next time the node application to which it is bound is started. Default in UTM-F applications. A service is node-bound if it
| ||||||||||||
CHECK-ALIVE-TIMER-SEC=time | |||||||||||||
Interval in seconds at which a node application of a UTM cluster application checks the availability of another node application. Minimum value: 30 | |||||||||||||
COMMUNICATION-REPLY-TIMER-SEC=time | |||||||||||||
Time in seconds that a node application of a UTM cluster application waits for a response after sending a message to another node application. If there is no response in the time specified here, it must be assumed that the other node application has failed. If you have selected a value greater than zero for COMMUNICATION-RETRY-NUMBER, it is only assumed that the other node application has failed after the number of retry attempts has been reached. Minimum value: 1 | |||||||||||||
COMMUNICATION-RETRY-NUMBER=number | |||||||||||||
Number of retry attempts to establish communication with another node application if this node application does not respond within the time specified under COMMUNICATION-REPLY-TIMER. If the monitored node application also fails to respond to any of the retry attempts, it is flagged as failed. Minimum value: 0, i.e. no retry after a timeout. | |||||||||||||
DEADLOCK-PREVENTION= | |||||||||||||
In UTM cluster applications, information concerning locked data areas (GSSB, TLS, ULS) is stored in a file. Before a service waits at a locked data area, UTM can check whether the new wait situation might result in a deadlock. To do this, additional file I/Os are necessary. This parameter specifies whether or not UTM performs additional checks in order to prevent deadlocks. | |||||||||||||
YES | UTM performs additional checks of the GSSB, TLS and ULS data areas in order to prevent deadlocks. | ||||||||||||
NO | UTM does not perform any additional checks of the GSSB, TLS and ULS data areas in order to prevent deadlocks If a deadlock occurs in one of these data areas then this is resolved by means of a timeout. See also MAX statement, operand RESWAIT=time1 ("MAX - define UTM application parameters"). Default: NO In productive operation, it is advisable to set this parameter to YES only if timeouts occur frequently when accessing these data areas. | ||||||||||||
EMERGENCY-CMD= | command_string1 Name of a script. This operand passes a command string containing a command to be executed. The emergency script is called by openUTM if a failed node application was not restarted after the failure script has been called and the restart timer (RESTART-TIMER-SEC parameter) has expired. The emergency script can be used, for example, to restart the failed computer in a cluster or perform a node recovery for a failed node application. The emergency script is always executed on the computer of the monitoring node application. The name passed here is not parsed by KDCDEF. command_string1 can be up to 200 characters in length. The way in which the emergency script is specified depends on the operating system. When openUTM is installed, platform specific templates are supplied with the name utm-c.emergency.Unix and Linux systems: Specify the fully qualified name of a Unix Sshell script. Example: Windows systems: Specify the fully qualified name of a Windows command script. Example: Calling the script command_string1 during an application run Six arguments are passed to the script command_string1. These identify the failed cluster node and allow corrective measures to be initiated. The arguments are passed in the following sequence:
The return code of the procedure or script is not evaluated. Unix and Linux systems: The generated script command_string1 is started as a background process. It is called with the six arguments listed above. Windows systems: The command script command_string1 is called with the Windows command START without waiting for it to terminate. It is called with the six arguments listed above. | ||||||||||||
FAILURE-CMD= | command-string2 Name of a script. command_string2 can be up to 200 characters in length. The way in which the failure script is specified depends on the operating system. The failure script is called by openUTM if a node application terminates abnormally or if failure of a node application is detected. A user can use the failure script to restart the failed node application, for instance. The failure script is always executed on the computer of the monitoring node application. Otherwise, the syntax and call method for FAILURE-CMD are identical to the syntax and call method of "EMERGENCY-CMD" (see "CLUSTER - Define global properties of a UTM cluster application"). When openUTM is installed, platform specific templates are supplied with the name utm-c.failure. | ||||||||||||
FILE-LOCK-RETRY= | number Number of retries for a lock request for a file that is global to the cluster if the lock was not assigned in the time specified in FILE-LOCK-TIMER-SEC. Minimum value: 1 | ||||||||||||
FILE-LOCK-TIMER-SEC= | time Maximum time in seconds that a node application of a UTM cluster application waits for a lock to be assigned to a file that is global to the cluster. Minimum value: 10 | ||||||||||||
LISTENER-ID= | number This parameter is used to select a network process for internal cluster communication. Minimum value: 0 | ||||||||||||
PGPOOL= | (number, warnlevel) Specifies the size of the cluster page pool and the warning level for cluster page pool utilization. The cluster page pool stores the GSSB, ULS and the service data of users (USER statement) who are generated with RESTART=YES. The cluster page pool can be extended during cluster operation while leaving the number of files unchanged, see the applicable openUTM manual “Using UTM Applications”. | ||||||||||||
number | Size of the cluster page pool in UTM pages. For each generated node, at least 500 UTM pages are needed in the cluster page pool. The size of a UTM page is defined in the BLKSIZE operand of the MAX statement. Default: 10,000 or the minimum size If the value specified here is smaller than the minimum value that UTM calculates from the number of generated nodes and the length generated in MAX RECBUF=length, then UTM increases number to the minimum size. | ||||||||||||
| warning level | Percentage value specifying the cluster page pool utilization level at which a warning (message K041) is output. Default: 80 Please note that the messages indicating that cluster page pool utilization has risen above or fallen below the warning level are only output for the node application that triggers the associated change in state. In contrast, all running node applications are affected by a potential cluster page pool bottleneck. | ||||||||||||
PGPOOLFS= | number Number of files over which the user data is to be distributed in the cluster page pool. The cluster page pool files are created using the cluster filebase that is specified in the CLUSTER-FILEBASE operand. They are given the suffixes CP01, CP02, .... CP10. In addition, KDCDEF always creates a file with the suffix CPMD which is used to manage the cluster page pool and does not contain any user data. Default: 1 | ||||||||||||
RESTART-TIMER-SEC= | time Maximum time in seconds that a node application requires for a warm start after a failure. After a failure has been detected and the failure command for a failed node application has been called, the monitoring node application starts a timer with the time specified here. If the failed node application is not available after this time has expired, the emergency command is started for the failed node application. If a value of 0 is specified, no timer is set for monitoring the restart of the failed node application. Minimum value: 0, i.e. restart of the application is not monitored. | ||||||||||||