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

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

• ****************************************************************
  USERS AFFECTED:
  User who set the default put response attribute (DEFPRESP) of a
  cluster to queue to ASYNC
  
  
  Platforms affected:
  MultiPlatform
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  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
  v7.5       7.5.0.10
  v8.0       8.0.0.12
  v9.0 LTS   9.0.0.7
  v9.1 CD    9.1.2
  v9.1 LTS   9.1.0.2
  
  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 is sysrouted FROM one or more of the following:

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

  PH07709

Fix information

• Fixed component name

  WMQ BASE MULTIP

• Fixed component ID

  5724H7241

Applicable component levels