PI68962: MQ Z/OS: XA CONNECTIONS, USING A CHANNEL WITH CSQSERVICE1 ENABLED, UNEXPECTEDLY RECEIVE XAER_NOTA ON AN XAEND CALL.

Obtain the fix for this APAR.

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 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.