CICS® and IMS™ perform similar recovery functions, but there are differences in terminology and in implementation. The following sections give an overview of these similarities and differences:
See CICS Recovery and Restart Guide and the IMS Operations Guide for background information on recovery in CICS and IMS, respectively. If you are familiar with CICS or IMS, but not both, read this overview and then read the manual for the product that you are not familiar with.
CICS has the following types of initialization or restart depending on the system initialization START parameter and on how it was last terminated:
You cannot specify warm start or emergency restart explicitly. Instead, you specify the START=AUTO system initialization parameter, and CICS determines which of these two kinds of start to use. See the CICS Operations and Utilities Guide for information about specifying CICS START options.
If CICS performs a warm start or an emergency restart on a system to which DBCTL was connected and you have specified DBCTLCON=YES as a system initialization parameter or put DFHDBCON in the PLT, so that it is invoked in the second stage of PLTPI processing, the same DRA startup table suffix is automatically used when DBCTL is reconnected. The suffix may change if you have used the INITPARM system initialization parameter (described in Reviewing CICS system initialization parameters) to override the suffix previously used. (For information on methods of connecting to the same, or a different, DBCTL see Connecting DBCTL to CICS automatically.)
CICS initialization begins when the job is submitted and, in almost all cases, continues until completion of the specified type of restart. Error conditions may require operator replies or may cause abnormal termination.
CICS has three types of termination:
The CICS master terminal command to shut down CICS has two options--normal and immediate. A normal shutdown allows transactions to complete before shutting down and saves the system status in the CICS catalog. You can do a warm start after a normal shutdown. An immediate shutdown does not allow transactions to complete. This means it is equivalent to an abnormal termination, and you must restart CICS using emergency restart.
There are special considerations for canceling CICS when it is connected to DBCTL. See the information on causing an abnormal termination of CICS, in CICS failure.
When considering CICS and IMS recovery and restart, consider the capabilities of the extended recovery facility (XRF), which can provide you with automatic takeover of a failing system, based on an emergency restart. For further guidance on XRF, see:
DBCTL has three types of (re)start:
The startup process has two distinct phases: initialization and restart. You can use AUTO restart to do either a warm start or an emergency restart.
With an AUTO restart, (DBCTL startup parameter AUTO=Y), DBCTL decides whether warm start or emergency restart is required, based on the contents of the IMS restart data set (RDS), and proceeds with the restart without your needing to enter any further restart command.
If you need to enter your own restart command (for example, to perform a cold start), use a non-AUTO restart (DBCTL startup parameter AUTO=N). Non-AUTO restart stops after initialization, at which point you must manually enter a restart command.
AUTO=N will have been specified, or defaulted to, for the first startup of DBCTL. For subsequent restarts, use warm start or emergency restart, which means that you will need to change the parameter to AUTO=Y. For guidance on specifying AUTO=Y and AUTO=N, see the IMS System Definition Reference manual manual or IMS Installation Volume 2: System Definition and Tailoring.
During restart processing, the log and RECON are opened.
The sections that follow state how you use these types of (re)start with DBCTL.
With this type of start, DBCTL is brought up in the state it was in at system generation. Do not use cold start after a DBCTL failure. Instead, use an emergency restart. See Emergency restart for more information.
To request a cold start of DBCTL, use the /NRESTART command with the CHECKPOINT 0 keyword. Additional keywords with /NRESTART CHECKPOINT 0 enable you to:
Before you do a cold start, you must ensure that the IMS you intend to start does not have a subsystem record in the RECON. This will be the case if it is a new subsystem, if it was shut down normally the last time it was used, or if it was not shut down normally but the appropriate DBRC commands (including DELETE.SUBSYS) and other actions needed to ensure database integrity were performed.
With this type of start, DBCTL is brought up in the environment it was in when it terminated normally using a /CHECKPOINT FREEZE or /CHECKPOINT PURGE command, as described in Stopping DBCTL normally. After a warm start, resources are in the same state they were in at the time the system was shut down.
The difference between the FREEZE and PURGE keywords applies to BMPs. FREEZE stops them after the next checkpoint, or at program completion, whichever is the sooner, and PURGE allows them to complete. See the IMS Operator’s Reference manual for a list giving guidance on the differences between these options.
To request a warm start of DBCTL, use the /NRESTART command without CHECKPOINT 0.
Any in-doubt UOWs are re-created for this type of start. (An in-doubt UOW is a piece of work that is pending during commit processing. If commit processing fails between DBCTL’s response to CICS’s request to prepare for commit and CICS’s decision to execute the commit, recovery processing must resolve the status of any work that is in-doubt.) See Resolving in-doubt CICS DBCTL units of work manually for information on using operator commands to resolve in-doubt UOWs.
You can use the following optional keywords on /NRESTART:
To perform an emergency restart of DBCTL, use the /ERESTART command. With this type of start, DBCTL is restarted in the environment it was in before a DBCTL failure. DL/I in-flight UOWs (that is, those that were still being processed when the failure occurred) are backed out. Committed but unwritten DEDB changes are applied to the database. Units of work that were in-doubt are retained and are resolved automatically when CICS and DBCTL are reconnected. For further guidance on how this is done, see the IMS Operations Guide. If the UOWs fail to be resolved automatically, you can use DBCTL operator commands to do so, as described in Resolving in-doubt CICS DBCTL units of work manually.
If a failure in emergency restart prevents backout being completed, instead of using a COLD start, you can reattempt the emergency restart using the COLDBASE keyword on the emergency restart command. Full function DL/I databases and DEDB areas that have in-doubt data or that need backout or recovery are identified and stopped. Database backout and committed DEDB updates are not done. You must then use the appropriate IMS utilities to backout or forward recover these databases. (See the IMS Utilities Reference: Database manual manual for guidance on using the utilities.)
You can also specify whether the restart or write ahead data sets should be formatted as part of the restart process. Format the RDS and the WADS if there has been a data set I/O error or if you need to reallocate a data set or change its size.
This section discusses system-level keypoint and checkpoint information. Both CICS and IMS also have task or program (thread) level synchronization information.
CICS keypoints and IMS checkpoints both contain system status information that is modified during online operation. The concepts are basically the same, but they are implemented differently.
A CICS warm start uses a warm keypoint that was written to the CICS catalog by the previous normal CICS shutdown.
A CICS emergency restart reads the CICS system log backwards until it has located an activity keypoint. The keypoint contains a record of incomplete UOW chains which CICS reads directly. These chains can reside on the primary and secondary system logs.
An IMS warm start reads the checkpoint ID table on the RDS to find the shutdown checkpoint on the log. The RDS is a data set that IMS uses to record system checkpoint ID information during the logging process. IMS finds the information it needs and uses it automatically. If the RDS is not available at restart, you can obtain the checkpoint information needed from the log, but this may lengthen the restart process. Generally, you do not need to know the content of the RDS. However, if you are faced with a particularly complex recovery problem, you may need to examine the RDS. You can find guidance on its contents in the IMS Operations Guide.
An IMS emergency restart reads the checkpoint ID table on the RDS and selects the checkpoint that precedes the last synchronization point of each program that was active at the time of the failure. It then reads the IMS log forward from the selected checkpoint.
To take a simple checkpoint of DBCTL, use the /CHECKPOINT command.
The meaning of the term dynamic backout differs slightly between CICS and IMS.
In CICS, dynamic backout means backout as a result of a transaction (or application program) failure. The term transaction backout is used for backout done during CICS emergency restart.
In IMS, dynamic backout means backout as a result of a program failure. In a DBCTL environment, program failures include CICS transaction abends and BMP failures. The IMS /ERESTART command also performs emergency restart backout. IMS provides a batch backout utility, DFSBBO00, which you can use if dynamic backout or emergency restart fails. See the IMS Operations Guide for guidance on when to run this utility, and IMS Utilities Reference: Database manual manual for guidance on how to run it.
Because IMS does the backing out of database updates in a DBCTL environment, we concentrate on IMS backout in this section.
For IMS full function databases, database changes are placed in the log buffers and the database buffers as they are made. Depending on system activity, they may be written before they are committed and so, after a program failure or an IMS system failure, databases may require backout. The IMS log data sets (OLDS) are used for dynamic backout. (See IMS online log data set (OLDS) for more information.) Additionally, if dynamic backout or /ERESTART backout fails, for a database, that database is stopped. The backout is automatically reattempted when the database is restarted.
For DEDBs, no changes are placed in the log buffers until syncpoint processing begins, and no changes are written to the database until a commit has been received. This means that they do not need backout if there is a failure during phase 1 of the syncpoint process. The system can undo the changes by releasing the database buffers that have been modified but not yet written.
The IMS log is a record of activities and database changes. Among the log records written to the IMS log are those that record both phases of the commit for each unit of work. These log records contain the information necessary for database recovery and system restart. The IMS Diagnosis Guide and Reference manual manual contains, for guidance, a list of the types of log records and tells you how to obtain a listing of these DSECTs. The IMS Utilities Reference: Database manual manual gives guidance on using the file select and formatting print utility, DFSERA10, to print the IMS log records.
Database recovery control (DBRC) assists you in controlling DBCTL logs, and in managing recovery of databases. With DBCTL, you must use DBRC to control your logs, and you may optionally use it to control batch logs and database recovery. DBCTL requires DBRC to be at SHARECTL level; if it is not, DBCTL will not start.
You may optionally use DBRC to control the data sharing environment by allowing (or preventing) access to databases by various subsystems sharing those databases.
If you use DBRC to control database recovery, you must register your databases with DBRC, so that it can record the relevant information in the RECON, and then use that information to control the recovery of your databases. See the IMS Operations Guide for general guidance on registering databases. You can register your databases using either of the following:
To recover a database that is registered with DBRC, use the /RMGENJCL.RECOV command. DBRC recovers the database using a combination of available input; for example, image copy data set, change accumulation data sets, log data sets, and archived log data sets.
DBRC automatically records information in dual recovery control (RECON) data sets. Both data sets contain identical information, and so are usually referred to as one--the RECON. The information from the RECON is needed during warm and emergency restarts. DBRC selects the correct data sets to be used by a recovery utility when you enter a GENJCL command. For a restart, the RECON shows which data set--the OLDS or the SLDS--contains the most recent log data for each database data set (DBDS) you have registered with DBRC. For the OLDS, the RECON shows whether the OLDS has been closed and whether it has been archived. The RECON contains timestamp information for each log data set and volume. IMS uses this information to determine which data set and volume contain the checkpoint information needed to restart DBCTL.