obj_type=KC_CLUSTER_PAR

You want to modify the circular monitoring settings for the node applications in a UTM cluster application (Unix, Linux and Windows systems) and/or the settings for node application access to the cluster configuration file and the administration journal of the UTM cluster application (Unix, Linux and Windows systems).

To do this, you must enter the new property values in the the data structure kc_cluster_par_str via the data area.

Possible modification

The following table indicates the settings that you are able to modify.

Field name	Meaning
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. openUTM also uses this timer in order to access the cluster configuration file and the administration journal periodically in order to check for possible updates. Minimum value: ‘30'' Maximum value: ‘3600'
communication_retry	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 defined time. 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. Minimum value: ‘0'' Maximum value: ‘10''
communication_reply_timer_sec	communication_reply_timer_sec specifies the maximum time in seconds that a node application waits for a response after sending a monitoring message. If the monitored node application does not respond in the defined time, then it is assumed to have failed (abnormal end of application) and the command sequence defined in failure_cmd is executed (e.g. a restart). 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. If a value of 0 is specified, no timer is set for monitoring the restart of a failed node application. Minimum value: 0, i.e. restart of the application is not monitored. Maximum value: 3600
file_lock_timer_sec file_lock_retry	file_lock_timer_sec is the maximum time in seconds that a node application waits for a lock to be assigned for accessing the cluster configuration file or 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. Note: Do not choose too small a value since a timeout when accessing the cluster configuration file can lead to the abnormal termination of the application.
	file_lock_timer_sec: Minimum value: ‘10' Maximum value: ‘60'
	file_lock_retry: Minimum value: ‘1' Maximum value: ‘10'
deadlock_prevention='N' deadlock_prevention='Y'	UTM does not perform any additional verifications for the GSSB, TLS and ULS data areas in order to prevent deadlocks. If a deadlock occurs in one of these data areas then it is resolved via a timeout.
	UTM performs additional verifications for 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.

Period of validity / transaction management: type GID ("KC_MODIFY_OBJECT - Modify object properties and application parameters")