A fix is available
APAR status
Closed as unreproducible in next release.
Error description
The problem occurs when the first operation in a unit of work is non-persistent and involves a shared queue (in this case URID 0015EF4C6000 performed an in-syncpoint MQGET of a non-persistent shared queue message, followed by an in-syncpoint MQPUT of a persistent shared queue message). When the MQGET was issued, the queue-manager expressed persistent interest in the RRS UR. However, the queue-manager had not yet created a UR, and hence an incorrect value was stored in the persistent interest data associated with the queue-managers interest in the RRS UR (the interest data should contain the URID of the queue-manager UR). Therefore, when the queue-manager was restarted after the LPAR outage, the queue-manager performed resync processing with RRS (ATRIRNI calls), but as the persistent interest data returned was incorrect, URID 0015EF4C6000 was backed-out. Additional Symptom(s) Search Keyword(s): MQ, DB2, RRS, UR, integrity, inconsistent
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 * * Release 0 Modification 1 and Release 1 * * Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: Performing an in-syncpoint MQGET of a * * non-persistent message from a shared * * queue followed by a MQPUT of a * * persistent message to a shared queue, * * without a commit in-between may result * * in an in-doubt unit of work being * * created if an error occurs before a * * commit can take place. This occurs when * * the application is linked using a RRS * * stub. * **************************************************************** * RECOMMENDATION: * **************************************************************** An in-syncpoint MQGET of a non-persistent message from a shared queue results in the queue manager registering persistent interest in a RRS UR. In this scenario a MQ UR is not started during the MQGET, this results in the persistent interest data being incorrectly set. During the MQPUT call, the MQ UR is started, but the persistent interest is not updated in the RRS UR. This can result in an inconsistent state during 2 phase commit processing in RRS, resulting in an indoubt UR.
Problem conclusion
Temporary fix
********* * HIPER * *********
Comments
The code was changed to ensure the persistent interest data in the RRS UR is updated when the related MQ UR is started. This ensures the UR data is consistent and does not result in an indoubt UR. ×**** PE14/10/31 FIX IN ERROR. SEE APAR PI28769 FOR DESCRIPTION
APAR Information
APAR number
PI23325
Reported component name
WMQ Z/OS V7
Reported component ID
5655R3600
Reported release
010
Status
CLOSED UR1
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2014-08-05
Closed date
2014-09-24
Last modified date
2014-11-07
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI21631 UI21632
Modules/Macros
CSQIDLM1 CSQILOGS CSQILOG1 CSQIRRSI CSQI201M CSQMCBCK CSQMCCMT CSQ3BCK CSQ3CMIT CSQ3ONLY CSQ3RRSR
Fix information
Fixed component name
WMQ Z/OS V7
Fixed component ID
5655R3600
Applicable component levels
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
07 November 2014