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

It still takes the programmer 45 minutes to arrive and 15 minutes to fix
the problem. This time, however, zero time is spent on database recovery
because all updates are valid. Moreover, the second ABEND, due to that
typo in the programming fix, occurs after only about 6 minutes. Again, po-
tential updates are rolled back. Thus, 22 minutes later, the program is past
the problem. By the time the hero has mailed you a short problem report,
the batch cycle has completed. It is still night, so your tired programmer re-
turns home.

IMS CHECKPOINT/RESTART FUNCTIONS

In the above story, there is a conspicuous usage of a black box labeled,
“a miracle happens here.” In the following paragraphs, I will attempt to de-
mystify this box by reviewing the basic functions that allow checkpoint re-
start to work.

Checkpoint Frequency

Usually, a simple Control Card interface serves to supply this value to
your program. It allows you to control the number of input transactions
that a program processes between commit points. The value should be
easy to change as estimating the frequency is not an exact science. For ex-
ample, 50,000 is too high if your program only processes an average of
40,000 transactions each run. On the other hand, 1 is too small.

Talk to your DBA about checkpoint frequency. As a
rule of thumb, I suggest a minimum of 10 checkpoints per run and/or an av-
erage elapse time between checkpoints of less than 15 minutes.

Recommendation:

Checkpoint Call

This is where your program commits all IMS database, DB2 table and se-
quential file (GSAM) updates. All locks held by your DBMS are released. All
data is written to disk or tape. Save areas are copied to the log. Conversely,
in the case of a program ABEND, a roll back call should be performed to
undo all updates, release all locks and make sure that no data is written
to disk.

At the end of the 'unit of work' for each input transaction, your program
should update a transaction counter and compare the current value to the
checkpoint frequency number. Upon reaching the checkpoint frequency,
your program may make a checkpoint call and reset the transaction
counter to zero.

Do not take a checkpoint, unless your program can re-
start from there. For example, if your input transactions are driven by an
SQL FETCH then make sure that your program has just crossed a break

Recommendation: