Suppose, a batch program that basically reads an input file and posts the updates/inserts/deletes to DB2 tables in the database was abended before the end of the job because of some reasons; Is it possible to tell - How many input records were processed? Were any of the updates committed to the database or can the job be started from the beginning?
Assume that COMMIT logic was not coded for large batch jobs that process millions of records. If an ABEND occurs all database updates will be rolled back and the job can be resubmitted from the beginning. If an ABEND occurs near the end of the process, the rollback of all the updates is performed. Also, DB2 will maintain a large number of locks for a long period of time, reducing concurrency in the system. In fact, the program may ABEND if it tries to acquire more than the installation-defined maximum number of locks.Program without COMMIT logic causes excessive locking.
To avoid the above difficulties COMMIT-RESTART LOGIC is recommended for all the batch programs performing updates/inserts/deletes. This involves setting up a batch-restart control table to store the last input record processed and other control information. The restart control table can also be used as an instrumentation table to control the execution, commit frequency, locking protocol and termination of batch jobs.
Assume that COMMIT logic was not coded for large batch jobs that process millions of records. If an ABEND occurs all database updates will be rolled back and the job can be resubmitted from the beginning. If an ABEND occurs near the end of the process, the rollback of all the updates is performed. Also, DB2 will maintain a large number of locks for a long period of time, reducing concurrency in the system. In fact, the program may ABEND if it tries to acquire more than the installation-defined maximum number of locks.Program without COMMIT logic causes excessive locking.
To avoid the above difficulties COMMIT-RESTART LOGIC is recommended for all the batch programs performing updates/inserts/deletes. This involves setting up a batch-restart control table to store the last input record processed and other control information. The restart control table can also be used as an instrumentation table to control the execution, commit frequency, locking protocol and termination of batch jobs.
Please provide more info like how to code, where to code...etc :)
ReplyDeleteWill be having a series of posts on RESTART and COMMIT logic in next few days.
ReplyDelete