Taking checkpoints in batch and BMP programs

You can take checkpoints in batch and BMP programs. Checkpoints are important for recovery and for integrity.

Taking checkpoints in batch and BMP programs is important for two reasons:

In addition to providing places from which to restart your program and committing database changes, issuing checkpoint calls in a BMP program or in a program participating in IMS data sharing releases database segments for use by other programs.

When a batch or BMP program issues a checkpoint request, IMS writes a record containing a checkpoint ID to the IMS system log.

When your application program reaches a point during its execution where you want to make sure that all changes made to that point have been physically entered in the database, issue a checkpoint request. If some condition causes your program to fail before its execution is complete, the database must be restored to its original state. The changes made to the database must be backed out so that the database is not left in a partially updated condition for access by other application programs.

If your program runs a long time, you can reduce the number of changes that must be backed out by taking checkpoints in your program. Then, if your program terminates abnormally, only the database updates that occurred after the checkpoint must be backed out. You can also restart the program from the point at which you issued the checkpoint request, instead of having to restart it from the beginning.

Issuing a checkpoint call cancels your position in the database.

Issue a checkpoint call just before issuing a Get Unique call, which reestablishes your position in the database record after the checkpoint is taken.

Types of checkpoints

The two types of checkpoint calls are basic and symbolic. Both types commit your program's changes to the database and establish places from which your program can be restarted:

Batch and BMP programs can issue basic checkpoint calls using the CHKP call. When you use basic checkpoint calls, you must provide the code for restarting the program after an abnormal termination.

Batch and BMP programs can also issue symbolic checkpoint calls. You can issue a symbolic checkpoint call by using the CHKP call. Like the basic checkpoint call, the symbolic checkpoint call commits changes to the database and establishes places from which the program can be restarted. In addition, the symbolic checkpoint call:

  • Works with the Extended Restart call to simplify program restart and recovery.
  • Lets you specify as many as seven data areas in the program to be checkpointed. When you restart the program, the restart call restores these areas to the way they were when the program terminated abnormally.

Specifying a checkpoint ID

Each checkpoint call your program issues must have an identification, or ID. Checkpoint IDs must be 8 bytes in length and contain printable EBCDIC characters.

When you want to restart your program, you can supply the ID of the checkpoint from which you want the program to be started. This ID is important because when your program is restarted, IMS searches for checkpoint information with an ID matching the one you have supplied. The first matching ID that IMS finds becomes the restart point for your program. This means that checkpoint IDs must be unique both within each application program and among application programs. If checkpoint IDs are not unique, you cannot be sure that IMS will restart your program from the checkpoint you specified.

One way to make sure that checkpoint IDs are unique within and among programs is to construct IDs in the following order:

  • Three bytes of information that uniquely identifies your program.
  • Five bytes of information that serves as the ID within the program, for example, a value that is increased by 1 for each checkpoint command or call, or a portion of the system time obtained at program start by issuing the TIME macro.

Specifying checkpoint frequency

To determine the frequency of checkpoint requests, you must consider the type of program and its performance characteristics.

In batch programs

When deciding how often to issue checkpoint requests in a batch program, you should consider the time required to back out and reprocess the program after a failure. For example, if you anticipate that the processing your program performs will take a long time to back out, you should establish checkpoints more frequently.

If you might back out of the entire program, issue the checkpoint request at the very beginning of the program. IMS backs out the database updates to the checkpoint you specify. If the database is updated after the beginning of the program and before the first checkpoint, IMS is not able to back out these database updates.

In a data-sharing environment, also consider the impact of sharing resources with other programs on your online system. You should issue checkpoint calls more frequently in a batch program that shares data with online programs, to minimize resource contention.

It is a good idea to design all batch programs with checkpoint and restart in mind. Although the checkpoint support may not be needed initially, it is easier to incorporate checkpoint calls initially than to try to fit them in later. If the checkpoint calls are incorporated, it is easier to convert batch programs to BMP programs or to batch programs that use data sharing.

In BMP programs

When deciding how often to issue checkpoint requests in a BMP program, consider the performance of your CICS® online system. Because these programs share resources with CICS online transactions, issue checkpoint requests to release segments so CICS online programs need not wait to acquire them.

Printing checkpoint log records

You can print checkpoint log records by using the IMS File Select and Formatting Print Program (DFSERA10). With this utility, you can select and print log records based on their type, the data they contain, or their sequential positions in the data set. Checkpoint records are type 18 log records. IMS Version 15.2 System Utilities describes this program.