PI52685: LARGE NUMBER OF ACCESSES TO CSQ.OBJ_B_QUEUE USING PLAN CSQ5R800

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The initial symptom was 800,000 DB2 SMF records being cut per
  hour as a result of MQ activity.  DB2 traces tracked this to
  plan CSQ5R800 and identified very many sequences of
  open/fetch/close on CSRQUEUE cursor in CSQ5AROB.
  
  Periodically, the queue-manager will check in DB2 for any new
  queues which have been created. It should only check for new
  queues since the last time it checked. However, if a queue
  which is not a temporary dynamic queue is deleted, the 'last
  time checked' time-stamp will be reset to the time the
  queue-manager was started.
  This means that if there are shared dynamic queues being
  deleted frequently (e.g. due to MQCO_DELETE_PURGE being used)
  this can cause the issue seen here with a large number of
  accesses to CSQ.OBJ_B_QUEUE using plan CSQ5R800).
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 8 *
  *                 Release 0 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: Increased CPU usage, and increased      *
  *                      usage in DB2 when permanent dynamic     *
  *                      (shared and private) queues are deleted *
  *                      frequently.                             *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  During the delete processing of a queue, the time the last
  refresh of shared queues from DB2 is reset to the start time of
  the queue manager if the queue being deleted is not a dynamic
  queue. However the logic currently is incorrect for permanent
  dynamic (shared and private) queues, resulting in csRefreshSTCK
  being reset for this type. This results in refresh processing
  going through all new queues defined since the start of the
  queue manager, when this type of dynamic queue is deleted. In a
  system with shared dynamic queues being frequently deleted, this
  will result in higher usage of DB2. This can be seen in DB2 SMF
  accounting records showing higher usage by the MQ plan CSQ5R800.
  

Problem conclusion

• The deletion processing for a queue object has been altered to
  no longer reset the refresh time for shared and permanent
  dynamic queues. This will reduce the number of new queues being
  checked, after a refresh when shared dynamic queues are deleted.
  000Y
  CSQIDDEL
  

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:

  UI33387

Modules/Macros

• CSQIDDEL
  

Fix information

• Fixed component name

  WMQ Z/OS 8

• Fixed component ID

  5655W9700

Applicable component levels

• R000 PSY UI33387

     UP16/01/08 P F601

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.