IBM Support


A fix is available


You can track all active APARs for this component.


APAR status

  • Closed as program error.

Error description

  • Queue manager terminates with 00E50705 after GET processing
    fails. When attempting to post get waiters CSQM1PGW abends with
    ABEND5C6 00D401F1 which Level 3 found is due to the async
    consume processing being performed by the CHIN. A client
    channel has issued a browse against its target queue
    followed by a destructive MQGET with MQGMO_MSG_UNDER_CURSOR.
    As async consume is being used by the client, CSQMGETM
    is invoked to process the request and adds MQGMO_SET_SIGNAL
    to the MQGET request. This results in the handle being added
    to the get-wait chain. However, as MQGMO_MSG_UNDER_CURSOR
    is specified, none of the flags in mhnd.lflDMCGopts2 are set.
    The message is successfully retrieved from the queue, and
    then CSQMGET attempts to remove the handle from the get-wait
    chain. However, it suspends waiting for the get-wait chain
    latch, which is currently held by CSQM1PGW which has been
    invoked by commit processing as a new mesage has been put
    to the target queue. CSQM1PGW processes the handle from
    the client channel and detects that mhnd.lflDMCGopts2 is 0.
    This is an unexpected situation and hence the ABEND5C6 is
    issued. As CSQM1PGW is running on a commit SRB and is
    holding a latch at the time of the abend, the queue-manager
    terminates with 00E50705. CSQM1PGW needs to allow for a
    handle with mhnd.lflDMCGopts2 being set to 0 in the case
    where mhnd.fGMsgUCursor or mhnd.fGBrUCursor are on.

Local fix

  • N/A

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 QMGR abends with 00D401F1 when an   *
    *                      application tries to put a message to   *
    *                      a queue which is in use by an           *
    *                      application doing browse messages       *
    *                      followed by a get call with             *
    *                      MQGMO_MSG_UNDER_CURSOR.                 *
    *                      A consequence of this abend happening   *
    *                      could be abends including 00E50013,     *
    *                      00E50044 and 00E50705, as well as       *
    *                      queue manager termination.              *
    * RECOMMENDATION:                                              *
    An application using the internal API (such as the MQ
    Async-Consume feature) is browsing a queue followed by a get
    with the MQGMO_MSG_UNDER_CURSOR option.
    In CSQMGET, the application will put and remove its handle from
    the get-wait chain, whilst holding the MPDO latch. When trying
    to get the latch before removing the handle from the chain, the
    application is suspended (waiting for the latch).
    In parallel another application is putting a message to the same
    queue. As part of the commit processing, the get-wait chain is
    scanned whilst holding the MPDO latch (causing the first
    application to get suspended). The handle of that application is
    found, and the options are checked. They do not match the
    expected value, causing the 00D401F1 abend to be issued, leaving
    the unit of work in flight.
    Depending on the type of application that does the put, IMS,
    CICS, batch etc. any abends following the 00D401F1 may vary.

Problem conclusion

  • The code was changed to avoid creating the condition by the use
    of the internal API, preventing the 00D401F1 from happening.

Temporary fix

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


APAR Information

  • APAR number


  • Reported component name

    WMQ Z/OS V7

  • Reported component ID


  • Reported release


  • Status


  • PE




  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date


  • Closed date


  • Last modified date


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

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

    UK83936 UK83937



Fix information

  • Fixed component name

    WMQ Z/OS V7

  • Fixed component ID


Applicable component levels

  • R010 PSY UK83936

       UP13/01/16 P F301 Ž

  • R100 PSY UK83937

       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