PH44368: MQ Z/OS: PROVIDE AN UPDATE THAT WILL MAKE BETTER USE OF THE XES KEYRNOTIFYDELAY PARAMETER AND REDUCE THE NUMBER OF DXWBS

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• In a Queue Sharing Group (QSG) environment, KEYRNOTIFYDELAY
  (abbreviated KRND) was implemented to cut down on the number of
  notifications from XCF to multiple queue managers. The reported
  case had 4 queue managers on each of two LPARs, and the
  Coupling Facility (CF) was local to one of the LPARs.  Most of
  the queue managers had IMS BMP trigger monitors active. and the
  triggered queue had TRIGTYPE(FIRST) and TRIGMPRI(0).
  
  KEYRNOTIFYDELAY was set to 15000 (15 milliseconds), but it
  did not provide much better performance.
  
  A code update is needed in MQ that will cause a decrease in the
  frequency with which XCF drives the MQ list transition exit
  for the case of TRIGTYPE(FIRST) and TRIGMPRI(0).
  When opening a shared queue so that an application can get
  messages from it, do not issue ?IXLLSTC
  REQUEST(WRITE_LCONTROLS) if the current values are already
  compatible with getting messages.
  
  
  The initial symptom that led to implementing
  KEYRNOTIFYDELAY was that the amount of local storage used
  increased in message CSQY220I. A dump showed that a build-up of
  DXWB control blocks occurred based on notifications from XCF
  when the IMS applications performed many opens and closes of
  the shared queues. The DXWB blocks are in z/OS Subpool 229 Key
  7 (SP229 KEY7 K7).  They are not part of an MQ storage subpool
  but are part of the queue manager's local storage.
  
  The worker task (XCFWRK01) that processes the DXWBs had many
  long delays (>1ms). The longest delays were 10's of
  milliseconds, with a few over 100ms. For these long delays, the
  task was suspended waiting on the object latch for a shared
  queue.  The latch was held for an extended period because
  another task was attempting to open the queue, and the CF
  update needed to be repeatedly retried because the queue list
  entry kept being changed by other queue managers.  The way the
  triggered IMS application used the shared queue caused the rate
  at which XCF messages were arriving on the queue manager to
  exceed the rate at which the MQ process could process the
  notifications.
  
  In some situations, a workaround might include using a
  WaitInterval for the MQGET so that more messages can be gotten
  per MQOPEN/MQCLOSE. IMS applications have a difference from
  other applications in that when the commit is done, the queue
  is closed.  It was not a good idea to use a high WaitInterval
  on a second MQGET before the commit was done. In that scenario,
  it helped to reduce the BMP monitors from 8 to 4 (two on each
  LPAR) to reduce the contention and the number of DXWBs.  The
  IMS regions were in a sharing environment, so all of them were
  still eligible to process the triggered work.
  .
  Additional keywords:
  KEYRANGENOTIFYDELAY Key Range Notify Delay
  

Local fix

• A ++APAR will be available.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 1 Modification 0 and Release 2       *
  *                 Modification 0.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: When a trigger-first shared queue is    *
  *                      defined on a CF structure with          *
  *                      KEYRANGENOTIFYDELAY, more trigger       *
  *                      messages than expected can be produced. *
  ****************************************************************
  For a shared queue with TRIGTYPE(FIRST) and TRIGMPRI(0), a
  message arriving on the queue will result in every queue manager
  in the QSG being notified and producing a trigger message.
  
  When the structure holding the shared queue has the
  KEYRANGENOTIFYDELAY attribute set, only one queue manager will
  initially be notified that a message has arrived on the queue.
  This is expected to result in fewer trigger messages being
  produced.
  However, an application opening the queue to process the message
  can cause the rest of the queue managers to receive
  notifications and multiple trigger messages may still be
  produced. In some cases these additional notifications are
  unnecessary and needlessly reduce the benefits of
  KEYRANGENOTIFYDELAY.
  

Problem conclusion

• Shared queue open processing has been changed to remove
  unnecessary notifications being produced for queues with
  TRIGTYPE(FIRST) and TRIGMPRI(0).
  This results in fewer trigger messages being generated when
  utilising the KEYRANGENOTIFYDELAY structure attribute.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UI81070 UI81072

Modules/Macros

• CSQEOSQ  CSQESLCT CSQIDPUT CSQMCLSQ
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R100 PSY UI81072

     UP22/06/29 P F206

• R200 PSY UI81070

     UP22/06/29 P F206

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.