IBM Support

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

A fix is available

Subscribe

You can track all active APARs for this component.

 

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 IBM MQ for z/OS Version 9 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:                                              *
    * None                                                         *
    ****************************************************************
    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.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PI66136

  • Reported component name

    MQ Z/OS V9

  • Reported component ID

    5655MQ900

  • Reported release

    000

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2016-07-19

  • Closed date

    2016-10-17

  • Last modified date

    2017-02-01

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

    PI58496

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

    UI41724

Modules/Macros

  • CSQELBK1
    

Fix information

  • Fixed component name

    MQ Z/OS V9

  • Fixed component ID

    5655MQ900

Applicable component levels

  • R000 PSY UI41724

       UP17/01/10 P F701 ¢

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.

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.0","Edition":"","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
01 February 2017