Processing transactions against unavailable data in DB/DC and DBCTL environments

When an application program attempts to access unavailable data, IMS abends the application program. Use the INIT call to prevent application programs from being scheduled when a database is unavailable.

IMS schedules an application program even if that application program might try to access an unavailable database. The application program can be sensitive or insensitive to unavailable data. To be sensitive, it must issue the INIT call. This requests that a status code is returned in the PSB if a subsequent call requires access to data that is unavailable. If the application program has not issued the INIT call and a call requires access to unavailable data, IMS abends the application program with U3303, and backs out any updates it has made.

After ten U3303 abends, IMS takes the following action:

• In a DB/DC environment, IMS stops the transaction with a USTOPPED condition.
• In a DBCTL environment, IMS stops the PSB, preventing further scheduling of the application program.

The disposition of the transaction depends on whether it is serial or not. Serial transactions are those that must be processed in the order of arrival. If it is serial, the processing of any transaction of its type is stopped. If it is not serial, only the processing of this particular transaction is stopped.

Data can be unavailable for these reasons:

• The database is stopped, locked, or unavailable for update.
• A lock cannot be obtained, because it is held by a failing component in a data sharing environment.
• In an XRF environment with block-level data sharing, the takeover system initiated new work before the data sharing configuration is revalidated.

IMS tries to resume transaction processing when any of these events occurs:

• A /DEQ SUSPEND command is issued.
• A /START TRAN command is issued for a transaction type that is stopped or that has stopped messages.
• A /START DATABASE command is issued for a database that is unavailable and in the intent list of the program requesting the transaction.
• A failing IRLM is reconnected.
• An emergency restart completes.
• An XRF takeover completes.
• A sharing IMS system completes a batch backout.