In this example, the DD statement defines data set DSN, a multivolume QSAM or BSAM data set for which a checkpoint is to be written twice: once when end-of-volume is reached on TAPE01 and once when end-of-volume is reached on TAPE02.
Joined: 22 Aug 2005 Posts: 413 Location: Colarado, US
As a follow up to Khamuruteen's posting I am adding some more information on Checkpoints.
Checkpoint in DB2
Batch jobs that do not regularly COMMIT their changes to DB2 risk excessive rollback times should they fail. Then, even after DB2 removes all work applied by the failing job, the original program must be rerun in its entirety after all problems have been corrected. Also, batch jobs that do not ever COMMIT database changes often use excessive DB2 resources and run longer than necessary.
Checkpoint/Restart allows you quickly insert COMMITs and CHECKPOINTS into your DB2 batch job streams – in some instances with- out even editing your programs. These COMMITs will often speed up DB2 batch programs and also free up DB2 resources for other production jobs that are running at the same time. After COMMITS are added to your DB2 batch programs, Checkpoint/Restart allows you to quickly restart any abended production job from the point of failure. Checkpoint/Restart will reestablish all positioning and resources within the problem program, including COBOL Working Storage and QSAM and VSAM file access; and then completes any remaining application processing rather than rerunning the whole DB2 program from the beginning.
Checkpoint Restart also provides a powerful Variable COMMIT Frequency Option that enables you to dynamically tune DB2 batch jobs by changing their COMMIT frequency as they run. Database Administrators can now dramatically speed up any jobs that need to be completed as soon as possible prior to the online DB2 applications being restarted.
I have attached the Checkpoint process in a JPG format.