PI65549: WMQ HIGH CPU WHEN BACKING UP STRUCTURES BACKUP CFSTRUCT EXCESSIVE CPU UTILIZATION LOOP IN CSQELBK1

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• High cpu during backup of structures, BACKUP CFSTRUCT .
  Loop in CSQELBK1 during BACKUP CFSTRUCT processing.
  Multiple CSQE121I messages.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 8 *
  *                 Release 0 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: High CPU utilization when backing up a  *
  *                      structure due to a loop in CSQELBK1     *
  *                      reading entries on the                  *
  *                      uncommitted-get-queue.                  *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  High CPU utilization in the queue-manager after BACKUP
  CFSTRUCT() processing due to a loop in module CSQELBK1 reading
  entries on the uncommitted-get-queue.
  The loop occurs when two messages on the uncommitted-get-queue
  have the same entry key, and their combined length exceeds the
  buffer size passed on the call. The queue is key sequenced so
  the two messages are adjacent. CSQELBK1 issues an IXLLSTM
  REQUEST(READ_LIST) passing a 64K buffer to hold the returned
  messages. The first message with the duplicate key is read
  successfully and added to the buffer. The second message would
  exceed the buffer size so READ_LIST returns with reason code
  ixlRsnCodeBufferFull. The key of the next message to read is
  returned in IXL list answer area field LctlKey. CSQELBK1
  processes the messages in the buffer, then re-issues the IXLLSTM
  REQUEST(READ_LIST) to read the next message, specifying the key
  returned in LctlKey. However the key of the next message is a
  duplicate of the message just read, so the first message is read
  again. When the subsequent message is processed READ_LIST again
  returns with ixlRsnCodeBufferFull leading to the reported
  indefinite loop in CSQELBK1.
  

Problem conclusion

• CSQELBK1 has been updated for the reported problem so that
  IXLLSTM REQUEST(READ_LIST) locates the second duplicate key
  entry by it's unique entryid as well as it's key.
  000Y
  CSQELBK1
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

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

  PI58496

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

  UI39515

Modules/Macros

• CSQELBK1
  

Fix information

• Fixed component name

  WMQ Z/OS 8

• Fixed component ID

  5655W9700

Applicable component levels

• R000 PSY UI39515

     UP16/08/25 P F608 ¢

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.