IBM Support

PM70109: WEBSPHERE MQ V7, ABEND 0C4-00000011 IN CSQXSGET, PROBLEM WILL ONLY OCCUR WHEN A WAS ADDRESS SPACE IS ENDING ABNORMALLY.

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Error DescriptionÏ
    The 0C4s in CSQXSGET are the follow-on problems from the abends
    in the WSAS address space and are occuring during clean-up
    processing. An async consume TCB is going through end-of-task
    processing. CSQMEOTC has been invoked and has invoked CSQADELT
    to delete conversion tables etc.. Before invoking CSQADELT,
    CSQMEOTC sets R13 to the address of CSQBSRV's working storage
    in the BLOA (CSQBSRV_WS). The prolog in CSQXSGET (CSQVLSM9)
    detects that there is a stack header block (XSTKH; indicated by
    'CSQA' in the first word of the save-area) and addresses the
    stack header (16 bytes prior to the save-area). It then picks
    up the address of the stack parm block, XSPM. However, the
    address is in another BLOA which has been released (due to the
    TCB which attached the async consume TCB ending), hence the 0C4
    occurs.
    

Local fix

  • Local FixÏ
    none
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 *
    *                 Release 0 Modification 1 and Release 1       *
    *                 Modification 0.                              *
    ****************************************************************
    * PROBLEM DESCRIPTION: The application address space abends    *
    *                      with S0C4-00000011 when the using       *
    *                      async-consume.                          *
    *                      This problem can occur when async-      *
    *                      consume is not used properly (i.e.      *
    *                      stopping the async-consume thread       *
    *                      and the disconnect step is not done)    *
    *                      or an abend occurs in the application   *
    *                      address space whilst an async-consume   *
    *                      thread is active.                       *
    *                      This problem can occur when WebSphere   *
    *                      Application Server is abending.         *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    A control thread is started and connects to MQ. As part of this
    a BLOA control block is allocated, containing a space for stack
    storage. When the control thread starts the async-consume
    thread with MQCTL-MQOP_START, a new BLOA control block is
    allocated for the async-consume thread. However this one
    contains a pointer back to the control threads BLOA, in order
    to be able to use it's connection when doing MQAPI calls. It
    also shares the control threads BLOA's stack storage.
    In the case where the async-consume thread is left running
    after the control thread has gone through end of task
    processing, for instance if the application address space is
    abending, the async-consume thread is left with pointers to the
    control threads BLOA, which has now been freed. Any attempt to
    access it will cause an 0C4.
    

Problem conclusion

  • The code was changed to correctly terminate the async consume
    thread with abend 5C6-00C20009 when the control thread goes
    through end of task processing whilst the async consume thread
    is still active.
    010Y
    100Y
    CSQBDSC
    CSQBSRV
    CSQMDALL
    CSQMEOTC
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM70109

  • Reported component name

    WMQ Z/OS V7

  • Reported component ID

    5655R3600

  • Reported release

    010

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2012-08-02

  • Closed date

    2012-11-27

  • Last modified date

    2013-02-04

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

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

    UK83774 UK83775

Modules/Macros

  • CSQBDSC  CSQBSRV  CSQMDALL CSQMEOTC
    

Fix information

  • Fixed component name

    WMQ Z/OS V7

  • Fixed component ID

    5655R3600

Applicable component levels

  • R010 PSY UK83774

       UP13/01/16 P F301

  • R100 PSY UK83775

       UP13/01/16 P F301

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

Document Information

Modified date:
04 February 2013