Alert monitor (CKAM)

The alert monitor transaction, CKAM, performs two functions: handling pending events that occur as a result of connect or disconnect requests to instances of IBM® MQ, and calculating the maximum number of MQGET calls that an MQMONITOR can issue per second.

CKAM and pending events

When pending events occur, the alert monitor generates messages that are sent to the system console.

Pending events are of two kinds:
Deferred connection
A pending event (called a deferred connection) is activated if CICS® tries to connect to IBM MQ before a suitable queue manager is started. A suitable queue manager could be either a single named queue manager or a member of an IBM MQ queue-sharing group, depending on the setting for the connection. When a suitable queue manager is available, the CICS-MQ adapter issues a connection request, a connection is made, and the pending event is canceled.

You can have multiple deferred connections, one of which is connected when a suitable queue manager is started.

If you are using an IBM MQ queue-sharing group for the connection, and all the queue managers in the group are unavailable, the CICS-MQ adapter initiates connection to each queue manager in turn, resulting in multiple deferred connections. When one of the queue managers is started, the CICS-MQ adapter makes the connection. If more than one queue manager is started on the same LPAR, the CICS-MQ adapter connects to one of them.

Termination notification
When a connection is successfully made to IBM MQ, a pending event called a termination notification is created. This pending event expires when one of the following occurs:
  • The queue manager to which CICS is connected shuts down normally with MODE(QUIESCE). The alert monitor issues a quiesce request on the connection.
  • The queue manager shuts down with MODE(FORCE) or ends abnormally.
  • The connection is shut down from the CKQC transaction.

The maximum number of pending events that CICS can handle is 99. If this limit is reached, no more events can be created until at least one current event expires.

The alert monitor stops itself when all pending events have expired. It is subsequently restarted automatically by any new connect request.

CKAM and MQMONITORs

If the z/OS® Workload Manager health service is active in a CICS region, changes in the region's health state can have an effect on MQMONITORs, in which CKAM plays a part as follows:

  • When the region's z/OS WLM health value is less than 100, CKAM calculates the maximum number of MQGET calls that an MQMONITOR can issue per second. For details on the formula that is used to calculate this throttle and the effect of the z/OS Workload Manager health service can have on MQMONITORs, see Effect of z/OS Workload Manager Health service on MQMONITORs.
  • When the z/OS WLM health open status is OPENING and the region's health value is greater than zero (for example, during a CICS warm-up process), CKAM starts all MQMONITORs that have been defined with AUTOSTART(YES).
  • When the z/OS WLM health open status is CLOSED and the region's health value is zero (for example, by the end of a CICS cool-down process, or after SET WLMHEALTH IMMCLOSE is issued), CKAM stops all MQMONITORs.
If CICS encounters an MXT condition, CKAM calculates, as shown in the following formula, the maximum number of MQGET calls that an MQMONITOR can issue per second while this condition exists. This restriction limits the number of tasks being started by MQMONITORs when CICS is at MXT. When the condition no longer exists, CKAM removes the restriction.
Formula: The maximum number of MQGET calls is MXT plus 10%.

To determine whether MXT gating has taken place, see Interpreting transaction statistics.