Offloading Disk Journal Files

What Happens When You Offload a Disk Journal File
The ARCHIVE JOURNAL utility statement offloads the contents of a disk journal file to an archive journal file. It also rebuilds the disk journal file, condensing all before images for each active transaction into new journal blocks at the beginning of the file. This process creates a journal file that contains only those before images that are needed if an active transaction aborts or requests rollback.
Creating Multiple Archive Files
CA IDMS/DB will offload the disk journal files to multiple archive files if more than one is defined in the DMCL used when executing the ARCHIVE JOURNAL utility statement. By creating multiple archive files, you increase the likelihood that a readable archive file is available in the event it is needed for manual recovery. If an I/O error is encountered while writing to one of the archive files, a warning message is issued and offloading continues without further writes to the damaged file. If all archive files incur write errors, execution is aborted.
When to Offload
You normally offload disk journal files only when:
  • CA IDMS/DB switches to another disk journal file
  • The DC/UCF system is shut down and the database is backed up
The procedure for each scenario is provided next followed by a description of how to restart an offload operation.
When CA IDMS/DB Switches Journal Files
When Switch Occurs
CA IDMS/DB switches to another disk journal file when:
  • The active disk journal becomes full
  • You issue a DCMT VARY JOURNAL command under the central version
  • An I/O error is detected on the active disk journal file
What Happens When the Switch Occurs
When CA IDMS/DB switches to another disk journal file, it writes a message to the operator, indicating that a swap has occurred and that the previously active journal file needs offloading. The operator should respond to this message by offloading the full file.
Eliminating Operator Intervention
You can eliminate the need for operator intervention by using a write-to-operator exit routine that intercepts and reviews the message to the operator and responds by automatically submitting a job to offload the full journal file.
For information on the WTOEXIT user exit and sample routines for each operating system, see the
Administrating section
How to Offload the Disk Journal
ARCHIVE JOURNAL Utility Statement
To offload the journal, you execute the ARCHIVE JOURNAL utility statement using the batch command facility. You should use the default option of AUTO so that the oldest non-archived journal file is selected for processing.
If change tracking is in effect for the CV whose journals are being offloaded, you should reference the CV's SYSTRK file in your ARCHIVE JOURNAL execution jcl so that the archive job is sharing the description of the journal files that are currently in use by CV.
For more information on change tracking and how to reference a SYSTRK file, see "Change Tracking" in the
Administrating section
System Failure During Offload
If the operating system fails while an ARCHIVE JOURNAL statement is executing, resubmit the ARCHIVE JOURNAL job using the RESTART parameter and identifying the journal file that was being processed at the time of failure.
Potential Problems While Offloading
You may encounter two types of problems when you offload journal files in an active system:
  1. The offloaded journal file is still full following the offload because it contains before images for uncommitted transactions active at the time of the offload. The ARCHIVE JOURNAL utility statement issues messages indicating how full the disk journal file is after being offloaded. If it is full, it is usually because a long-running batch job is updating the database without issuing intermediate COMMIT statements. If all journal files fill, the system will halt database processing until corrective action is taken. See 19.4.3, “Handling Full Journal Files" for how to recover from this situation.
  2. The remaining disk journal files fill before ARCHIVE JOURNAL completes offloading a single file. When this occurs, CA IDMS/DB temporarily halts further database activity until the offload job is complete.
Prevention For Problem 1
To prevent a full disk journal following an offload, take one or more of the following steps:
  • Ensure that batch update programs issue frequent COMMITs to reduce the number of before images that must be retained on the journal file
  • Allocate larger disk journal files
  • Execute long-running update programs in local mode
Prevention For Problem 2
To prevent future disk journal file overloading, take one or more of the following steps:
  • Allocate larger disk journal files
  • Increase the number of disk journal files
  • Execute long-running update programs in local mode.
Handling Full Journal Files
Long running transactions that do not commit their changes can fill the journals because the ARCHIVE JOURNAL utility is unable to remove the BFOR images for uncommitted transactions. The ARCHIVE JOURNAL utility generates a warning message when the journal file that is being archived remains nearly full after the process completes. The ARCHIVE_JOURNAL_WARNING_PERCENT SYSIDMS parameter dictates the threshold used to trigger the message. If this message appears, it indicates that the journal files are filling and corrective action may be needed.
When the journals are close to being full, the CA IDMS system halts database activity. To recover from this situation, the task that is filling the journals must be canceled.
To assist in this process, the following message is written for each task that is waiting to write to a full journal file:
DC205024 Journal Write waiting on full Journal
The message will be repeated every few seconds until tasks are no longer waiting on a full journal.
To recover from this situation, the task that is filling the journal files must be identified and aborted. To assist in this effort, CA IDMS will display message DC205030 showing details of the task causing the journal swap. This is most likely the task causing excessive journaling activity, although it may not be. To determine if this is the offending task, display detailed transaction information by issuing DCMT DISPLAY TRANSACTION commands or using the transaction detail function of the real time monitor within CA IDMS Performance Monitor.
Look for the transaction that has written the largest number of BFOR journal images. Cancel its associated task by issuing a DCMT VARY ACTIVE TASK command.
When the cancelled task has terminated, issue a DCMT VARY JOURNAL command to force the central version to swap to a new active journal file allowing the full file to be offloaded and condensed by ARCHIVE JOURNAL. It is likely that DCMT VARY JOURNAL will need to be issued more than once, since several journal files may have filled and require offloading.
Once the system swaps back to the first journal file on which tasks waited, processing should continue without the need for further intervention.
After System Shutdown
Offload All Files
After a normal system shutdown, you may offload
non-empty journal files, by executing an ARCHIVE JOURNAL utility statement with the ALL option:
archive journal all;
Usually Done in Conjunction With Backup
Offloading all journal files following a system shutdown is usually performed in conjunction with backing up the database.
For more information on backup, see 21.2, “Backup Procedures".