How IMS protects data integrity: commit points
When an online program accesses the database, it is not necessarily the only program doing so. IMS™ and Db2 for z/OS® make it possible for more than one application program to access the data concurrently without endangering the integrity of the data.
To access data concurrently while protecting data integrity, IMS and Db2 for z/OS prevent other application programs from accessing segments that your program deletes, replaces, or inserts, until your program reaches a commit point. A commit point is the place in the program's processing at which it completes a unit of work. When a unit of work is completed, IMS and Db2 for z/OS commit the changes that your program made to the database. Those changes are now permanent and the changed data is now available to other application programs.
What happens at a commit point
When an application program finishes processing one distinct unit of work, IMS and Db2 for z/OS consider that processing to be valid, even if the program later encounters problems. For example, an application program that is retrieving, processing, and responding to a message from a terminal constitutes a unit of work. If the program encounters problems while processing the next input message, the processing it has done on the first input message is not affected. These input messages are separate pieces of processing.
A commit point indicates to IMS that a program has finished a unit of work, and that the processing it has done is accurate. At that time:
- IMS releases segments it has locked for the program since the last commit point. Those segments are then available to other application programs.
- IMS and Db2 for z/OS make the program's changes to the database permanent.
- The current position in all databases except GSAM is reset to the start of the database.
If the program terminates abnormally before reaching the commit point:
- IMS and Db2 for z/OS back out all of the changes the program has made to the database since the last commit point. (This does not apply to batch programs that write their log to tape.)
- IMS discards any output messages
that the program has produced since the last commit point.
Until the program reaches a commit point, IMS holds the program's output messages so that, if the program terminates abnormally, users at terminals and other application programs do not receive inaccurate information from the abnormally terminating application program.
If the program is processing an input message and terminates abnormally, the input message is not discarded if both of the following conditions exist:
- You are not using the Non-Discardable Messages (NDM) exit routine.
- IMS terminates
the program with one of the following abend codes: U0777, U2478, U2479,
U3303. The input message is saved and processed later.
Exception: The input message is discarded if it is not terminated by one of the abend codes previously referenced. When the program is restarted, IMS gives the program the next message.
If the program is processing an input message when it terminates abnormally, and you use the NDM exit routine, the input message might be discarded from the system regardless of the abend. Whether the input message is discarded from the system depends on how you have written the NDM exit routine.
Related Reading: For more information about the NDM exit routine, see IMS Version 13 Exit Routines.
- IMS notifies the MTO that the program terminated abnormally.
- IMS and Db2 for z/OS release any locks that the program has held on data it has updated since the last commit point. This makes the data available to other application programs and users.
Where commit points occur
A commit point can occur in a program for any of the following reasons:
- The program terminates normally. Except for a program that accesses Fast Path resources, normal program termination is always a commit point. A program that accesses Fast Path resources must reach a commit point before terminating.
- The program issues a checkpoint call. Checkpoint calls are a program's means of explicitly indicating to IMS that it has reached a commit point in its processing.
- If a program processes messages as its input, a commit point might
occur when the program retrieves a new message. IMS considers this commit point the start of
a new unit of work in the program. Retrieving a new message is not
always a commit point. This depends on whether the program has been
defined as single mode or multiple mode.
- If you specify single mode, a commit point occurs each time the program issues a call to retrieve a new message. Specifying single mode can simplify recovery, because you can restart the program from the most recent call for a new message if the program terminates abnormally. When IMS restarts the program, the program begins by processing the next message.
- If you specify multiple mode, a commit point occurs when the program issues a checkpoint call or when it terminates normally. At those times, IMS sends the program's output messages to their destinations. Because multiple-mode programs contain fewer commit points than do single mode programs, multiple mode programs might offer slightly better performance than single-mode programs. When a multiple mode program terminates abnormally, IMS can only restart it from a checkpoint. Instead of reprocessing only the most recent message, a program might have several messages to reprocess, depending on when the program issued the last checkpoint call.
The following table lists the modes in which the programs can run. Because processing mode is not applicable to batch programs and batch-oriented BMPs, they are not listed in the table. The program type is listed, and the table indicates which mode is supported.
| Program type | Single mode only | Multiple mode only | Either mode |
|---|---|---|---|
| MPP | X | ||
| IFP | X | ||
| Transaction-oriented BMP | X |
You specify single or multiple mode on the MODE parameter of the TRANSACT macro.
Related Reading: For information on the TRANSACT macro, see IMS Version 13 System Definition.
See the following figure for an illustration of the difference between single-mode and multiple-mode programs. A single-mode program gets and processes messages, sends output, looks for more messages, and terminates if there are no more. A multiple-mode program gets and processes messages, sends output, but has a checkpoint before looking for more messages and terminating. For a single-mode program, the commit points are when the message is obtained and the program terminates. For multiple-mode, the commit point is at the checkpoint and when the program terminates.
Db2 for z/OS does some processing with multiple- and single-mode programs that IMS does not. When a multiple-mode program issues a call to retrieve a new message, Db2 for z/OS performs an authorization check. If the authorization check is successful, Db2 for z/OS closes any SQL cursors that are open. This affects the design of your program.
The Db2 for z/OS SQL COMMIT statement causes Db2 for z/OS to make permanent changes to the database. However, this statement is valid only in TSO application programs. If an IMS application program issues this statement, it receives a negative SQL return code.