The z/OS Automatic Restart Manager (ARM)

You can use the z/OS® Automatic Restart Manager (ARM) to restart a subsystem (or job) after a z/OS hardware or software failure.

In addition, in the event of a z/OS hardware or software failure that requires you to move a subsystem from one z/OS system to another, ARM will move all the subsystems defined in the same restart group as a group to a remaining z/OS system.

IMS supports ARM in these environments:

DL⁄I, DBB, and IMS utilities are not supported. The IMS control region is the only region restarted by ARM.

Attention: The DL⁄I SAS and DBRC regions are started internally by the IMS control region. IMS dependent regions are not automatically restarted, because they are normally restarted after the IMS control region has restarted.

The element name that IMS uses on the registration call to ARM is the IMSID. The element type is SYSIMS. Duplicate element names are not allowed by ARM. When ARM is used, the IMSIDs of online systems and FDBR systems must be unique.

ARM provides a default ARM level of 1 for SYSIMS.

The IMSID must be unique across the sysplex. ARM tries to move IMS to a surviving z/OS if a failure occurs on the z/OS or the CPC on which the IMS is executing. If the IMSID is not unique, ARM might move the IMS from the failing CPC to one that already has an IMS with the same IMSID.

If IMS is canceled by z/OS, IMS is only automatically restarted by ARM if the ARMRESTART option is specified on the CANCEL or FORCE command.

IMS maintains the following user abend table and de-registers from ARM any time one of these abends occurs:

  1. U0020: USER 20 - MODIFY
  2. U0028: USER 28 - ⁄CHE ABDUMP
  3. U0604: USER 604 - ⁄SWITCH
  4. U0758: USER 758 - QUEUES FULL
  5. U0759: USER 759 - QUEUE I⁄O ERROR
  6. U2476: USER 2476 - CICS® TAKEOVER

The first three of these abends are the result of operator intervention. The last three abends require some external changes before IMS can be restarted.