kc_cluster_par_str - Global properties of a UTM cluster application

The data structure kc_cluster_par_str is defined for the parameter type KC_CLUSTER_PAR. In the case of KC_GET_OBJECT, UTM uses kc_cluster_par_str to return the current settings for the properties of a UTM cluster application together with current data (e.g. generation time, start time, number of active and generated node applications).
You can use KC_MODIFY_OBJECT to modify the following:

• Parameters which control the verification of the individual node applications

• Parameters which control node application access to the cluster configuration file and the cluster administration journal.

mod 1	data structure kc_cluster_par_str
-	struct kc_cluster_filebase cluster_filebase;
-	struct kc_admi_date_time_model gen_time;
-	char os_type[24];
-	char bit_mode[8];
-	char bcamappl[8];
-	char port_nbr[8];
x(GID)	char check_alive_timer_sec[8];
x(GID)	char communication_retry[8];
x(GID)	char communication_reply_timer_sec[8];
x(GID)	char restart_timer_sec[8]:
x(GID)	char file_lock_timer_sec[8];
x(GID)	char file_lock_retry[8];
-	char max_nbr_nodes[4];
-	char curr_nbr_nodes[4];
-	char nbr_active_nodes[4];
-	char emergency_cmd [200];
-	char failure_cmd [200];
-	struct kc_admi_date_time_model last_kdcdef_time;
-	struct kc_admi_date_time_model cluster_start_time;
-	char abort_bound_service;
x(GID)	char deadlock_prevention;
-	char listener_id[5]; (only on Unix, Linux and Windows systems)
-	char cpgpool[10];
-	char cpgpool_warnlevel[2];
-	char cpgpool_fs[2];

¹ Field content can be modified with KC_MODIFY_OBJECT , see "obj_type=KC_CLUSTER_PAR"

The fields in the data structure kc_cluster_par_str correspond to the configuration information in the KDCDEF control statement CLUSTER, see openUTM manual “Generating Applications”.

The fields in the data structure have the following meanings:

cluster_filebase

Name prefix or directory (base name) of the cluster configuration file and other global administration files of the UTM cluster application, e.g. the administration journal.

The name is passed in the element cluster_filebase of type kc_cluster_filebase:

struct kc_cluster_filebase

char length[2];

char fb_name[54];

fb_name contains the base name and length the length of the base name.

gen_time

Time at which the cluster configuration file was generated. The date and time are returned in the element gen_time of type kc_admi_date_time_model.

struct kc_admi_date_time_model

struct kc_admi_date_model admi_date;

struct kc_admi_time_model admi_time

where

struct kc_admi_date_model

char admi_day [2];

char admi_month [2];

char admi_year_4 [4];

char admi_julian_day [3];

char admi_daylight_saving_time

and

struct kc_admi_time_model

char admi_hours [2];

char admi_minutes [2];

char admi_seconds [2]

os_type

System platform of the computer

bit_mode

Mode in which the operating system is running. The following values are returned:

'32 Bit' for 32-bit mode.

'64 Bit' for 64-bit mode.

bcamappl

Name of the transport system endpoint (BCAMAPPL name) that is used for communication within the cluster.

port_nbr

Number of the listener port used for communication within the cluster.

check_alive_timer_sec

In a UTM cluster application, every node application is monitored by another node application (circular monitoring), i.e. each node application monitors the availability of another node application and is itself monitored by a node application. To do this, the monitoring node application sends messages to the monitored node application at defined intervals (check_alive_timer_sec). If the monitored application is available, it acknowledges the message.
check_alive_timer_sec specifies the interval in seconds at which monitoring messages are sent to the monitored node application.
This timer is also used for periodic access to the cluster configuration file and the cluster administration journal.

KC_MODIFY_OBJECT:
You can modify the monitoring interval.

Minimum value: ‘30'
Maximum value: ‘3600'

communication_retry

Specifies how often a node application repeats an attempt to send a monitoring message if the monitored node application does not respond within the time defined in communication_reply_timer_sec.
If the monitored node application does not respond to any of the retries in the defined time, then it is assumed to have failed and the command sequence defined in failure_cmd is executed (e.g. a restart).

KC_MODIFY_OBJECT:
You can modify the value of communication_retry.

Minimum value: ‘0'
Maximum value: ‘10'

communication_reply_timer_sec

Maximum time in seconds that a node application waits for a response after sending a monitoring message.
If no response is received within this period then the monitored node application is assumed to have failed (abnormal end of application) and the command sequence defined in failure_cmd is executed (e.g. a restart).

If a value greater than zero is set for communication_retry, then the target node application is only assumed to have failed if, additionally, no response to the monitoring message is received after the final retry.

KC_MODIFY_OBJECT:
You can modify the settings for communication_reply_timer_sec.

Minimum value: '1'
Maximum value: '60'

restart_timer_sec

Maximum time in seconds that a node application requires for a warm start after a failure (abnormal program termination).

The monitoring node application waits for the time specified here after calling the command sequence specified under failure_cmd before sending another monitoring message to this node application. If the monitoring node application does not receive a response to this message, it is assumed that the failed node application can no longer be restarted as a result of a persistent problem. The command sequence specified in emergency_cmd is called for the failed node application.

KC_MODIFY_OBJECT:
You can modify the value of restart_timer_sec.

Minimum value: ‘0', i.e. no time monitoring of restart.
Maximum value: '3600'

file_lock_timer_sec

Maximum time in seconds that a node application waits for a lock to be assigned for accessing the cluster configuration file of the cluster administration journal. file_lock_retry specifies how often a node application repeats the request for a lock on the cluster configuration file or the cluster administration journal if the lock was not assigned in the time specified in file_lock_timer_sec.

KC_MODIFY_OBJECT:
Sets a new value for file_lock_timer_sec.

Minimum value: ‘10'
Maximum value: ‘60'

file_lock_retry

Specifies how often a node application repeats the request for a lock on the cluster configuration file or the cluster administration journal if the lock was not assigned in the time specified in file_lock_timer_sec.

KC_MODIFY_OBJECT:
You can modify the value of file_lock_retry:

Minimum value: ‘1'
Maximum value: ‘10'

max_nbr_nodes

Maximum possible number of node applications that can be generated in a UTM cluster application.

In an XCS cluster of BS2000 systems, a maximum of 16 of the 32 node applications that can be generated can run at any one time.

curr_nbr_nodes

Number of node applications actually generated for this UTM cluster application (corresponds to the number of CLUSTER-NODE statements in the KDCDEF generation of the UTM cluster application).

nbr_active_nodes

Number of node applications currently active (started) in the UTM cluster application.

emergency_cmd

Contains a command to be executed together with its arguments.
This command is called by UTM if a failed node application cannot be restarted and a value greater than zero has been set for restart_timer_sec. I.e., the actions specified in failure_cmd have not resulted in the failed node application being restarted (in time).

failure_cmd

Contains a command to be executed together with its arguments. This command is called by UTM if a node application terminates abnormally or if failure of a node application is detected. The command in failure_cmd can, for example, be used to initiate the restart of a failed node application or to send an e-mail to the system administrator.

last_kdcdef_time

Time of the last generation of a KDCFILE which has been used to start at least one node application.

The date and time are returned in the element last_kdcdef_time of type kc_admi_date_time_model (see gen_time).

cluster_start_time

Time at which the first node application in the UTM cluster application was started.

The date and time of the start are returned in the element cluster_start_time of type kc_admi_date_time_model (see gen_time).

abort_bound_service

'N'	If when a user signs on, there is an open service for this user that is bound to another node application, 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.
'Y'	If when a user signs on at a node application, there is an open 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.

deadlock_prevention

Specifies whether or not UTM is to perform additional checks of the GSSB, TLS and ULS data areas in order to prevent deadlocks.

'N'	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.
'Y'	UTM performs additional checks of the GSSB, TLS and ULS data areas in order to prevent deadlocks. In productive operation, it is advisable to set this parameter to 'Y' only if timeouts occur frequently when accessing these data areas.

listener_id (only on Unix, Linux and Windows systems)

This parameter is used to select a network process for internal cluster communication.

cpgpool

Size of the cluster page pool in 4K pages.

cpgpool_warnlevel

Percentage value specifying the cluster page pool utilization level at which a warning (message K041) is output.

cpgpool_fs

Number of files over which the user data is distributed in the cluster page pool.