DFS2482I DBRC LOG xxxx EXIT FAILED (yy)

Explanation

When xxxx indicates EOV or SYNAD, either a return code of X'00' or X'04' indicates that it was successful, or a return code of X'12' indicates that it was unsuccessful.

The DBRC return code is displayed as yy (hexadecimal) in the message. See the DBRC request return code information.

When xxxx indicates OPEN and yy indicates RC(4), and you are trying to cold start an IMS system that previously failed, the correct procedure is to do an emergency restart of IMS. If you are cold starting IMS because of an emergency restart failure, you must close the log stream of the previous IMS instances and clean up the subsystem record by using the NOTIFY.PRILOG and CHANGE.SUBSYS commands. Also ensure that you have completed necessary steps such as batch backout for full-function databases, and some method of forward recovery for Fast Path DEDBs, before you cold start IMS. (However, if FDBR was active when IMS abended, and successfully completed recovery processing, batch backout and DEDB forward recovery are not necessary.)

Message DFS4168I is an indication that FDBR successfully completed recovery processing. If DFS0693I messages are received during FDBR recovery processing, indicating that resolve indoubt structures were built for in-doubt units of work, cold start is possible but you must manually resolve the in-doubt units of work using commands from the commit coordinator side (for example, CICS® or RRS).

For ESS processing such as DB2® or IBM® MQ, IMS is the commit coordinator and you will not normally receive messages from FDBR indicating an in-doubt condition. IMS provides a sample exit, DFSFIDN0, which will issue a DFS3722I message with recommended recovery actions for each in-doubt ESS unit of work. The in-doubt UOWs will also be visible from the ESS participant subsystem, and in the event of IMS cold start, must be resolved using appropriate participant subsystem commands.

IMS might build Extended Error Queue Elements (EEQEs) and register them with DBRC during FDBR recovery processing of in-doubt units of work. These EEQEs protect the in-doubt IMS database resources from being accessed by other data-sharing IMS subsystems. If IMS is cold started, in-doubt EEQEs will require manual processing. For DEDBs, it is safe to delete such EEQEs using DBRC commands because DEDBs are never updated before commit processing. For full-function databases, you might need to perform database recovery on the databases that have in-doubt EEQEs.