Recovering indoubt transactions on the host when Db2 Connect does not use the Db2 Syncpoint Manager

If your application has accessed a host or System i database server during a transaction, there are some differences in how indoubt transactions are recovered. To access host or System i database servers, Db2 Connect is used. The recovery steps differ if Db2 Connect has the Db2 Syncpoint Manager configured.

About this task

Use the information in this section when TCP/IP connectivity is used to update Db2 for z/OS® in a multisite update from the 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.

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.

Procedure

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

    From this list identify the transaction that you want to heuristically complete. For details about the DISPLAY command, see the Db2 for z/OS Command Reference. The LUWID displayed can be matched to the same luwid at the Transaction Manager Database.

  2. Issue the RECOVER THREAD( <LUWID>) ACTION(ABORT|COMMIT) command, depending on what you want to do.

    For details about the RECOVER THREAD command, see the Db2 for z/OS Command Reference.