Deciding whether to use orderly or immediate disconnection

Use immediate disconnection only if necessary. For example, you may need to use it if you have already issued an orderly disconnection request which has not taken place, and you need disconnection to take place soon.

Orderly disconnection allows all existing CICS®-DBCTL tasks to complete before CICS is disconnected from DBCTL. Tasks not currently using DBCTL are prevented from issuing further PSB schedule requests. This means that there should not be any indoubt logical units of work (UOWs), and database records are available to other CICS systems connected to that DBCTL.

Immediate disconnection allows only current DL/I requests to DBCTL from this CICS system to complete before CICS is disconnected from DBCTL. Any new DL/I or PSB schedule requests are prevented. This can cause indoubt UOWs for the task involved and leave database records unavailable for other CICS systems connected to that DBCTL until it is reconnected. What happens depends on the type of request issued to DBCTL after the immediate disconnection request:
  • If it is a PSB schedule request, a DHTJ abend (for a command-level program) or a DLINA condition (for a call-level program) is issued.
  • If it is a DL/I request, the UOW is backed out and an ADCA abend is issued.
  • If it is a PREPARE request, the UOW is backed out and an ASP7 abend is issued.

    In all these cases, database records are available to other applications.

  • If it is a COMMIT request, the task remains indoubt and DBCTL records are unavailable. The in-doubts will not be resolved until DBCTL is reconnected to CICS. An abend is issued when the next PSB schedule is received, as described for PSB schedule request.

    See Two-phase commit for DBCTL for information on PREPARE and COMMIT requests.

So, use immediate disconnection only if necessary. For example, you may need to use it if you have already issued an orderly disconnection request which has not taken place, and you need disconnection to take place soon. Orderly disconnection may be delayed by a task that is issuing many DL/I requests, or by a conversational task that is awaiting input from an unattended terminal. If you think the problem is being caused by such a task, you may prefer to identify it using CEMT INQ TASK, and then use CEMT SET TASK(n) PURGE, where n is the task identifier to purge it. You can then use orderly disconnection. However, if the problem is being caused by many tasks or by a single task that you cannot identify, you may have to use immediate disconnection.