Tuning coupling facility list monitoring

Use this topic to understand coupling facility list monitoring

Coupling facility (CF) list monitoring is used to monitor the state of list structures containing IBM MQ shared queues. When a message is added to a shared queue, and the queue's depth transitions from zero to non-zero, the CF notifies all queue managers in the queue sharing group. When notified the queue managers might perform a number of actions, including notifying trigger monitors that are using TRIGGER(FIRST), or applications which are performing a get-wait.

By default, the CF notifies all queue managers in the queue sharing group at the same time. In certain configurations this can cause problems, such as:

  • Skewed workload distribution, where a large percentage of messages go to a particular queue manager in the queue sharing group, often the queue manager running on the fastest LPAR, or which is closest to the CF, or
  • A large number of failed gets, resulting in wasted CPU time.

z/OS® V2R3 introduces a new coupling facility resource manager (CFRM) attribute called KEYRNOTIFYDELAY, which can be used with list structures containing shared queues (that is, application structures, and not the admin structure), and which can, for certain workloads, minimize the effects of workload skewing and empty MQGET calls, or empty MQGET calls.

KEYRNOTIFYDELAY can only be set on structures in a CF, running at CFLEVEL 22 or higher.

Its value must be one to seven decimal digits, in a range from 0 to 1,000,000 microseconds. If set to a non-zero value and the depth of a queue transitions from zero to non-zero, the CF selects a single queue manager from the queue sharing group, and notifies that queue manager before all the other queue managers in the group.

The queue manager is selected in a round-robin manner. If the selected queue manager does not process the message inside the time interval described by KEYRNOTIFYDELAY all the other queue managers in the queue sharing group will also be notified.

More information on KEYRNOTIFYDELAY is available here: Understanding Keyrange Monitoring Notification Delay.

Note that there are two similar CFRM attributes called LISTNOTIFYDELAY and SUBNOTIFYDELAY. Neither of these has any measurable effect on IBM MQ workload.