APAR status
Closed as program error.
Error description
DEFECTS FIXED IN WEBSPHERE MQ FIX PACK 7.0.1.3
Local fix
Problem summary
**************************************************************** USERS AFFECTED: See detailed description in the Problem Summary section. Platforms affected: All Distributed (iSeries, all Unix and Windows) +Java **************************************************************** PROBLEM SUMMARY: PM09004J Abstract: CORRELID) AND MSG REACHES BACKOUT THRESHOLD AND IS QUEUED TO BACKOUT Q. Users Affected: This issue affects all users with message-driven beans using shared queues that use the WebSphere MQ v7 Resource Adapter and either connect to a WebSphere MQ v6 queue manager on z/OS or use a connection factory that has the PROVIDER property set to "6". Platforms affected: All Distributed (iSeries, all Unix and Windows) +Java Error Description: Prior to MQ V6, the message listener would always use MQMO_MATCH_MSG_ID to locate a message from a message reference. This would be used for both the normal case of doing a destructive get prior to calling the MDB's onMessage method and for the case of a bad message being got prior to putting it to a backout queue or a dead letter queue. As the gets were always matching msgid, it was a requirement for shared queues being serviced by a message listener that the queue needed to be indexed by msgid. At MQ V6 and above, the introduction of msg token matching meant that the Version 2 listener changed the get processing prior to calling onMessage to use MQMO_MATCH_MSG_TOKEN. This removed the need to index shared queues for the working case. Problem Summary: When a message-driven bean throws an exception or rolls back, and the queue agent thread in the Resource Adapter determines that the message should be requeued, the message is removed from the queue using the MsgId so that it can be put to the requeue queue. If the queue is a shared queue in an MQ Queue Sharing Group on z/OS the removal of the message fails with MQRC 2206 if the queue is not indexed by MsgId. Problem Conclusion: The queue agent thread has been changed to get the message by msgtoken, allowing the queue to be indexed by keys other than MsgId. ---------------------------------------------------------------- 136587 Abstract: QUEUE MANAGER CAN APPEAR ACTIVE ON MORE THAN ONE NODE IN A MULTI-INSTANCE QUEUE MANAGER ENVIRONMENT Users Affected: Windows users that are taking advantage of multi-instance queue managers. Platforms affected: Windows Error Description: When control passes from a an active node to a standby node, it is possible that both nodes will report as being active. The "dspmq -x" command can be used to check for active queue manager instances. Problem Summary: The method used for file locking was incorrect and this led to a situation whereby two queue managers could appear as being active. Problem Conclusion: The code was reworked to use an alternative locking strategy which was shown in testing to fix the problem. ----------------------------------------------------------------
Problem conclusion
The defects described above are fixed in fix pack 7.0.1.3. --------------------------------------------------------------- AdditionalKeywords: APARNOPUB
Temporary fix
Comments
APAR Information
APAR number
IC72546
Reported component name
WMQ WINDOWS V7
Reported component ID
5724H7220
Reported release
700
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2010-11-12
Closed date
2010-11-12
Last modified date
2010-11-12
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 WINDOWS V7
Fixed component ID
5724H7220
Applicable component levels
R700 PSY
UP
[{"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.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
31 March 2023