IN FOCUSIMS Forward Recovery Needs More Than TLOGs: Image Copies, Complete Log Chains, and the Offline Batch Gap
Rocket Enterprise Server 12.0 on UNIX forward-recovers IMS databases by restoring an image copy and applying every required post-backup log. Forward logging is disabled by default, query-only logs still belong to the recovery chain, and offline DLI/DBB updates are not captured. [1] [2] [3] [4]
Read the full briefing
IMS Forward Recovery Needs More Than TLOGs: Image Copies, Complete Log Chains, and the Offline Batch Gap
Scope: Rocket Enterprise Developer / Enterprise Server 12.0 for Eclipse on UNIX, IMS database administration.
IMS forward recovery combines a database image copy with forward recovery logs to restore recent updates. It is not enabled by default; automatic backward recovery is. Rocket recommends enabling both because together they provide the best coverage among the documented IMS recovery alternatives. See IMS Database Recovery.
Preparation has two independent parts. First, every database must have a recoverable backup, including every secondary-index file. The Recovery utility always applies log records to an existing database copy—even when that copy is an empty initialized database—so a backup image is always required. The backup image must not be altered with Rocket utilities before recovery; changing it causes recovery to fail.
Second, forward logging must be enabled for every Enterprise Server region that updates the IMS database. The documented [ES-Environment] settings are:
ES_IMS_ROLLFORWARD=YES
ES_IMS_TLOG_PATH=logFilePathOnce enabled, Enterprise Server logs online updates and updates performed by BMP transactions. It does not create forward recovery logs for databases updated offline by batch programs running in DLI or DBB mode. Rocket recommends backing up each affected database immediately after each such batch job. Preparing for Forward Recovery also requires preservation of every log created after the latest database backup. This includes logs containing only query activity; deleting an apparently update-free log can break the recovery chain.
Recovery can follow either of two documented paths: restore databases first with Image Restore and then apply logs, or let the Recovery utility copy the specified image backups into the current location before applying logs. After any Recovery utility run, create a new image copy of the recovered databases. The process is summarized in IMS Database Forward Recovery.
The utility adds further operational constraints. All target databases must be stopped. Log files must be unlocked, which requires stopping the server that created them. A recovery job can process up to 200 databases, but a database with a much older timestamp should be recovered separately because otherwise the utility may process many unnecessary logs. The core JCL invocation names the server that created the logs:
//RECOVER EXEC PGM=MFDBUJCL,PARM='RECOVER,SERVER=IMSBANK'By default, failure to recover one database does not stop recovery of others whose log chains are complete. Placing ABEND as the first statement after the SYSIN card changes this to fail on the first error; if an error occurs in that mode, no databases are recovered. These behaviors are documented in Recovery Utility.
Takeaway: IMS forward recovery succeeds only when an untouched image copy, every required post-backup log, and a logged update path all exist; offline DLI/DBB work requires a new backup because it creates no forward recovery log.