Leveraging Checkpoint Processing - High-Performance Web Databases: Design, Development, and Deployment - page 663

DESIGN CONSIDERATIONS

We covered all the main points. You have added restart and checkpoint
logic to your program and converted the sequential input and two report
files to use GSAM calls. Well, you are not quite done! There is one final de-
sign consideration. Your program's main processing loop has shifted from
inside the program to that of submitting the entire job. That's correct. You
must include the job's JCL in your design and make sure that your check-
point/restart scenario is bullet proof. I recommend that you walk through
the job's JCL and make sure that is restartable. For instance, upon restart,
would your output report file be deleted and reallocated? Thereby, losing
all the data written during processing of the first 350,000 records as per our
previous example. Would generation dataset file indicators need to be
changed? Does the JOB run two separate programs? If so, how would you
restart if the second one abends?

Secondly, I recommend that you actually test the restart logic, as
follows:

1. Perform a sample test run to a successful completion. Then, back up
the output report files.
2. Refresh the test environment and begin the sample test run. This
time force an ABEND by canceling the program.

— you may need to reduce the Checkpoint frequency to an ar-
bitrary low value such as 2 in order to produce sufficient check-
points.
3. Restart your program and let it run to a successful completion.
Check to see if the Checkpoints correctly picked up where they fin-
ished. Compare the output files to those of the first sample run; they
should be exactly the same!

N.B.

Do's and Don'ts

• Test an ABEND — most programmers assume that their program
works. Make sure that they have forced an ABEND and done a success-
ful restart. You would be surprised at the number of typos that can be
caught.
• Remember to test restarting the JOB from the top; 3:00 a.m. is not the
time to expect people to restructure JCL to restart in the proper
sequence.
• Set a single consistent Restart policy. I know of a case where two
checkpoint/restart programs run in a single JOB. The second program
failed. Upon restart, the first program ran successfully again. (Alas, it
was not the payroll system.)