Batch backout
If the failing application program is a batch updater involved in block-level data sharing, IMS does not always automatically back out its uncommitted database changes.
Just as in a nonsharing environment, you must recover the database if any of the following is true:
- The batch region does not use DASD logging
- You do not specify BKO=Y as an execution parameter
- The failure is not a DL/I-detected error
In a block-level-data-sharing environment, however, you must back out database changes of all batch update application programs using the Batch Backout utility (DFSBBO00).
During block-level sharing, if an application program deadlock occurs involving only batch update jobs, IMS abnormally terminates one of these jobs with abend U0777. If IMS can dynamically backout changes, other application programs continue processing. Otherwise, IMS abnormally terminates the other application programs with abend U3303.
You must recover all of the batch jobs that did not have dynamic backout by executing the Batch Backout utility for each of them. Because the locks held by these batch jobs could affect access of other batch jobs or online IMS systems, you should begin batch backouts promptly.
- The Batch Backout utility requires an IRLM for its execution.
- The Batch Backout utility backs out to the last successful checkpoint.