IBM Support

IT22401: Message may be lost if it was put with MQPMO_ASYNC_RESPONSE while the client-server channel is being quiesced

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • If a message is put from a client using the option
    MQPMO_ASYNC_RESPONSE (this is the default behaviour in some Java
    or JMS client situations) it might be lost.
    
    This can only happen if the client-server channel is being
    quiesced at the time the message is put.
    

Local fix

  • Modify MQI applications to set MQPMO_SYNC_RESPONSE in the put
    message options. Ensure the application does not set
    MQPMO_ASYNC_RESPONSE.
    
    For JMS or XMS applications, set PUTASYNCALLOWED=NO on the
    Destination, to ensure that a synchronous PUT response is
    requested.
    
    If a synchronous response is requested by performing this local
    fix, the application will receive MQRC_CONNECTION_QUIESCING if
    the MQPUT fails because the channel is quiescing, however,
    accounting and statistics messages will not account for this
    failed MQPUT.
    

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    Users putting messages using a client, where the MQPUT is using
    the options MQPMO_ASYNC_RESPONSE and MQPMO_FAIL_IF_QUIESCING
    (this is the default behaviour in some JMS client situations) at
    the time the client-server channel is being quiesced by the
    administrator.
    
    
    Platforms affected:
    MultiPlatform
    
    ****************************************************************
    PROBLEM DESCRIPTION:
    While the SVRCONN channel is in "quiescing" state, if the client
    sends an MQPUT that includes MQPMO_FAIL_IF_QUIESCING within
    MQPMO.Options, the MQPUT fails with Reason =
    MQRC_CONNECTION_QUIESCING.
    
    However, when the SVRCONN channel program fails the client MQPUT
    in this way, it does so without executing the following:
    - incrementing accounting and statistics information for the
    queue
    - calling MQPUT API exits
    - in the async case, recording the failed status for inspection
    by a later app call to MQSTAT
    - in the async case, remembering that the current transaction is
    rollback-only
    
    As a result, in the async case, it was possible for such an
    MQPUT to appear to have succeeded when in fact it failed.
    
    Also the transaction that was open at the time of the failed
    asynchronous MQPUT appeared to succeed, even though it should
    have failed because of the failing MQPUT.
    
    Client MQPUT1 was also affected in the same way as MQPUT.
    

Problem conclusion

  • Client MQPUTs in these circumstances will be failed with Reason
    = MQRC_CONNECTION_QUIESCING, but the various items above will be
    executed:
    - incrementing accounting and statistics information for the
    queue
    - calling MQPUT API exits
    - in the async case, recording the failed status for inspection
    by a later app call to MQSTAT
    - in the async case, remembering that the current transaction is
    rollback-only
    
    ---------------------------------------------------------------
    The fix is targeted for delivery in the following PTFs:
    
    Version    Maintenance Level
    v7.1       7.1.0.9
    v7.5       7.5.0.9
    v8.0       8.0.0.8
    v9.0 CD    9.0.5
    v9.0 LTS   9.0.0.3
    
    The latest available maintenance can be obtained from
    'WebSphere MQ Recommended Fixes'
    http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037
    
    If the maintenance level is not yet available information on
    its planned availability can be found in 'WebSphere MQ
    Planned Maintenance Release Dates'
    http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309
    ---------------------------------------------------------------
    

Temporary fix

Comments

APAR Information

  • APAR number

    IT22401

  • Reported component name

    WMQ BASE MULTIP

  • Reported component ID

    5724H7241

  • Reported release

    750

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2017-09-14

  • Closed date

    2017-10-31

  • Last modified date

    2017-12-04

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

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

Fix information

  • Fixed component name

    WMQ BASE MULTIP

  • Fixed component ID

    5724H7241

Applicable component levels

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSDEZSF","label":"IBM WebSphere MQ Managed File Transfer for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.5","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
31 March 2023