Runtime Considerations › Application Restartability › Taking a Checkpoint at Runtime

Taking a Checkpoint at Runtime

Your application should take its checkpoints with the object of being able to restart after an abend at the highest level dialog.

The highest level dialog should perform the checkpoint or should pass control to a dialog whose purpose is to take the checkpoint. The checkpoint should do the following:

1. Update the input, output, and suspense file record count fields of the checkpoint record.
2. Close all files in order to clear the file buffers; the disposition of each file should be MOD.
3. Perform a database commit. Between checkpoints, you should leave the run unit open by using the NOSAVE parameter in LINK and INVOKE commands, and the NOFINISH parameter in TRANSFER commands. Committing the database at any point other than the checkpoint can jeopardize restartability.
4. Move required variable and status information to the checkpoint record.
5. Increment the checkpoint record identification number.
6. Write the checkpoint record to an output file or a queue file.
7. If the record is being written to an output file, close the file to ensure that the record is physically written.

The first two tasks must be performed by the dialogs that access the files. The dialog performing the checkpoint can link to each of these dialogs, with a flag set that indicates that a checkpoint is being performed. The dialogs can have premap processes that perform special processing when the flag is set. The processing includes incrementing the record count fields of the checkpoint record and closing the files.

Considerations

The following considerations apply:

• Dialogs to which control will be transferred during a checkpoint must not have as their entry points the mapin operation. If such an entry point is desired, the premap process can issue a READ TRANSACTION command immediately, unless a checkpoint is being performed.
• If a file has been accessed by more than one dialog, you must link to and issue a CLOSE command in each dialog that has accessed the file. If you do not, the file will not be physically closed.
• The record counts for a dialog's input, output, and suspense files are contained in the system-supplied fields $INPUT-COUNT, $OUTPUT-COUNT, and $ERROR-COUNT.
• You update the checkpoint record's record count fields by adding the system-supplied data fields for each dialog to the checkpoint record fields. Each time you issue a CLOSE command in a dialog, the system-supplied data fields for the closed files are reset to zero. At a checkpoint, therefore, the value of a data field equals the number of records read or written only since the last checkpoint.

Your application should have a checkpoint interval, based on a value such as the number of input records read or the time elapsed since the last checkpoint was taken. The checkpoint interval should not be so frequent as to substantially increase processing time, nor be so infrequent as to leave uncommitted more transactions than you would be willing to have to reprocess should the application abend.