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.
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.
db2 => connect to db2spm Database Connection Information Database product = SPM0500 SQL authorization ID = CRUS Local database alias = DB2SPM
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
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.
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, see 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.|
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.
Refer to the DB2 for OS/390 Command Reference for details of the RECOVER command.
[ DB2 List of Books | Search the DB2 Books ]