Controlling checkpoint frequency

QUICKSTART does not necessarily issue a checkpoint each time the application program invokes the Checkpoint Routine (i.e. implicitly in Transparent Mode, or explicitly with CALL or INCLUDed code). Rather, the Checkpoint Routine delays the actual execution of a checkpoint until an adequate number of iterations have passed. Invocations of the Checkpoint Routine are assumed to have been well placed within the application program, typically at the end of a Logical Unit of Work.

The CKPTCNTL_FREQ field of the QUICKSTART Checkpoint Control Table controls the number of iterations of the Checkpoint Routine being invoked by the application program before the Checkpoint Routine actually issues a database checkpoint. The valid range is 0001 through 9999. Or, if the first character of CKPTCNTL_FREQ is a 'T', it represents the desired “time interval” in one second increments (wall clock time) between checkpoints.

Assuming that the application program is designed under the guidelines of the Logical Unit of Work approach, and that the application program invokes the Checkpoint Routine at the conclusion of each Logical Unit of Work, this field essentially represents the number of Logical Units of Work which are allowed to pass before a checkpoint is actually issued.

This easily facilitates three different approaches to the checkpoint Frequency issue:

1. Have the application program invoke the Checkpoint Routine at the end of each Logical Unit of Work, and set CKPTCNTL_FREQ to a relatively high value (say, 500), or
2. Have the application program invoke the Checkpoint Routine only at the end of certain Logical Units of Work, spaced at even intervals (say, every hundredth), and set CKPTCNTL_FREQ to a relatively low value (say, 5).
3. Set CKPTCNTL_FREQ to a time interval 'Tnnn', and PERFORM CKPT-RTN after some number of LUW's, depending on the size of the LUW. CKPT-RTN will checkpoint based on wall clock time.

Any of the above approaches are acceptable, and each yields essentially the same result - that an actual checkpoint is issued after some number of Logical Units of Work.

Adjusting the value of the CKPTCNTL_FREQ field of the QUICKSTART Checkpoint Control Table effectively increases or decreases the checkpointing Frequency of an application program. QUICKSTART utilizes CKPTCNTL_FREQ in such a manner that the checkpointing Frequency can be dynamically adjusted—even while the application program is executing.

To modify the value of an existing CKPTCNTL_FREQ field, use the QSMENU CLIST for DB2 applications, or a QUICKSTART-supplied or user-written batch utility program (see Customized-location-of-QUICKSTART-for-MVS-examples-and-include-files).

In lieu of manually creating a QUICKSTART Checkpoint Control Table row/record for each application program, QUICKSTART will automatically generate a Checkpoint Control Table row/record for any given application program as it executes under QUICKSTART for the first time. In Transparent Mode, QUICKSTART initializes the CKPTCNTL_FREQ field of the new Checkpoint Control Table row/record to a site default (See QSMENU, Configuration), or to the value of QSCTRL1 parameter CKPTFREQ. In API Mode, QUICKSTART initializes the CKPTCNTL_FREQ field of the new Checkpoint Control Table row/record to the value of the application program's CKPT-FREQUENCY field located within the program's Working Storage Section. Once the Checkpoint Control Table row/record has been created, QUICKSTART no longer honors the value of the application program's CKPT-FREQUENCY field, as it exists in Working Storage.

To minimize unnecessary checkpointing overhead, QUICKSTART does not normally issue checkpoints more often than once every 10 seconds (this time span may have been adjusted during the QUICKSTART installation process and does not apply when CKPTCNTL_FREQ specifies a time interval by setting the first character =‘T’. See CONFIGURATION in the QSMENU CLIST for the current setting).

This minimum delay period can be overridden by the application program issuing a “Forced checkpoint” request, so indicated by the presence of the value 'F' (“Force”) rather than the value SPACE in the CKPT-REQUEST-TYPE field. Forced checkpointing can be issued:

• When the application program has reached some critical phase of its processing logic,
• When testing the restartability of the application program, to actually force a checkpoint to be issued, in the presence of only a limited volume of test data.