IBM Support

PH05604: MQ Z/OS: LEAK OF ECSA STORAGE IN SUBPOOL 231 KEY 7 DURING STARTUP IF THERE IS A REPEATED PROBLEM CONNECTING TO DB2

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • ABEND878-08 occurs due to high use of ECSA storage by an MQ
    MSTR job in Subpool 231 key 7 SP231 KEY7 K7
    
    Many storage segments shown in IPCS OWNCOMM output have a
    length of x'000002A0'.  The getmains are from CSQSGMN. The
    storage has eycatchers that look like
    
    ........SYSOPR
    ........245.DB2MST00............
    ........CSQ1    ........
    
    where CSQ1 is the queue manager name.
    
    The first word of storage is 007102A0, which is associated with
    an MQ CCB control block.
    
    The growth in ECSA occurs when there are repetitive abends when
    CSQ5CONN calls DB2. During queue manager startup, CSQ5CONN is
    called on the DB2MST00 internal task in the queue manager to
    establish the initial connection from the queue manager to DB2.
    While MQ is attempting to read the queue manager object from
    DB2, the abend occurs. CSQ5CONN retries and ends gracefully.
    This causes the DB2MST00 task to end and another to be
    automatically started. The new task similarly attempts to read
    the queue manager object, abends, and ends on retry, causing a
    new task to be started. If the underlying problem is
    persistent, it causes a loop in the connection processing from
    MQ to DB2.
    
    Because this is during queue manager startup, the CCB control
    blocks for the tasks are not obtained/freed from the usual PHB
    pool and are instead obtained using CSQSGETM. The expectation
    is that these tasks are long running internal tasks, and so the
    CCBs are not explicitly freed - instead they will be implicitly
    freed at queue manager shutdown.
    
    In normal operation this is fine. However in this situation it
    leads to the CCB for each failed attempt remaining allocated
    for the lifetime of the queue manager. The huge number of
    failed attempts to access DB2 has led to a large amount of ECSA
    being used by the queue manager.
    
    These CCBs should be freed in a more timely manner rather than
    waiting for queue manager shutdown.
    
    
    For one of the reports of this problem, the underlying problem
    was repetitive ABENDs seen in LOGDATA associated with
    SUBFUNCTION DB2 CSQ5CONNREADQMGR and an UNKNOWN module.  The
    PSW was in a vendor module.  There could be other underlying
    abends interrupting the processing.
    
    
    Additional Symptom(s) Search Keyword(s):
    ABENDS878 878 S878 S0878
    000002A0 2A0 x2A0
    
    IEA705I ERROR DURING GETMAIN SYS CODE = 878-08 MSTJCL00
    

Local fix

  • Restart the queue manager if possible. Resolve the underlying
    abend that is preventing the connection from MQ to DB2 from
    working.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
    *                 Release 1 Modification 0.                    *
    ****************************************************************
    * PROBLEM DESCRIPTION: Storage leak of SP231 Key 7 ECSA        *
    *                      storage occurs if tasks repeatedly fail *
    *                      during queue manager startup.           *
    ****************************************************************
    During queue manager startup CSQ3AUGI is called to obtain and
    free CCB control blocks for tasks started before CSQ3AUCM is
    available.
    However CSQ3AUGI only expects to be called to free CCBs during
    queue manager shutdown, and does not explicitly free the storage
    used. This can result in CCBs remaining allocated but unused in
    ECSA until the queue manager shuts down.
    In the reported case, an external error caused the DB2
    connection task to abend and retry repeatedly, resulting in a
    large number of such CCBs remaining allocated and causing a
    shortage of ECSA.
    

Problem conclusion

  • CSQ3AUGI is changed to explicitly free the CCB when called
    during queue manager startup.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PH05604

  • Reported component name

    IBM MQ Z/OS V9

  • Reported component ID

    5655MQ900

  • Reported release

    100

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2018-11-21

  • Closed date

    2019-01-11

  • Last modified date

    2019-02-02

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

    PH02867

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

    UI60628

Modules/Macros

  • CSQ3AUGI
    

Fix information

  • Fixed component name

    IBM MQ Z/OS V9

  • Fixed component ID

    5655MQ900

Applicable component levels

  • R100 PSY UI60628

       UP19/01/26 P F901 ¢

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":"100","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
02 February 2019