IBM Support

PI14456: CSQ1,ABN=5C6-00E2000B,U=XXXXXX,C=R3600.710.ASMC-CSQVICEU, M=CSQVEUS2,LOC=CSQSLD1.CSQSFBK+00000DDA - BUILDUP OF ITRQP CBS

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • The customer is running WebSphere MQ V7.1 and they are
    receiving the 5C6-00E2000B. This has occurred due to the queue-
    manager going short on storage due to the problem with the
    ITRQP control blocks associated with a specific queue. These
    ITRQP control blocks should only be present when commits
    are performed while an MQGET is in-progress. However, it looks
    as though IVSA.lGetCursCnt is set to 1 although there are
    actually no in-progress MQGETs.
    .
     From the dump the change team can see that a very large
    proportion of these ITRQP control blocks have been incorrectly
    built. That is, the RPR of the message that they relate to
    should be in ITRQP_CRPR but the control blocks actually contain
    an address (also ITRQP_CSTCK should contain the STCK of the
    message, but it is 0). the Change team can see that this problem
    with the control blocks being incorrectly built could occur if
    there is a problem during MQPUT processing, for instance if the
    application passed an invalid buffer address, resulting in MQRC
    2004, MQRC_BUFFER_ERROR, which is the reason for the
    incorrectly-built ITRQP control blocks.
    .
     The change team has not been able to determine why these
    control blocks have not been released though (which lead to the
    short-on-storage experienced by the QMGR). We are taking this
    APAR so that the change team can investigate further how these
    incorrect ITRQP control blocks can go unreleased.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 *
    *                 Release 1 Modification 0.                    *
    ****************************************************************
    * PROBLEM DESCRIPTION: Build up of invalid ITRQP control       *
    *                      blocks occurs following failing MQPUT   *
    *                      calls, leading to increased get/browse  *
    *                      times and storage shortages in the      *
    *                      queue manager address space.            *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    An application attempting to put a message to a queue fails (for
    example, due to CSQI_PAGESET_FULL) and rel_locks is called to
    release any request locks obtained during the failing MQPUT.
    If the queue being put to is also being processed by any MQGET
    calls, an ITRQP is incorrectly queued to the IVSA for the
    queue by rel_locks.
    The invalid ITRQP causes any in progress MQGETs to restart
    scanning the page chain, delaying completion of the MQGET
    request.
    The invalid ITRQPs will be freed when the last MQGET using them
    completes. In some cases the page chain rescans caused by the
    invalid ITRQPs can delay the MQGET request long enough for
    further invalid ITRQPs to be created, resulting in additional
    rescans, and delays the freeing of the invalid blocks. This
    can lead to the storage used by the ITRQP pool growing and
    potentially leading to a short on storage condition and
    abends relating to insufficient available storages e.g. S878
    

Problem conclusion

  • CSQIMPU2 is changed to no longer queue an invalid ITRQP to the
    IVSA chain following a failing MQPUT.
    100Y
    CSQIMPU2
    

Temporary fix

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

Comments

APAR Information

  • APAR number

    PI14456

  • Reported component name

    WMQ Z/OS V7

  • Reported component ID

    5655R3600

  • Reported release

    100

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2014-03-25

  • Closed date

    2014-06-20

  • Last modified date

    2014-08-04

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

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

    UI19014

Modules/Macros

  • CSQIMPU2
    

Fix information

  • Fixed component name

    WMQ Z/OS V7

  • Fixed component ID

    5655R3600

Applicable component levels

  • R100 PSY UI19014

       UP14/07/22 P F407 ¢

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":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
04 August 2014