IMS Checkpoints


IMS provides facilities to keep the application data stored in databases in a consistent state. This section describes techniques to maintain consistent data from the application's point of view.

The application must use IMS facilities to maintain consistent data. However, the facilities to consistently update the database also ensure that all internal IMS information (pointers, free space elements, and more) are kept consistent, though these activities are transparent to the application program.

An application program might make updates to several IMS databases. If a problem is encountered part of the way through these updates, either because the program fails or application logic dictates that the application cannot continue with the processing, then the application must restore the data in the databases to the state before the updates started.

For example, a program might add a detail to an order in the order database and then needs to update the part database to reduce the quantity of parts available for ordering. If the program updates the order database, but then fails before updating the part database, the order is recorded, but the quantity of parts is still shown as available for ordering in the part database. The update to the order database and the update to the part database make up a single unit of work (UOW). For the application data to be consistent, either all the updates in a unit of work must be written to the database successfully (committed) or none of the updates in the UOW must be committed.

To maintain database consistency, IMS uses the concept of the application checkpoint.

Application Program Checkpoints

An application program checkpoint, which applies to the single execution of an application program, is different from an IMS system checkpoint. IMS takes system checkpoints to allow the IMS subsystem to recover from a failure of the complete IMS subsystem. The application program checkpoint indicates to IMS the end of the application's unit of work (UOW) and causes IMS to commit all updates made in that UOW. An application's UOW commences when the application program starts running. By default, IMS takes an application checkpoint and commits all updates when the application terminates normally.

Application program checkpoints have two levels of functionality: basic checkpoints and symbolic checkpoints.

Basic Checkpoints

A basic checkpoint is when you explicitly request a checkpoint by issuing a CHKP call, which also tells IMS that the application program is starting another UOW. If an application program terminates abnormally, then all database changes are backed out to the last commit point (the start of program if application checkpoints are not being used, or last CHKP call if application checkpoints are used). The application can also manually back out all updates within the current UOW by using the ROLB, ROLL, or ROLS calls. The difference between the calls relates to action taken by the IMS TM, if applicable, and whether the application regains control after the call.

Related Reading: For complete descriptions of the CHKP, ROLB, ROLL, and ROLS functions, see "Maintaining Database Integrity" in the "Recovering Databases and Maintaining Database Integrity" chapter of IMS Version 9: Application Programming: Database Manager.

For long-running batch and BMP application programs, you should issue explicit CHKP calls at regular intervals. As the programs read database records, details of these database records (internal IMS addresses) are stored by the IMS subsystem until the application reaches a commit point (the application issues a CHKP or terminates). IMS stores the details to prevent other application programs from updating the same database records while the application is working with them. These details are stored in an internal buffer in the IMS address space. If the application does not issue checkpoints at regular intervals, the following problems can occur:

  • The IMS address space has insufficient storage to contain all the buffers needed to contain the update details, which results in the application program being terminated.

  • If the application fails, or issues a ROLL, ROLB, or ROLS call, IMS must back out all the updates performed by the application. If the application has been running for a long time without issuing CHKP calls, the application might take the same amount of time to back out all the updates as it took to apply them. If you correct the problem and restart the program, it will take the same time again to reprocess the updates.

  • With BMP applications, other applications that process the databases that are managed by the same IMS control region might be prevented from accessing these database records. Other applications that are being used by online users might experience severe response-time problems as a result of the BMP application's failure to issue regular CHKP calls. For batch jobs, you might encounter similar problems if block-level data sharing is used. Also, the IMS ENQ/DEQ block supply might become exhausted, which results in a U0775 abend of all of the application programs that are running at the time of the abend.

Long-running programs should issue CHKP or SYNC calls based on the number of database calls made. As a rule of thumb, initially issue batch CHKP calls for every 500 database calls. You do not want to issue CHKP calls too frequently because overhead is involved in writing all the updates and the application repositioning itself in all the IMS databases after the CHKP call. Except for DEDBs with PROCOPT=P, IMS loses the position in the databases after a CHKP call, so where such positioning is important to the application logic, a CHKP call must be followed up with a GU call to the last record retrieved in databases.

SYNC calls perform the same synchronization functions as basic CHKP calls but avoid issuing a message to the IMS master terminal for every sync point and, in doing so, flooding the terminal with messages. All online programs must always restart from the last successful sync point, so the CHKP ID issued by a CHKP call is of no value.

Obviously you cannot CHKP more frequently than the number of calls in one UOW. IBM recommends you code the program so it can be easily changed because you might need to tune the checkpoint frequency. It is best to code a CHKP call in the program as a variable, possibly as an input parameter at run time.

Symbolic Checkpoints

For applications that run in batch and BMP address spaces, extended checkpoint functionality is available by using symbolic checkpoints. Symbolic checkpoints provide the following additional facilities that enable application programs that run in batch or BMP address spaces to be restarted:

  • The XRST call is made at the start of the program and indicates to IMS that the application is using symbolic checkpoints. If this is the first time the application has run, IMS continues processing. If this iteration of the application program is a result of a restart, IMS performs some additional steps that are described later in this list.

  • The CHKP call is extended to allow the application to pass up to seven areas of program storage to IMS. These areas are saved by IMS and returned to the program if it is restarted. These areas can be used to store variables (such as accumulated totals or parameters) that the application might need to resume processing.

  • Each CHKP call is identified by an ID that is generated by the application program. This ID is displayed in an IMS message output to the operating system log when the checkpoint is successfully completed. IBM recommends that you make each of these IDs unique. Nothing in IMS enforces this practice.

  • If the program fails, it can be restarted (after you correct the problem) from either the last successful checkpoint (for true batch jobs only) or any previous successful checkpoint in that run. IMS will reposition the databases (including non-VSAM sequential files that are accessed as GSAM) to the position when the checkpoint was taken. When the XRST call is made on restart, the program receives the ID of the checkpoint it is restarting from, together with any user areas passed to IMS when that CHKP call was issued.

Related Reading: See the "Maintaining Database Integrity" chapter in IMS Version 9: Application Programming: Database Manager for the details about symbolic checkpointing.



Introduction to IMS. Your Complete Guide to IBM's Information Management System
An Introduction to IMS: Your Complete Guide to IBMs Information Management System
ISBN: 0131856715
EAN: 2147483647
Year: 2003
Pages: 226

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net