Administration Guide

Recovery of Indoubt Transactions on the Host

If your application has accessed a host or AS/400 database server within a transaction, there are some differences in how indoubt transactions are recovered.

To access host or AS/400 database servers, DB2 Connect is used. The recovery steps differ if DB2 Connect has the DB2 Syncpoint Manager configured.

Recovery when DB2 Connect Has the DB2 Syncpoint Manager Configured

The recovery of indoubt transactions at host or AS/400 servers is normally performed automatically by the Transaction Manager (TM) and the DB2 Syncpoint Manager (SPM). An indoubt transaction at a host or AS/400 server does not hold any resources at the local DB2 location, but does hold resources at the host or AS/400 server as long as the transaction is indoubt at that location. If the administrator of the host or AS/400 server determines that a heuristic decision must be made, then the administrator may contact the local DB2 database administrator (for example via telephone) to determine whether to commit or roll back the transaction at the host or AS/400 server. If this occurs, the LIST DRDA INDOUBT TRANSACTIONS command can be used to determine the state of the transaction at the DB2 Connect instance. The following steps can be used as a guideline for most situations involving an SNA communications environment.

Connect to the SPM as shown below.

db2 => connect to db2spm
 
 Database Connection Information
 
 Database product       = SPM0500
 SQL authorization ID   = CRUS
 Local database alias   = DB2SPM

Issue the LIST DRDA INDOUBT TRANSACTIONS command to display the indoubt transactions known to the SPM. The example below shows one indoubt transaction known to the SPM. The db_name is the local alias for the host or AS/400 server. The partner_lu is the fully qualified luname of the host or AS/400 server. This provides the best identification of the host or AS/400 server, and should be provided by the caller from the host or AS/400 server. The luwid provides a unique identifier for a transaction and is available at all hosts and AS/400 servers. If the transaction in question is displayed, then the uow_status field can be used to determine the outcome of the transaction if the value is C (commit) or R (rollback). If you issue the LIST DRDA INDOUBT TRANSACTIONS command with the WITH PROMPTING parameter, you can commit, roll back, or forget the transaction interactively. For more information, refer to the Command Reference.
```
db2 => list drda indoubt transactions
 DRDA Indoubt Transactions:
 1.db_name: DBAS3    db_alias: DBAS3    role: AR
   uow_status: C  partner_status: I  partner_lu: USIBMSY.SY12DQA
 corr_tok: USIBMST.STB3327L
 luwid: USIBMST.STB3327.305DFDA5DC00.0001
 xid: 53514C2000000017 00000000544D4442 0000000000305DFD A63055E962000000
      00035F
```
If an indoubt transaction for the partner_lu and for the luwid is not displayed, or if the LIST DRDA INDOUBT TRANSACTIONS command returns as follows:
```
db2 => list drda indoubt transactions
SQL1251W  No data returned for heuristic query.
```
then the transaction was rolled back.
There is another unlikely but possible situation that may occur. If an indoubt transaction with the proper luwid for the partner_lu is displayed, but the uow_status is "I", the SPM doesn't know whether the transaction is to be committed or rolled back. In this situation, you should use the WITH PROMPTING parameter to either commit or roll back the transaction on the DB2 Connect workstation. Then allow DB2 Connect to resynchronize with the host or AS/400 server based on the heuristic decision.

Recovery when DB2 Connect Does Not Use the DB2 Syncpoint Manager

Use the information in this section when TCP/IP connectivity is used to update DB2 for OS/390 in a multisite update from either DB2 Connect Personal Edition or DB2 Connect Enterprise Edition, and the DB2 Syncpoint Manager is not used. The recovery of indoubt transactions in this situation differs from that for indoubt transactions involving the DB2 Syncpoint Manager. When an indoubt transaction occurs in this environment, an alert entry is generated at the client, at the database server, and (or) at the Transaction Manager (TM) database, depending on who detected the problem. The alert entry is placed in the db2alert.log file. For more information on alerts, refer to the Troubleshooting Guide manual.

The resynchronization of any indoubt transactions occurs automatically as soon as the TM and the participating databases and their connections are all available again. You should allow automatic resynchronization to occur rather than heuristically force a decision at the database server. If, however, you must do this then use the following steps as a guideline.
Note: Because the DB2 Syncpoint Manager is not involved, you cannot use the LIST DRDA INDOUBT TRANSACTIONS command.

On the OS/390 host, issue the command DISPLAY THREAD TYPE(INDOUBT).

From this list identify the transaction that you want to heuristically complete. Refer to the DB2 for OS/390 Command Reference for details of the DISPLAY command. The LUWID displayed can be matched to the same luwid at the Transaction Manager Database.
Issue the RECOVER THREAD(<LUWID>) ACTION(ABORT|COMMIT) command, depending on what you want to do.
Refer to the DB2 for OS/390 Command Reference for details of the RECOVER command.

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

[ DB2 List of Books | Search the DB2 Books ]