Invoking a checkpoint causes the creation of one or more of the following checkpoint-related disk files: a checkpoint file, a checkpoint job file, and checkpoint temporary files. The following paragraphs explain what these files are, and the factors that determine whether they are created.
A checkpoint file is always created if the checkpoint is successful. This file stores a complete description of the checkpointed task and is titled according to the following convention:
(<usercode>)CP/<job number>/<checkpoint number> ON <family name>
The usercode in the checkpoint file title is the usercode of the task. The job number is the 5-digit mix number of the job that initiated the task. The checkpoint number is a 3-digit number used to distinguish this checkpoint from any other checkpoints executed by the same task. The family name is taken from the value of the device option in the CHECKPOINT statement.
If the disposition option is set to PURGE, the checkpoint number is always 0 (zero) and each succeeding checkpoint with PURGE set removes the previous checkpoint file. If the disposition option is set to LOCK, the checkpoint number starts at a value of 1 for the first checkpoint, and is incremented by 1 for each succeeding checkpoint that is invoked with LOCK. If a task invokes some checkpoints with LOCK and some with PURGE, then the “locked” checkpoints use ascending checkpoint numbers and the “purged” checkpoints use a checkpoint number of 0.
A checkpoint job file is produced by the first checkpoint in the task that is invoked with LOCK. This checkpoint job file makes it possible to restart the checkpointed task after its original job has terminated. Later checkpoints with LOCK do not produce a job file, nor do any checkpoints invoked with PURGE. The checkpoint job file is titled according to the following convention:
(<usercode>)CP/<job number>/JOBFILE ON <family name>
Checkpoint temporary files store the contents of temporary files in use by the checkpointed task. Checkpoint temporary files are created only in certain circumstances, which are discussed under Planning for File Recovery earlier in this section. These files are titled according to the following convention:
(<usercode>)CP/<job number>/F<file number> ON <family name>
In the checkpoint temporary file title, the file number is a 3-digit file number that starts at 1 and is incremented by 1 for each temporary disk file.
The way the checkpointed task terminates can have an effect on the checkpoint-related files. If the checkpointed task terminates abnormally and the last checkpoint has a disposition of PURGE, the system retitles the checkpoint file to have the next sequential checkpoint number and creates a checkpoint job file if none exists. If the checkpointed task terminates normally and all checkpoints have a disposition of PURGE, then the system removes all checkpoint-related files that were created for the task.
For tasks that invoke a large number of checkpoints with the LOCK disposition, the checkpoint number is incremented up to 999 and then is recycled to 1 (leaving 0 undisturbed). When this happens, the checkpoint files previously numbered 1, 2, and so on are lost as new ones using those numbers are created.
When a task restarts at a checkpoint that was not the last, subsequent checkpoints invoked from the restarted task continue in numerical sequence from the one used for the restart. Old high-numbered checkpoints are thus lost.
If a rerun is initiated and the original job number is in use by another task, then a new job number is assigned to the job. The titles of all checkpoint-related files for the task are changed to reflect the new job number.
