When to use checkpoint calls

Issuing Checkpoint calls is most important in programs that do not have built-in commit points.

The decision about whether your program should issue checkpoints, and if so, how often, depends on your program. Generally, these programs should issue checkpoint calls:

You do not need to issue checkpoint calls in:

Checkpoints in MPPs and transaction-oriented BMPs

The mode type of the program is specified on the MODE keyword of the TRANSACT macro during IMS system generation. The modes are single and multiple.

  • In single-mode programs

    In single mode programs (MODE=SNGL was specified on the TRANSACT macro during IMS system definition), a Get Unique to the message queue causes an implicit commit to be performed.

  • In multiple-mode programs

    In multiple-mode BMPs and MPPs, the only commit points are those that result from the checkpoint calls that the program issues and from normal program termination. If the program terminates abnormally and it has not issued checkpoint calls, IMS backs out the program's database updates and cancels the messages it 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.

    Consider the following when issuing checkpoint calls in multiple-mode programs:

    • How long it would take to back out and recover that unit of processing. The program should issue checkpoints frequently enough to make the program easy to back out and recover.
    • How you want the output messages grouped. checkpoint calls establish how a multiple-mode program's output messages are grouped. Programs should issue checkpoint calls frequently enough to avoid building up too many output messages.

    Depending on the database organization, issuing a checkpoint call might reset your position in the database.

    Related Reading: For more information about losing your position when a checkpoint is issued, see IMS Version 15 Database Administration.

Checkpoints in batch-oriented BMPs

Issuing checkpoint calls in a batch-oriented BMP is important for several reasons:

  • In addition to committing changes to the database and establishing places from which the program can be restarted, checkpoint calls release resources that IMS has locked for the program.
  • A batch-oriented BMP that uses DEDBs or MSDBs might terminate with abend U1008 if a SYNC or CHKP call is not issued before the application program terminates.
  • If a batch-oriented BMP does not issue checkpoints frequently enough, it can be abnormally terminated, or it can cause another application program to be abnormally terminated by IMS for any of these reasons:
    • If a BMP retrieves and updates many database records between checkpoint calls, it can tie up large portions of the databases and cause long waits for other programs needing those segments.

      Exception: For a BMP with a processing option of GO or exclusive, IMS does not lock segments for programs. Issuing checkpoint calls releases the segments that the BMP has locked and makes them available to other programs.

    • The space needed to maintain lock information about the segments that the program has read and updated exceeds what has been defined for the IMS system. If a BMP locks too many segments, the amount of storage needed for the locked segments can exceed the amount of available storage. If this happens, IMS terminates the program abnormally. You must increase the program's checkpoint frequency before rerunning the program. The available storage is specified during IMS system definition.

      Related Reading: For more information on specifying storage, see IMS Version 15 System Definition.

      You can limit the number of locks for the BMP by using the LOCKMAX=n parameter on the PSBGEN statement. For example, a specification of LOCKMAX=5 means the application cannot obtain more than 5000 locks at any time. The value of n must be between 0 and 255. When a maximum lock limit does not exist, 0 is the default. If the BMP tries to acquire more than the specified number of locks, IMS terminates the application with abend U3301.

      Related Reading: For more information about this abend, see IMS Version 15 Messages and Codes, Volume 3: IMS Abend Codes.

Checkpoints in batch programs

Batch programs that update databases should issue checkpoint calls. The main consideration in deciding how often to take checkpoints in a batch program is the time required to back out and reprocess the program after a failure. A general recommendation is to issue one checkpoint call every 10 or 15 minutes.

If you might need to back out the entire batch program, the program should issue the checkpoint call at the beginning of the program. IMS backs out the program to the checkpoint you specify, or to the most recent checkpoint, if you do not specify a checkpoint. 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.

For a batch program to issue checkpoint calls, it must specify the compatibility option in its PSB (CMPAT=YES). This generates an I/O PCB for the program, which IMS uses as an I/O PCB in the checkpoint call.

Another important reason for issuing checkpoint calls in batch programs is that, although they may currently run in an IMS batch region, they might later need to access online databases. This would require converting them to BMPs. Issuing checkpoint calls in a BMP is important for reasons other than recovery—for example, to release database resources for other programs. So, you should initially include checkpoints in all batch programs that you write. Although the checkpoint support might not be needed then, it is easier to incorporate checkpoint calls initially than to try to fit them in later.

To free database resources for other programs, batch programs that run in a data-sharing environment should issue checkpoint calls more frequently than those that do not run in a data-sharing environment.