Checkpoint/restart request considerations

Keep the following information in mind when you use checkpoint/restart requests:

  • If an application program uses remote VSAM access services (VSAM file sharing), the frequency of checkpoints issued can affect performance of CICS systems that own shared VSAM data sets. When an application program updates a record in the CICS environment, CICS locks the record or control interval (CI) until the program commits the changes by issuing a checkpoint call. As the interval between program checkpoints grows longer, more locks are held and, potentially, performance is degraded.
  • If the application program is using the DB2 option CURSOR WITH HOLD, it does not need to reposition the DB2 tables after a checkpoint request; however, DB2 does not release locks until the application program issues a CLOSE CURSOR or terminates.
  • For COBOL programs, only data in the working storage section or linkage section can be saved during checkpoint processing and restored during restart. The data areas in the FILE SECTION are not restored; if data from a record previously read or written is needed after restart, move the data to the working storage section.
  • The application program should save the same areas in the checkpoint requests as the areas restored in the restart request. Saving different areas is not recommended; an abend results if the lengths of the two areas are different. If the application program saves different areas, the program must ensure that it tells AR/CTL to restore these fields during restart by matching them on the restart request. If AR/CTL cannot complete the checkpoint, it issues an application program abend. Saving areas of different lengths in different checkpoint requests is not a valid coding practice.
  • Although AR/CTL does not have any restrictions on the size of working storage the program can save during checkpoint processing, be aware that larger storage areas are more costly (in performance and resources) to write than smaller storage areas. If the program has large storage areas to save, you might want to reduce the frequency of checkpoints through the use of checkpoint pacing.
  • To implement checkpoint/restart services in programs that have subprograms, you can use the Subprogram Virtual Storage (ARCSPVS) application program interface (API) to define the virtual storage areas that you want AR/CTL to save during checkpoint processing and to restore automatically during initialization processing or manually on demand. You can define these areas in addition to the user areas that you can define with checkpoint (CHKP) and restart (XRST) calls.
  • The program should issue a checkpoint call as the final call. If the program is using checkpoint pacing, the checkpoint call should use the force option to ensure that the checkpoint is not bypassed.
  • If the application program uses AR/CTL checkpoint/restart services, it must issue the restart request before opening a data set that uses AR/CTL data services. It must also issue the same type of open request (input, output, or I/O) at restart time as the last type of open request it issued before the abend occurred.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*