IBM Books

Administration Guide


XA Interface Problem Determination

When an error is detected during an XA request from the TM, the application program may not be able to get the error code from the TM. If your program abends or gets a cryptic return code from the TP Monitor or the TM, you should check the First Failure Service Log, which reports XA error information when diagnostic level 3 or greater is in use.

For more information about the First Failure Service Log, see the Troubleshooting Guide manual. In addition to this source of information for problem determination, you should also consult the console message, TM error file or other product-specific information provided by the external transaction processing software being used. Refer to the documentation of your transaction processing product for more details in this area.

The database manager writes all XA specific errors to the First Failure Service Log with SQLCODE -998 (transaction or heuristic errors) and the appropriate reason codes. The following are some of the more common reasons for errors:

The following example displays an XA open error generated on an AIX platform due to a missing XA open string.

Figure 37. Error Log for XA Open Error

Tue Apr  4 15:59:08 1995
toop pid(83378) process (xatest) XA DTP Support      sqlxa_open Probe:101
DIA4701E Database "" could not be opened for distributed transaction
processing.
String Title : XA Interface SQLCA  pid(83378)
SQLCODE = -998  REASON CODE: 4  SUBCODE: 1
Dump File : /u/toop/diagnostics/83378.dmp Data : SQLCA

Using Encina for Transaction Processing Through TM-XA Interface

When using Encina for transaction processing with DB2 through the TM-XA interface, please note the following:

  1. Encina nested transactions are not currently supported by the DB2 XA interface. If possible, avoid their use. If their use cannot be avoided, make sure that SQL work is done in only one member of the Encina transaction family.
  2. If a thread of control is associated with a particular transaction and intends to switch the association to a different transaction, it can do so only after resolving (committing or aborting) the transaction with which it is associated currently.

In the event that a RELEASE statement is used to release a connection to a database, a CONNECT statement, rather than SET CONNECTION, should be used to reconnect to that database.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]

[ DB2 List of Books | Search the DB2 Books ]