Checkpoint pacing intervals

Pacing interval between checkpoints

With checkpoint pacing, a checkpoint can be initiated each time the application program reaches a logical point during processing, typically at a unit of work (UOW) boundary, without concern for operational issues such as checkpoint overhead.

You can use the Pacing Interval between Checkpoints options to control the frequency that AR/CTL allows an initiated checkpoint to result in continued checkpoint processing. This control is external to the program and can be tailored for the requirements of the program, the environment, and the time of day.

To perform checkpoint pacing by a minimum pacing interval, AR/CTL intercepts the checkpoint call issued by (or on behalf of) the application program. AR/CTL then makes the pacing decision—whether to let checkpoint processing continue or to bypass checkpoint processing and return to the program.

Checkpoint processing includes flushing database buffers, freeing resource locks, issuing a DB2 commit (if applicable), writing checkpoint (X'18') log records to the IMS log (if applicable), writing a CICS syncpoint record (if applicable), and writing the checkpoint records to the checkpoint data set. If AR/CTL bypasses the checkpoint, it can return a user-defined status code (blank by default) to the application program, indicating that the checkpoint was bypassed.

To make the pacing decision, AR/CTL compares current values (as of the last checkpoint) of one or more elements from execution to the pacing interval requirements you have defined. Current elements include the elapsed time since the last completed checkpoint, the number of checkpoints initiated, and the counts of various types of calls issued by the application program.

To affect the pacing decision, the value of a current element must be greater than or equal to its defined requirement for the element. You can set an ANY condition or an ALL condition for the defined requirements. If you set an ANY condition, any element that meets or exceeds the defined requirement causes AR/CTL to allow checkpoint processing to continue. If you set an ALL condition, all elements must meet or exceed the defined requirement for AR/CTL to allow checkpoint processing to continue.

Threshold interval without a checkpoint

With checkpoint pacing, you can avoid lockout and performance problems caused when checkpoints are not issued frequently enough for an executing program.

You can use the Threshold Interval without a Checkpoint options to take action (issue a warning or an abend for the program) if no checkpoint is issued within the interval. This control is external to the program and can be tailored for the requirements of the program, the environment, and the time of day.

To perform checkpoint pacing by threshold interval, AR/CTL monitors current values (as of the last checkpoint) of one or more elements from execution and compares those values to the threshold interval requirements you have defined. Current elements include the elapsed time since the last completed checkpoint and the counts of various types of calls issued by the application program.

To affect the pacing decision, the value of a current element must be greater than or equal to its defined requirement for the element. You can set an ANY condition or an ALL condition for the defined requirements. If you set an ANY condition, any element that meets or exceeds the defined requirement causes AR/CTL to take the threshold interval action. If you set an ALL condition, all elements must meet or exceed the defined requirement for AR/CTL to take the threshold interval action.