IBM Support

IT22064: MQ default put response (DEFPRESP) behaves unexpectedly when putting to cluster queues using MQPMO_RESPONSE_AS_Q_DEF

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.


APAR status

  • Closed as program error.

Error description

  • MQ queues provide several administrative attributes that can
    set default values for certain message properties.  When putting
    to a cluster queue, values like persistence and priority may be
    set based on the DEFPSIST and DEFPRTY settings of the cluster
    queue to which the message is put.  If the putting application
    is using MQ to round-robin the messages to different instances
    of the cluster queue, the persistence and priority can even vary
    if the cluster queue instances have inconsistent DEFPSIST and
    DEFPRTY values.
      However, the default put response setting (DEFPRESP) which
    decides whether client MQPUT calls should be synchronous (wait
    for a response) or asynchronous ("fire and forget") does not
    behave like the other values.  An application which MQPUTs to
    a cluster queue using MQPMO_RESPONSE_AS_Q_DEF will find that
    the DEFPRESP value used comes from 1) a local instance of the
    cluster queue if there is one, or 2) the cluster transmission
    queue, and not from the target cluster queue.

Local fix

  • Use MQPMO_ASYC_RESPONSE to ensure asynchronous MQPUTs are used
    or MQPMO_SYNC_RESPONSE to ensure synchronous MQPUTs are used.

Problem summary

  • ****************************************************************
    User who set the default put response attribute (DEFPRESP) of a
    cluster to queue to ASYNC
    Platforms affected:
    When a user has set the default put response attribute
    (DEFPRESP) of a cluster queue to ASYNC, there is an expectation
    that all puts are deemed to succeed (fire and forget).
    If / when the user wants information about the puts that have
    been performed, then using the MQSTAT should be used. This will
    provide statistic on the put operations success and failures.
    The problem was that DEFPRESP attribute was incorrectly derived
     during name resolution, from the SYSTEM.CLUSTER.TRANSMIT.QUEUE
    (which is by default set to SYNC) and not the final resolved
    queue. As a  result, a failure was immediately returned to the
    application requiring appropriate error handling and over-riding
    the "fire and forget" which the user requested and expected for
    continual putting of messages.

Problem conclusion

  • The code has been fixed to obtain the DEFPRESP attribute from
    the appropriate cluster queue during name resolution.
    The fix is targeted for delivery in the following PTFs:
    Version    Maintenance Level
    v9.0 LTS
    v9.1 CD    9.1.2
    v9.1 LTS
    The latest available maintenance can be obtained from
    'WebSphere MQ Recommended Fixes'
    If the maintenance level is not yet available information on
    its planned availability can be found in 'WebSphere MQ
    Planned Maintenance Release Dates'

Temporary fix


APAR Information

  • APAR number


  • Reported component name


  • 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:


Fix information

  • Fixed component name


  • Fixed component ID


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