This section discusses the impact of failures of different components of a CICS-DBCTL environment and of transaction and thread failures.
If CICS® fails, DBCTL retains locks on database records updated by in-doubt UOWs. These records remain unavailable until in-doubts are resolved. CICS records information about the disposition of UOWs on its log. A CICS warm start or emergency restart reconstructs information describing UOWs that may be in-doubt. When CICS reconnects to DBCTL, DBCTL returns a list of any in-doubt UOWs. CICS notifies DBCTL of the resolution of all in-doubts, so DBCTL can commit or backout as appropriate.
If CICS fails, or if you need to cause an immediate shutdown, CICS attempts to disconnect from DBCTL. At this time, CICS gives the requests in progress time to complete before shutdown occurs. The time is specified in the DRA startup table parameter, TIMEOUT. (For information on this parameter, see Defining the IMS DRA startup parameter table.) If TIMEOUT is exceeded and CICS terminates while threads are still active in DBCTL, a U113 abend of DBCTL will occur. If this happens, you will have to restart DBCTL (IMS™).
Choosing a value for TIMEOUT involves a trade-off between the length of restart process, which may be delayed if the value you specify is too high, and the risk of causing U113 abends, which may increase if you specify to low a value. One possible solution is to specify a TIMEOUT value that is about equal to the average length of time between BMP checkpoints. If a BMP checkpoint has been taken, there is less likelihood that CICS resources are waiting. This lessens the likelihood of U113 abends without lengthening the restart process too much.
If you want an abnormal termination of CICS, and CICS does not respond to an immediate shutdown, use an MVS™ CANCEL command. This command, and CICS abends with different causes, should not result in an IMS U113 abend because DBCTL "traps" the CANCEL and an MVS system abend code of 08E is issued instead. Changing the effect of an MVS CANCEL from a U113 abend to an MVS system abend of 08E makes the effects of a CANCEL more like the effects of a CICS immediate shutdown, as described above. If you have been obliged to cancel CICS in this way, do not start CICS with the START=INITIAL system initialization parameter unless absolutely necessary, especially if there is a possibility of in-doubt units of work for DBCTL, because CICS will lose its record of the in-doubt units of work. (Unlike CICS/ESA 4.1 and other releases earlier than CICS TS, a cold start of CICS does not lose the record of in-doubt units of work. This allows in-doubt units of work to be resolved automatically on reconnection of CICS and DBCTL. The START=INITIAL system initialization parameter causes CICS to lose its in-doubt units of work. See Resolving in-doubt CICS DBCTL units of work manually.)
For further information on the effects of a CICS failure in a DBCTL environment, see the section on CCTL termination in the appropriate IMS Customization Guide: Database manual.
A termination of DBCTL should not cause CICS to terminate, it simply leaves CICS without DBCTL services. The DRA is left partially initialized to help reduce the restart time.
If any of the DBCTL address spaces (DBC, DBRC, or DLISAS) fails, all of these address spaces are terminated and you must restart the system using an /ERESTART command.
If you are using the IRLM as your lock manager, and it has failed as well as DBCTL, you must restart it before restarting DBCTL. See IRLM failure.
Normally, you terminate DBCTL with a /CHECKPOINT FREEZE or a /CHECKPOINT PURGE command, but an MVS MODIFY command can be used to force the termination of DBCTL. The STOP option used with the MODIFY command forces termination without a dump and the DUMP option forces termination with a dump. The DBCTL address space terminates with a U0020 abend. The messages received at the system console are:
If DL/I is processing a request and the thread that is doing the processing abends is active in DL/I or is waiting on a lock, DBCTL abends with a U113 after the following message has been sent to the system console:
DFS613I DBC RCN U113 DUE TO Sxxx Uyyyy DURING DL/I CALL IN CCTL
zzzzzzzz dddd
where:
For example, for a user abend:
DFS613I DBC RCN U113 DUE TO S000 U0474 DURING DL/I CALL IN CCTL
DBDCCICS IMSA
CICS is isolated from such abends because, in DBCTL, each thread TCB has its own extended subtask ABEND exit (ESTAE).
The threads are then terminated and the DRA attempts to reconnect to DBCTL. Any requests made by the subsystem during this period result in a return code of 40, which indicates that no active communications exist with DBCTL, or a return code 28, which indicates that the specified thread does not exist. These return codes are included in messages DFHDB8104, DFHDB8109, DFHDB8111, and DFHDB8130. Guidance on interpreting them is in the DBCTL DRA return codes appendix of the IMS Messages and Codes manual manual.
The DRA attempts to reconnect to DBCTL. After the first failing attempt, you are given the opportunity to reply to message DFS690A. You can reply either WAIT, in which case the DRA continues trying to reconnect, or CANCEL, in which case the DRA stops trying to reconnect. If you reply CANCEL, you must use the CDBC transaction to reconnect DBCTL.
If you reply WAIT, the time interval between each attempt to reconnect is as specified in the DRA startup parameter TIMER (described in Defining the IMS DRA startup parameter table).
If you reply WAIT and later want to prevent further attempts to reconnect, use the CDBC DISCONNECT transaction. (See Deciding whether to use orderly or immediate disconnection.)
When the IRLM fails, DBCTL subsystems using it cannot continue normal operations. DBCTL terminates active programs that are using the IRLM with a U3303 abend and forces any PSB schedule requests to wait until it has been reconnected to the IRLM. You reconnect DBCTL to the IRLM by first restarting the IRLM using an MVS START command, and then issuing an MVS MODIFY RECONNECT command to DBCTL. For guidance on using MVS commands with the IRLM and DBCTL, see the IMS Operator’s Reference manual.
If a transaction fails in DBCTL, the CICS transaction is abended.
If a transaction fails in CICS when a DL/I request it has issued is being processed in DBCTL, the error is passed to the DBCTL thread. When a transaction terminates, the thread allocated to it is released and a record is written to the IMS log. If there is an error, a return code is returned to the application in the usual form:
(Response codes for a DBCTL environment are in Summary of DBCTL abends and return codes.)
Where the transaction has been abended, the thread is also terminated, and all recoverable resources, including DL/I, are backed out. (DL/I backout is assumed on all thread and transaction failures.)
In some cases, other resources may not have been backed out, but DL/I backout has taken place. In these cases, one of the following status codes will be returned: BB, FD, FR, FS. You can also receive the FD status code on a call to a full function database if the PSB for the program (BMP) has a DEDB PCB. See Status codes and backout for actions you should take if this happens.
As described in the CICS Recovery and Restart Guide, DBCTL detects transaction deadlocks, which can occur when two transactions are waiting for the same two resources to become available; that is, both resources are needed by both transactions, as illustrated in Figure 30.
If one resource is a DBCTL database and the other is a CICS resource, the task waiting for the CICS resource is abended after its DTIMOUT period has elapsed, if you have specified one. (See the CICS Resource Definition Guide for help on specifying the DTIMOUT option of the TRANSACTION definition.) In the example shown in Figure 30, transaction A is the one that is abended when DTIMOUT expires. This is because it is waiting in an enqueue until transaction B frees the lock held for CICS resource C. However, CICS resource C cannot be freed because transaction B is waiting for transaction A to free the lock it is holding on DBCTL resource D.
If you did not specify DTIMOUT for the task using the CICS resource, both tasks will remain suspended indefinitely, unless one of them is canceled by the CICS master terminal operator (as described in Purging a transaction that is using DBCTL).
If the resources are both DBCTL databases, DBCTL detects the potential deadlock when the database requests that create the deadlocks are attempted. DBCTL then causes the task with less update activity to be abended. The abend (ADCD) causes all resources to be backed out. If a deadlock is detected when you are using DEDBs, an FD status code is issued instead of an ADCD abend. See Status codes and backout for details.
For DL/I full function databases and DEDBs, if you have specified automatic restart, the task can be restarted at this point. (See CICS Recovery and Restart Guide for help on specifying automatic restart.) However, this can take place only if the transaction abended in the first (or only) UOW, and there has been no terminal input or output since the initial terminal input was read.
If a BMP fails, DBCTL backs out any changes made by that BMP following the latest successful syncpoint. You must restart BMPs, because DBCTL does not restart them automatically.
The JCL used to restart BMPs depends on whether the checkpoint for the BMP is still on an OLDS available to DBCTL. If the BMP’s last checkpoint records are not in the OLDS, they will be in the SLDS, and you must add an IMSLOGR DD statement for the SLDS(s) containing the log records required to the BMP JCL. Guidance on the JCL needed to do this is in the IMS Utilities Reference: Database manual manual.
There is an option to defer changes made to databases by backout of BMPs at emergency restart. If you specify NOBMP on the /ERESTART command, changes made to databases by BMPs are not backed out and all PSBs affected are stopped. Databases that were being updated by BMPs when the failure occurred are also stopped. You must then do batch backout for the databases that are stopped. (Batch backout will also backout the databases that were affected.) Be aware that using NOBMP may mean that the online DBCTL is restarted sooner, but it also delays data availability for the databases that were stopped by the BMP failure.
If an MVS, processor, or power failure occurs, DBRC is unable to mark the subsystem (SSYS) records in the RECON as having terminated abnormally. This means that you cannot use automatic restart. Instead, you must use the /ERESTART command with the OVERRIDE keyword to override the RECON subsystem record. Alternatively, use the DBRC command CHANGE.SUBSYS to mark the subsystem record as abnormally terminated. You will need to do this if you want to run any utilities (such as database recovery or log utilities). This is because these utilities will fail if the subsystem record is still marked as active. For information on doing this, see the IMS Utilities Reference: Database manual manual. Backout of in-flight updates should then occur. You can then restart CICS with an AUTO (emergency) restart. When CICS has reconnected to DBCTL, CICS decides whether any in-doubt UOWs exist, and resolves them in the same way as for other failures.