Introducing checkpoint calls

Checkpoint calls indicate to IMS that the program has reached a commit point. They also establish places in the program from which the program can be restarted. IMS has symbolic checkpoint calls and basic checkpoint calls.

A program might issue only one type of checkpoint call.

• MPPs and IFPs must use basic checkpoint calls.
• BMP, JMP, and batch programs can use either symbolic checkpoint calls or basic checkpoint calls.

Programs that issue symbolic checkpoint calls can specify as many as seven data areas in the program to be checkpointed. When IMS restarts the program, the Restart call restores these areas to the condition they were in when the program issued the symbolic checkpoint call. Because symbolic checkpoint calls do not support z/OS® files, if your program accesses z/OS files, you must supply your own method of establishing checkpoints.

You can use symbolic checkpoint for either Normal Start or Extended Restart (XRST).

For example, typical calls for a Normal start would be as follows:

• XRST (I/O area is blank)
• CHKP (I/O area has checkpoint ID)
• Database Calls (including checkpoints)
• CHKP (final checkpoint)

For example, typical calls for an Extended Restart (XRST) would be as follows:

• XRST (I/O area has checkpoint ID)
• CHKP (I/O area has new checkpoint ID)
• Database Calls (including checkpoints)
• CHKP (final checkpoint)

The restart call, which you must use with symbolic checkpoint calls, provides a way of restarting a program after an abnormal termination. It restores the program's data areas to the way they were when the program issued the symbolic checkpoint call. It also restarts the program from the last checkpoint the program established before terminating abnormally.

All programs can use basic checkpoint calls. Because you cannot use the restart call with the basic checkpoint call, you must provide program restart. Basic checkpoint calls do not support either z/OS or GSAM files. IMS programs cannot use z/OS checkpoint and restart. If you access z/OS files, you must supply your own method of establishing checkpoints and restarting.

In addition to the actions that occur at a commit point, issuing a checkpoint call causes IMS to:

• Inform Db2 for z/OS that the changes your program has made to the database can be made permanent. Db2 for z/OS makes the changes to Db2 for z/OS data permanent, and IMS makes the changes to IMS data permanent.
• Write a log record containing the checkpoint identification given in the call to the system log, but only if the PSB contains a DB PCB. 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 X'18' log records.

  Related Reading: For more information about the DFSERA10 program, see IMS Version 15 System Utilities.

• Send a message containing the checkpoint identification that was given in the call to the system console operator and to the IMS master terminal operator.
• Return the next input message to the program's I/O area, if the program processes input messages. In MPPs and transaction-oriented BMPs, a checkpoint call acts like a call for a new message.