Running the CIND in-doubt tool

  1. Change the transaction class of the transactions you want to go in-doubt to DFHTCIND. (You can do this using CEMT or CEDA.)
  2. Type CIND ON. This activates the tool and enables a task-related user exit for task start. You should get the following message:
    DFHIN1001 date time applid termid userid.
    The in-doubt tool is now active for
    DFHTCIND tranclass transactions.

    For every transaction that is started, the task-related user exit inquires whether it is in transaction class DFHTCIND. If it is, the task-related user exit issues a call to the CICS® recovery manager to add a link to CIND, acting as a CICS coordinator system called DFHINDSP.

  3. Run your transactions. If the transactions update recoverable resources and the TRANSACTION resource definition specifies the INDOUBT attribute WAIT(YES), they fail in-doubt. The transaction abends with abend code ASP1, and the UOW is shunted. You can use the CEMT INQUIRE UOW SHUNTED command to display the shunted UOWs.

    A transaction that updates non-recoverable resources, or that issues only READ requests abends with abend code ASPR. However, the UOW is not shunted, because it is read-only, so no syncpoint resynchronization is required with remote coordinator DFHINDSP.

  4. Type CIND OFF. This disables the task-related user exit and stops any further invocations of your transactions going in-doubt. You should get the following message:
    DFHIN1004 date time applid termid userid.
    The in-doubt tool is no longer active for
    DFHTCIND tranclass transactions.
  5. Type CIND RESYNC COMMIT or CIND RESYNC BACKOUT. This simulates a coordinator CICS system reconnecting to your CICS system. In this case, the coordinator is DFHINDSP. You should get the following message:
    DFHIN1007 date time applid termid userid.
    Initiation of resynchronization for units of work
    awaiting coordinator DFHINDSP is now complete.
    The CICS recovery manager domain unshunts all UOWs that were previously shunted because of the tool. The commit or backout specifies what happened in the dummy coordinator DFHINDSP, and hence what the CICS recovery manager domain instructs its subordinates to do when the unshunt takes place.

    For each UOW unshunted, message DFHIN1012 is sent to CSMT detailing the UOW status as defined by coordinator DFHINDSP, and the UOW status held by the CICS recovery manager. Both states should be the same.

    You can use the CIND RESYNC COMMIT command or the CIND RESYNC BACKOUT command to simulate what happens when UOWs are not synchronized. For example, a transaction may be run with CIND activated and with a TRANSACTION resource definition that specifies the INDOUBT attributes WAIT(NO) and WAITACTION(COMMIT). In this case, the UOW is not shunted but is forced to commit. The CICS recovery manager domain keeps a record of the UOW in order to resynchronize with the coordinator. CEMT shows the UOW in committed status waiting for the return of the coordinator. If a CIND RESYNC BACKOUT command is issued at this point, the DFHIN1012 message output to CSMT shows the UOW to be out of sync, as does message DFHRM0111 output by CICS recovery manager domain.

Inquiring on the status of CIND

Type CIND INQUIRE This returns the current status of CIND with one of the following messages:

DFHIN1003 date time applid.  The in-doubt tool
is active for DFHTCIND tranclass transactions.

DFHIN1006 date time applid.  The in-doubt tool is
not active.

Running the in-doubt tool using an EXEC CICS LINK command

Instead of running the in-doubt tool using a terminal and the CIND transaction, you can use the EXEC CICS LINK command to link to the in-doubt tool from an application passing a commarea; for example:

EXEC CICS LINK PROGRAM('DFHINDT') COMMAREA(COMM)

where COMM is a data-area that contains the commands to pass to DFHINDT. COMM should contain one of:

' ON '
' OFF '
' RESYNC COMMIT '
' RESYNC BACKOUT '

Setting a single transaction in-doubt

If you want a single transaction to go in-doubt regardless of its transaction class, an application can link to program DFHINDAP. (No commarea is required in this case.) This causes that single transaction to go in-doubt without the need to type CIND ON. This single transaction can be resynchronized by typing CIND RESYNC COMMIT, and so on, as described in Running the CIND in-doubt tool. DFHINDAP works by enabling the in-doubt task-related user exit if necessary and then issuing an API call to the in-doubt task-related user exit to add the dummy coordinator. This has the advantage of allowing a test application to decide it wants to force in-doubt dynamically, after it has started. Hence a UOW, other than the first one in the transaction can be forced in-doubt.

Related tasks
Using CICS supplied transactions
CIND--in-doubt testing tool
CIND Messages
[[ Contents Previous Page | Next Page Index ]]