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 number
IT22064
Reported component name
WMQ BASE MULTIP
Reported component ID
5724H7241
Reported release
750
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2017-08-19
Closed date
2019-01-24
Last modified date
2019-01-24
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
[{"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