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 CheckpointsAn 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 CheckpointsA 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:
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 CheckpointsFor 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:
Related Reading: See the "Maintaining Database Integrity" chapter in IMS Version 9: Application Programming: Database Manager for the details about symbolic checkpointing. |