Dynamic backout

As in a nonsharing environment, an online IMS system in a data-sharing environment dynamically backs out an application program's uncommitted database changes and discards its uncommitted output messages if the application program fails or requests backout with a rollback call. In a data-sharing environment, however, IRLM locks and RECON status indicators ensure integrity by protecting uncommitted changes from sharing IMS systems.

After an application program failure, operation of the system and other application programs continues uninterrupted.

If the application program is a batch updater in a block-level data-sharing environment, IMS dynamically backs out changes in any of the following situations:

• When the application program issues a rollback call (ROLL, ROLB, or ROLS).
• When the batch region uses system logging allocated to DASD, you specify BKO=Y as an execution parameter, and the application program issues a ROLB or ROLS call or a DL/I-detected error occurs.
• When some types of resource shortages and deadlocks involving two or more batch update application programs occur, IMS performs dynamic backout for one or more of the batch application programs; all continue executing, provided that the involved regions use DASD logging and you specify BKO=Y.

In these situations, you are not involved in recovery actions.

For either online or batch IMS systems, if the database is shared at the database level, other application programs might read uncommitted data before the database is dynamically backed out. Backout affects only the updating application program's data in the database—not the output of any other application program that used this uncommitted data. This is a consequence of the nature of PROCOPT=GO processing, rather than of the nature of database backout in a data-sharing environment.

If a dynamic backout for a database fails, you must back out the database using batch backout. Then, you must restart that database using a /START DB or UPDATE DB START(ACCESS) command.