Effect of z/OS Workload Manager health service on MQMONITORs

If the z/OS® Workload Manager health service is active in a CICS® region, CICS can have a warm-up process after the completion of system initialization and can have a cool-down process before shutdown. During either system warm-up or cool-down, CICS adjusts the region's health value to control flow of work into the region. Changes in the region's health state can have an effect on MQMONITORs; for example, when MQMONITORs with attribute AUTOSTART(YES) are started or stopped. When the health value is less than 100, all started MQMONITORs are subject to a throttle limiting the messages that a single MQMONITOR can process.

Effect on when MQMONITORs are started

If MQMONITORs are set to be started automatically, they will be started when the WLMHEALTH open status is OPEN or OPENING and the region's health value is greater than zero.

For example, when system initialization is completed, CICS will start to call the z/OS WLM Health API (IWM4HLTH) at preset intervals to increment the region's health value from zero until it reaches 100%. So, after the first interval, the health value will be greater than zero, and then MQMONITORs with attribute AUTOSTART(YES) are started. The interval and adjustment value is specified in the WLMHEALTH system initialization parameter.

Note: If the z/OS Workload Manager health service is disabled in a CICS region (that is, WLMHEALTH is set to OFF), such MQMONITORs will be started immediately after control is given to CICS at the end of system initialization.

Effect on when MQMONITORs are stopped

MQMONITORs with attribute AUTOSTART(YES) will be stopped when the WLMHEALTH open status is CLOSED and the region's health value is zero. For example, if SET WLMHEALTH OPENSTATUS(CLOSE) is issued, the region's health value is decremented at intervals, and when it is zero, such MQMONITORs in the region are stopped.

MQMONITORs with attribute AUTOSTART(YES) will be stopped immediately when SET WLMHEALTH OPENSTATUS(IMMCLOSE) is issued.

Throttle on the number of MQGET calls per second

When the region's z/OS WLM health value is less than 100, there is a throttle on the number of MQGET calls that an MQMONITOR can issue per second, thereby controlling how many trigger tasks are started. The throttle affects all started MQMONITORs in the region. When the region's health value reaches 100, the throttle on MQGET calls is removed. The throttle is calculated by CKAM as follows:

The maximum number of MQGET calls per second is double the value of the MXT value times the region's z/OS WLM health value.

Suppose WLMHEALTH=(20,25) and MXT=400 are specified for the region. The following example illustrates how the amount of maximum MQGET calls per second is changed after each interval during the whole system warm-up process.

Table 1. Example
Time	Health value (%)	Maximum MQGET calls per second
0 (End of system initialization)	0	0
20	25	200
40	50	400
60	75	600
80 (End of system warm-up)	100	Throttle removed

Likewise, during the system cool-down process, the region's health value starts to decrement at intervals, and the throttle on MQGET calls takes effect. The amount of maximum MQGET calls an MQMONITOR can issue per second is gradually reduced at every interval.