Skip to Content

Checkpoint/restart processing in an application program

This section describes a typical processing flow of an application program that uses explicit checkpoint/restart requests. Depending on the method that the program uses to obtain checkpoint/restart services, the program might need to identify function codes and storage areas for structures such as the restart ID area and the checkpoint application request block (ARB).

For information about how processing occurs for a program that uses Automatic Restart and Automatic Checkpoints options, see Reference.

  1. Receive control from AR/CTL or IMS.

  2. Issue a request (XRST or ARCXRST call) for restart processing during initialization. The restart request establishes the checkpoint/restart environment and determines the starting status of the job step. It also identifies one to seven areas in the program’s working storage to save during checkpoint processing and restore during restart processing. AR/CTL performs initialization processing. If the program is restarted from a previous checkpoint, AR/CTL restores the user areas identified by the restart request.

    Warning

    Note

    The program should always issue the restart request before the first checkpoint request, data set open request, DL/I call, or EXEC SQL call.

  3. When AR/CTL returns control, check the contents of the restart ID field:
    • If the restart ID area is blank, perform normal start initialization processing.
    • If the restart ID area is not blank, perform restart initialization processing. This processing might include priming variables and reestablishing position within DB2 tables. IMS automatically reestablishes position in IMS databases. AR/CTL automatically reestablishes position in the sequential, VSAM, and ASAM data sets that use AR/CTL data services.
  4. Issue data set open requests.

  5. Issue the first request (CHKP or ARCCHKP call) for checkpoint processing. Checkpoint pacing does not apply to the first checkpoint; AR/CTL always allows the first checkpoint to complete.

    A minor change in the program statements is required when an FCB is defined with the REREAD=Y option. When this option is set, before the first initial checkpoint is issued, the program has to READ the file to position the first record being processed in the program. Because of the additional READ, the REREAD record is skipped for processing.

    Warning

    Note

    To ensure a correct restart, the program should issue the first checkpoint request before any database or data set processing.

  6. Perform processing to the end of a logical unit of work (UOW).
  7. If applicable, save information needed to reestablish DB2 table position. This action would be necessary if, for example, the application program does not use the DB2 CURSOR WITH HOLD option. This information must be in a user area that is saved during checkpoint processing.
  8. Issue a checkpoint request. If you use checkpoint pacing (bypass), the program can issue a checkpoint request at the end of any logical UOW without concern for operational and performance issues. If checkpoint pacing requirements allow checkpoint processing to occur, AR/CTL notifies the DBMS to commit changes. In preparation for a possible restart, AR/CTL saves the application program’s working storage areas and sequential data set positioning information.
  9. If applicable, check the status code:
    • If the program uses AR/CTL-format checkpoint calls and checkpoint pacing and the Pacing Status Code option (in the pacing class record) has a nonblank value, the program can check the status code field in the checkpoint ARB. If the program does not use checkpoint pacing, the status code is always blank.
    • If the program uses AR/CTL common calls and checkpoint pacing and the Pacing Status Code option (in the pacing class record) has a nonblank value, the program can check the status code field named in the common call. If the program does not use checkpoint pacing, the status code is always blank.
    • If the program uses IMS format checkpoint calls, the program can check the status code field in the checkpoint program communication block (PCB).

    • If the program issues a DB2 commit statement, AR/CTL does not return a status code.

      Warning

      Note

      If AR/CTL detects a problem, it does not return control to the application program. AR/CTL terminates the application program task.

  10. Take action based on the status code, if applicable; for most application programs, no action is necessary:
    • If the status code field indicates that AR/CTL has paced (bypassed) the checkpoint request, the program might need to accommodate the paced checkpoint. For example, if the program does not use the DB2 CURSOR WITH HOLD option, the program must not attempt to reestablish DB2 table position or it must be able to tolerate a DB2 status code indicating that table position was already established.
    • If the status code field is blank, AR/CTL has not paced the checkpoint request. For example, if the program does not use the DB2 CURSOR WITH HOLD option, the program must reestablish database or table position.
  11. Continue processing UOWs, and issue a checkpoint request at the end of each UOW.

  12. Issue the final checkpoint request before termination, to ensure synchronization of multiple DBMSs. BMC Software recommends that you use the force option with the AR/CTL common call or the ARCECHK call to ensure that this checkpoint is not bypassed because of checkpoint pacing.

    During termination, AR/CTL performs the following tasks:

    • AR/CTL closes all ASAM data sets.
    • AR/CTL closes all data sets that use local virtual storage access method (VSAM) access services of AR/CTL. If AR/CTL obtained exclusive use of the data set from CICS, it leaves the data set closed and disabled to CICS.
    • AR/CTL ends the connection with any CICS regions that AR/CTL was using for remote VSAM access services.

 

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

APPLICATION RESTART CONTROL 4.1 (ARCHIVED)