IMS Base (full DB recovery)
With full database recovery, the updates in the archived logs are applied to the clean or concurrent image copies through to the end of the last good log data set available at the remote site. It is unnecessary to create an RP for full database recovery as the updates are applied to the database data sets, including the uncommitted updates. IMS is then emergency-restarted to allow dynamic back-out to back out the uncommitted updates. If emergency restart fails, it is also possible to run batch back-out to back out the uncommitted updates.
It must be noted that full database recovery will not work in a data-sharing environment because the archived logs do not end at the same timestamp on the one or more data-sharing systems. This means that when change accumulation is run, there could be spaces between the logs where updates could exist. These spaces are called spill records, and the Change Accum indicates this by showing COMPLETE=NO for the resulting CA data set. When a CA data set has this indicated, it cannot be used for recovery.
Each time a log data set is archived, the RECON data set is backed up, and the log and backup RECON are transmitted to the remote site. The full database recovery will use the last good log data set received at the remote site.
At the remote site, the backup copy of the RECON data set must be conditioned before it can be used for recovery. When the backup RECON was created, it showed a primary system that was up and running and healthy. The conditioning will change the RECON data set to reflect that a disaster has occurred and IMS was abnormally terminated.
The first conditioning step is to flag the primary image copies as
invalid. This is only necessary if dual image copies are being created
at the primary site and only the secondary image copy is being
transmitted to the remote site. It is common to use dual image
copies in this way. The command for this is
CHANGE.IC DBD(dbname) DDN(ddname) INVALID.
The second conditioning step before IMS is cold-started is to close and
archive the open log data sets in the RECON data set. The OLDS data
sets are not transmitted to the remote site. However, at the time the
backup RECON was created, it would have showed an active OLDS data
set. To close and archive the data set, an empty OLDS data set must be
allocated, and the active OLDS in the RECON must be flagged for
archiving. The archive utility will not care that the OLDS is empty
and it will archive it appropriately. As a result the PRILOG, PRISLD,
and PRIOLD records in the RECON will change from having all zeros in
the stop times to having valid timestamps. The command to identify the
active OLDS for this is
After the OLDS is allocated, the command to notify the RECON that the
OLDS needs archiving is
SSID(newssid) -STARTIME(start) … RUNTIME(start+1).
The third step is to flag the IMS subsystems as abnormally terminated.
LIST.SUBSYS DBRC command will show which
IMS subsystems were active,
then a series of commands are required to delete each
Listing 3. Commands to show which IMS subsystems active
CHANGE.SUBSYS SSID(ssidname) ABNORMAL CHANGE.SUBSYS SSID(ssidname) STARTRCV
It is important not to delete the IMS subsystem DBRC records so
emergency restart can be done for these IMS systems. Prior to running
the recovery jobs, the database data sets must be deleted and
reallocated as empty data sets. Once this is done, the
GENJCL.RECOV command can be issued to create the DBRC recovery JCL, and the
resulting jobs can be executed. There is no timestamp specified with
GENJCL.RECOV because the recovery is to the end of the log. The last
step is to allocate an empty RDS data set. The RDS contains checkpoint
information, but it was not sent to the remote site. The emergency
restart will work without the RDS data set, but will take longer
because the restart will need to look in the logs to find the correct
checkpoint timestamp. The emergency restart command includes
WA RS to allow the Write-Ahead Data Set (WADS) and RDS data sets to be formatted. Finally,
the IMS subsystems are emergency-restarted, and dynamic back-out removes
any uncommitted updates.
The RECON conditioning steps are shown in Figure 5.
Figure 5. Manually Condition the RECON Data Set (Remote Site Activity)