Recovery involving IRLM

Failure in one part of a data-sharing configuration does not usually cause the other parts to fail.

For example:

• If one z/OS® system fails because of a hardware problem or an abnormal termination of the z/OS operating system, the other systems—with their IRLMs and other IMS systems—continue to run. In this case, the surviving IRLMs are notified of the failure by z/OS and then provide the necessary retained lock protection for locks owned by the failing member.
• If an IRLM fails, its associated IMS online systems continue to run while all active application programs receive U3303 abends, and IMS suspends transaction scheduling, allowing backouts to complete. Batch IMS systems terminate to protect database integrity. The surviving IRLMs are notified of the failure by z/OS and then provide the necessary retained lock protection for locks owned by the IMS on the failing IRLM.

  If an IRLM fails in an IMS DBCTL environment, in-doubt threads receive a U3303 abend on their next DL/I calls. The in-doubt threads remain active until phase 2 of sync-point processing. After processing phase 2 commit or abort, the thread is terminated. The IMS DBCTL system tries to reconnect to IRLM after all in-doubt threads are terminated.

• If an IMS system fails, its associated IRLM and other IMS systems continue to run, with locks owned by the failing IMS protected by retained locks created by its IRLM.
• If DBRC fails, its IMS system abnormally terminates, but the associated IRLM and the other IMS systems and their IRLMs continue to run.