Scenarios for resolving problems with indoubt threads

Indoubt threads can cause a variety of problems, but you can recover from these problems.

The recovery scenarios for indoubt threads are based on a sample environment, which this topic describes. System programmer, operator, and database administrator actions are indicated for the examples as appropriate. In these descriptions, the term administrator refers to the database administrator (DBA) if not otherwise specified.

Configuration
The configuration includes four systems at three geographic locations: Seattle (SEA), San Jose (SJ) and Los Angeles (LA). The system descriptions are as follows.
  • Db2 subsystem at Seattle, Location name = IBMSEADB20001, Network name = IBM®.SEADB21
  • Db2 subsystem at San Jose, Location name = IBMSJ0DB20001, Network name = IBM.SJDB21
  • Db2 subsystem at Los Angeles, Location name = IBMLA0DB20001, Network name = IBM.LADB21
  • IMS subsystem at Seattle, Connection name = SEAIMS01
Applications
The following IMS and TSO applications run at Seattle and access both local and remote data.
  • IMS application, IMSAPP01, at Seattle, accesses local data and remote data by DRDA access at San Jose, which accesses remote data on behalf of Seattle by Db2 private protocol access at Los Angeles.
  • TSO application, TSOAPP01, at Seattle, accesses data by DRDA access at San Jose and at Los Angeles.
Threads
The following threads are described and keyed to Figure 1. Database access threads (DBAT) access data on behalf of a thread (either allied or DBAT) at a remote requester.
  • Allied IMS thread A at Seattle accesses data at San Jose by DRDA access.
    • DBAT at San Jose accesses data for Seattle by DRDA access 1 and requests data at Los Angeles by Db2 private protocol access 2.
    • DBAT at Los Angeles accesses data for San Jose by Db2 private protocol access 2.
  • Allied TSO thread B at Seattle accesses local data and remote data at San Jose and Los Angeles, by DRDA access.
    • DBAT at San Jose accesses data for Seattle by DRDA access 3.
    • DBAT at Los Angeles accesses data for Seattle by DRDA access 4.
Figure 1. Resolution of indoubt threads. Results of issuing DISPLAY THREAD TYPE(ACTIVE) at each Db2 subsystem.
Begin figure description. This figure is a flowchart that depicts threads between four systems that are located at three different locations. End figure description.

The results of issuing the DISPLAY THREAD TYPE(ACTIVE) command to display the status of threads at all Db2 locations are summarized in the boxes of the preceding figure. The logical unit of work IDs (LUWIDs) have been shortened for readability, as follows:

  • LUWID=15 is IBM.SEADB21.15A86A876789.0010.
  • LUWID=16 is IBM.SEADB21.16B57B954427.0003.

For the purposes of procedures that are based on this configuration, assume that both applications have updated data at all Db2 locations. In the following problem scenarios, the error occurs after the coordinator has recorded the commit decision, but before the affected participants have recorded the commit decision. These participants are therefore indoubt.

Read one or more of the scenarios to learn how best to handle problems with indoubt threads in your own environment.