Checkpoints in IMS programs

Issuing checkpoint calls releases locked resources and establishes a place in the program from which you can restart the program. The decision about whether your program should issue checkpoints (and if so, how often) depends on your program.

Generally, the following types of programs should issue checkpoint calls:
  • Multiple-mode programs
  • Batch-oriented BMPs
  • Nonmessage-driven Fast Path programs. (These programs can use a special Fast Path call, but they can also use symbolic checkpoint calls.)
  • Most batch programs
  • Programs that run in a data sharing environment. (Data sharing makes it possible for online and batch application programs in separate IMS systems, in the same or separate processors, to access databases concurrently. Issuing checkpoint calls frequently in programs that run in a data sharing environment is important, because programs in several IMS systems access the database.)
You do not need to issue checkpoints in the following types of programs:
  • Single-mode programs
  • Database load programs
  • Programs that access the database in read-only mode (defined with the processing option GO during a PSBGEN) and are short enough to restart from the beginning
  • Programs that, by their nature, must have exclusive use of the database
A CHKP call causes IMS to perform the following actions:
  • Inform Db2 that the changes that your program made to the database can become permanent. Db2 makes the changes to Db2 data permanent, and IMS makes the changes to IMS data permanent.
  • Send a message that contains the checkpoint identification that is given in the call to the system console operator and to the IMS master terminal operator (MTO).
  • 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.
  • Sign on to Db2 again.

Programs that issue symbolic checkpoint calls can specify as many as seven data areas in the program that is to be restored at restart. Db2 always recovers to the last checkpoint. You must restart the program from that point.

If you use symbolic checkpoint calls, you can use a restart call (XRST) to restart a program after an abend. This call restores the program's data areas to the way they were when the program terminated abnormally, and it restarts the program from the last checkpoint call that the program issued before terminating abnormally.

Restriction: For BMP programs that process Db2 databases, you can restart the program only from the latest checkpoint and not from any checkpoint, as in IMS.

Checkpoints in MPPs and transaction-oriented BMPs

In single-mode programs, checkpoint calls and message retrieval calls (called get-unique calls) both establish commit points. The checkpoint calls retrieve input messages and take the place of get-unique calls. BMPs that access non-DL/I databases and MPPs can issue both get unique calls and checkpoint calls to establish commit points. However, message-driven BMPs must issue checkpoint calls rather than get-unique calls to establish commit points, because they can restart from a checkpoint only. If a program abends after issuing a get-unique call, IMS backs out the database updates to the most recent commit point, which is the get-unique call.

In multiple-mode BMPs and MPPs, the only commit points are the checkpoint calls that the program issues and normal program termination. If the program abends and it has not issued checkpoint calls, IMS backs out the program's database updates and cancels the messages that it has created since the beginning of the program. If the program has issued checkpoint calls, IMS backs out the program's changes and cancels the output messages it has created since the most recent checkpoint call.

Checkpoints in batch-oriented BMPs

If a batch-oriented BMP does not issue checkpoints frequently enough, IMS can abend that BMP or another application program for one of the following reasons:
  • Other programs cannot get to the data that they need within a specified amount of time.

    If a BMP retrieves and updates many database records between checkpoint calls, it can monopolize large portions of the databases and cause long waits for other programs that need those segments. (The exception to this situation is a BMP with a processing option of GO; IMS does not enqueue segments for programs with this processing option.) Issuing checkpoint calls releases the segments that the BMP has enqueued and makes them available to other programs.

  • Not enough storage is available for the segments that the program has read and updated.

    If IMS is using program isolation enqueuing, the space that is needed to enqueue information about the segments that the program has read and updated must not exceed the amount of storage that is defined for the IMS system. (The amount of storage available is specified during IMS system definition. ) If a BMP enqueues too many segments, the amount of storage that is needed for the enqueued segments can exceed the amount of available storage. In that case, IMS terminates the program abnormally. You then need to increase the program's checkpoint frequency before rerunning the program.

When you issue a DL/I CHKP call from an application program that uses Db2 databases, IMS processes the CHKP call for all DL/I databases, and Db2 commits all the Db2 database resources. No checkpoint information is recorded for Db2 databases in the IMS log or the Db2 log. The application program must record relevant information about Db2 databases for a checkpoint, if necessary. One way to record such information is to put it in a data area that is included in the DL/I CHKP call.

Performance might be slowed by the commit processing that Db2 does during a DL/I CHKP call, because the program needs to re-establish position within a Db2 database. The fastest way to re-establish a position in a Db2 database is to use an index on the target table, with a key that matches one-to-one with every column in the SQL predicate.