Unit of work in IMS online programs

IMS applications can explicitly define units of work by using a CHKP, SYNC, ROLL, or ROLB call, or, for single-mode transactions, a GU call.

In IMS, a unit of work starts when one of the following events occurs:
  • When the program starts
  • After a CHKP, SYNC, ROLL, or ROLB call has completed
  • For single-mode transactions, when a GU call is issued to the I/O PCB
A unit of work ends when one of the following events occurs:
  • The program issues either a subsequent CHKP or SYNC call, or, for single-mode transactions, a GU call to the I/O PCB. At this point in the processing, the data is consistent. All data changes that were made since the previous commit point are made correctly.
  • The program issues a subsequent ROLB or ROLL call. At this point in the processing, your program has determined that the data changes are not correct and, therefore, that the data changes should not become permanent.
  • The program terminates.
Restriction: The SQL COMMIT and ROLLBACK statements are not valid in an IMS environment.
A commit point occurs in a program as the result of any one of the following events:
  • The program terminates normally. Normal program termination is always a commit point.
  • 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.
  • The program issues a SYNC call. A SYNC call is a Fast Path system service call to request commit-point processing. You can use a SYNC call only in a non-message-driven Fast Path program.
  • For a program that processes messages as its input, a commit point can occur when the program retrieves a new message. This behavior depends on the mode that you specify in the APPLCTN macro for the program:
    • If you specify single-mode transactions, a commit point in Db2 occurs each time the program issues a call to retrieve a new message.
    • If you specify multiple-mode transactions or you do not specify a mode, a commit point occurs when the program issues a checkpoint call or when it terminates normally.
At the time of a commit point, the following actions occur:
  • IMS and Db2 can release locks that the program has held since the last commit point. Releasing these locks makes the data available to other application programs and users.
  • Db2 closes any open cursors that the program has been using.
  • IMS and Db2 make the program's changes to the database permanent.
  • If the program processes messages, IMS sends the output messages that the application program produces to their final destinations. Until the program reaches a commit point, IMS holds the program's output messages at a temporary destination.
If the program abends before reaching the commit point, the following actions occur:
  • Both IMS and Db2 back out all the changes the program has made to the database since the last commit point.
  • IMS deletes any output messages that the program has produced since the last commit point (for nonexpress PCBs).
  • If the program processes messages, people at terminals and other application programs receive information from the terminating application program.

If the system fails, a unit of work resolves automatically when Db2 and IMS batch programs reconnect. Any indoubt units of work are resolved at reconnect time.