Using BLT (Batch Log Tracker) best practices
Article ID: 50433
Updated On:
Products
Issue/Introduction
What are the current best practices with Batch DBRC when recovery is required?
Why separately track batch logs in a data set?
Resolution
The purpose of DBRC is to insure that databases can be recovered. The required files to recover a database are image copies and logs. When DBRC=YES is specified, DBRC is notified when these files are created.
However, DLI jobs can be executed in the DBRC environment with DBRC=NO and logs may or may not be generated. If they are created, DBRC does not know about them so they would be missed in a DBRC controlled recovery.
The best practice is to always specify DBRC=YES in DLI batch jobs. DBRC will insure that a log is created and recorded. However, there is still the possibility that a DLI batch job is run with DBRC=NO. In this situation, the Batch Log Tracking function will intercept all DLI batch executions and insure that logs are generated and will capture the log information.
It insures that you have the log files needed for recovery.
BLT does not track logs beyond ensuring that Batch Backout has occurred when necessary.
When a job abends, an "execution record" is retained until it is either manually deleted or Batch Backout is successfully run. The existence of the execution record will keep the job from (re)running until the condition is fixed.
This processing is unnecessary when DBRC is used, but helpful when not.
Another feature of BLT that helps "bridge the gap" to get applications under DBRC is that of batch log allocation. BLT can be used to enforce standards for log allocation. For instance, the JCL DD DUMMY allocations can be deallocated and proper logs dynamically allocated. This is often easier to enforce using BLT than finding/changing JCL decks in many instances.
Feedback
