Planning recovery procedures
Recovery in a data-sharing environment is similar to standard IMS recovery.
Both standard IMS recovery and recovery in a data-sharing environment involves these primary tasks:
- Setting up the mechanisms of recovery (logging, taking checkpoints, keeping records)
- Setting up the operational procedures to be followed in the event of situations that require recovery
The logging and checkpoint mechanisms of online IMS systems in a nonsharing environment are also active in a data-sharing environment. These include:
- System log data sets and the use of the WADS and restart data sets
- Application program, system, and message-queue checkpoints
- Making image copies of databases
The primary difference between nonsharing and data-sharing environments is in their degree of reliance on DBRC. DBRC helps control the data-sharing environment; it does not merely keep records.
As in a single IMS system, a failure in a data-sharing environment might require offline (utility-type) recovery as well as restart. After a failure in a data-sharing environment, however, you must consider and perform recovery actions not only in the failing system, but also in other sharing systems. In addition, each IRLM, DBRC, and coupling facility structure in the environment introduces another potential point of failure and another component that you might need to include in a recovery and restart procedure.
Recovery for the message queue data sets, (in a nonshared-queues environment) log data sets, and system data sets are no different in a data-sharing environment:
- To recover the log, use the Log Recovery utility (DFSULTR0).
- To recover the message queue data set, request at IMS restart that IMS rebuild the queues. You need to supply the system log data sets since the last system checkpoint that recorded the queue contents (SNAPQ, DUMPQ, or PURGE).
- To recover a system data set other than the message queue data set, update the latest image copy. You must recover the RECON data set for data sharing to continue.