Fixes are available
Closed as program error.
V6 client using XA with CCDT: ---------------------------- The client code does not check whether a CCDT is being used with XA and that CCDT will result in different queue managers being chosen. This means that application will 'appear' to work but if the customer has a resulting crash of the system the XA recovery might not work as expected resulting in indoubt XA work on the WMQ Server requiring manual recovery by the WMQ Administrator. V7 client using XA with CCDT: ----------------------------- The client code DOES check if the CCDT being used will result in a different queue manager being potentially chosen. This results in an exception on the xa_open call and so stops an application from using XA with a CCDT that can result in different queue managers being chosen for the connection.
**************************************************************** USERS AFFECTED: Users of the WebSphere MQ classes for JMS that make use of a CCDT file to connect to the Queue Manager and also take part in an XA transaction. Platforms affected: All Distributed (iSeries, all Unix and Windows) +Java +Java zOS **************************************************************** PROBLEM SUMMARY: When using the WebSphere MQ classes for JMS, Connection Factories can be configured to reference a Client Channel Definition Table (CCDT). If an application uses a Connection Factory that has been configured in this way to create a JMS Connection, the WebSphere MQ classes for JMS will pick an appropriate entry in the CCDT and use that entry to create a connection to a WebSphere MQ queue manager. Similarly, when using the WebSphere MQ Resource Adapter, Activation Specifications can also be configured to make use of a CCDT. When the Activation Specification starts, the Resource Adapter will choose an entry in the CCDT and use the information in the entry to connect to a queue manager. If a Connection Factory or Activation Specification has been configured to use a CCDT that contains a queue manager group, and is trying to use an entry in the CCDT that is part of a queue manager group, the WebSphere MQ classes for JMS and Resource Adapter will throw the exception: JMSWMQ1068 XA_OPEN ERRORCODE: -5 when connecting to WebSphere MQ if they detect that the application creating the JMS connection, or the Activation Specification, is participating in an XA transaction.
The use of queue manager groups in a CCDT within an XA transaction can lead to indoubt transactions remaining on a queue manager in the following situations: 1) The Transaction Manager (for example WebSphere Application Server) crashes or is stopped whilst XA transactions are in flight. 2) The physical connection between the WebSphere MQ classes for JMS or Resource Adapter, and the WebSphere MQ queue manager is broken whilst transactions were in flight. 3) The WebSphere MQ queue manager crashes or is stopped while XA transactions were in flight. If one of these scenarios occurs and an indoubt transaction remains on the queue manager, and the Transaction Manager has no knowledge of the transaction, then the transaction must be manually resolved on the queue manager. Because of this, the WebSphere MQ classes for JMS and Resource Adapter contains logic to prevent the use of CCDTs with queue manager groups in an XA environment. If the WebSphere MQ classes for JMS or Resource Adapter detect this configuration, an exception is thrown containing XA error code XAER_INVAL (-5). This check can be disabled by setting a Java System Property on the Java Runtime Environment that the WebSphere MQ classes for JMS or Resource Adapter are running in. Due to the transactional integrity issues mentioned above, that can be caused by the use of a CCDT with queue manager groups in an XA environment, please contact IBM Support to review the implications that using the property can have in your environment, and to find out how to set the Java System Property once the implications are understood. --------------------------------------------------------------- The fix is targeted for delivery in the following PTFs: v7.0 Platform Fix Pack 184.108.40.206 -------- -------------------- Windows U200352 AIX U853055 HP-UX (PA-RISC) U853082 HP-UX (Itanium) U853087 Solaris (SPARC) U853083 Solaris (x86-64) U853089 iSeries 220.127.116.11 Linux (x86) U853084 Linux (x86-64) U853088 Linux (zSeries) U853085 Linux (Power) U853086 zOS 18.104.22.168 v7.1 Platform Fix Pack 22.214.171.124 -------- -------------------- Windows 126.96.36.199 AIX 188.8.131.52 HP-UX (Itanium) 184.108.40.206 Solaris (SPARC) 220.127.116.11 Solaris (x86-64) 18.104.22.168 iSeries 22.214.171.124 Linux (x86) 126.96.36.199 Linux (x86-64) 188.8.131.52 Linux (zSeries) 184.108.40.206 Linux (Power) 220.127.116.11 zOS 18.104.22.168 Platform v7.5 -------- -------------------- Multiplatforms 22.214.171.124 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 ---------------------------------------------------------------
Reported component name
WMQ AIX V7
Reported component ID
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fixed component name
WMQ AIX V7
Fixed component ID
Applicable component levels