A fix is available
APAR status
Closed as program error.
Error description
XA connections unexpectedly receive XAER_NOTA on an XAEND call. The problem addressed by this APAR will only occur if there are two types of XA work in the system: firstly, work connecting over a channel with CSQSERVICE1 set, and secondly, work connecting over a normal client channel that is using QSG-scope XA transactions. CSQSERVICE1 is added by PI36807 (MQ 7.1) / PI49236 (MQ 8.0). In the reported case, the client performed the following sequence of XA calls: XASTART which returns OK XAEND which returns XAER_NOTA XAEND which returns XAER_NOTA The XA transaction ID for the 3 calls is the same, so for XAEND calls made immediately after the XASTART, MQ should know about the transaction and not return XAER_NOTA. If the client application responds to the error code by ending the thread without attempting to close the MQ connection, then the following error can occur: CSQX209E CSQXRESP Connection unexpectedly terminated, channel <channel name> connection <connection name> (<ip address>) (queue manager <queue manager name>) TRPTYPE=TCP RC=00000000 Additional Symptom(s) Search Keyword(s): XA_END XA_START Tuxedo client SVRCONN
Local fix
N/A
Problem summary
**************************************************************** * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 * * Release 1 Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: An XA client connection, using a * * channel with the CSQSERVICE1 keyword, * * unexpectedly receives XAER_NOTA (-4) * * on an XAEND call for a transaction * * that is known to MQ. * **************************************************************** * RECOMMENDATION: * **************************************************************** A queue manager is being used by two different XA client applications. One application is using XA transactions with a transaction scope of the QSG name. The other application is connecting over a SVRCONN channel with the keyword CSQSERVICE1 in its description, and an XA transaction scope of the QMGR name. If the CSQSERVICE1 application issues XASTART for an XA transaction, and subsequently issues XAEND for the same transaction ID, MQ may check for the transaction in the wrong transaction scope. This results in a return code of -4 (XAER_NOTA), incorrectly indicating that MQ has no knowledge of the requested transaction ID.
Problem conclusion
MQ has been changed to check the correct transaction scope when locating XA transaction IDs for CSQSERVICE1 connections. 100Y CSQMXARH
Temporary fix
Comments
APAR Information
APAR number
PI68962
Reported component name
WMQ Z/OS V7
Reported component ID
5655R3600
Reported release
100
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2016-09-09
Closed date
2016-10-25
Last modified date
2016-12-01
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI41980
Modules/Macros
CSQMXARH
Fix information
Fixed component name
WMQ Z/OS V7
Fixed component ID
5655R3600
Applicable component levels
R100 PSY UI41980
UP16/11/26 P F611
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.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
01 December 2016