Restarting the Catalog Address Space

The catalog address space is designed to restart with a minimum of interruption to your system. Requests that are being processed are generally able to be restarted from the beginning. Requests that are made while the address space is in the process of restarting are temporarily suspended.

The catalog address space is critical to the functioning of your system, and there is always the possibility that a restart might fail. However, the use of the restart facility might also prevent an IPL or clear other error conditions that are a result of problems associated with the use of catalogs. For example, the following problems are typically corrected by a restart:

Inability to vary a volume containing a catalog offline, when a MODIFY CATALOG,CLOSE command does not release the volume
ABENDs in the catalog address space that relates to lack of storage (such as 878 ABENDs)
ABENDs in the catalog address space that might indicate damage to control blocks (such as repeated 0C4 ABENDs at the same location)
ENQ lockouts, particularly on the SYSIGGV2 resource, when the MODIFY CATALOG,ABEND command will not remove the task in error
Installing catalog maintenance to correct a problem when an IPL is not necessary or feasible

Do not use RESTART to refresh catalog or VVDS control blocks or to change catalog characteristics. The use of other MODIFY command formats are designed to accomplish this on a catalog-by-catalog basis. There is a risk that the catalog address space restart might fail for some unanticipated reason. If this occurs, it will be necessary to IPL the system to recover the address space. However, a restart failure is a very unlikely occurrence.

It is also possible that a catalog request that is currently being processed cannot be properly retried after being interrupted by these commands. For example, this could occur with a DEFINE command of a VSAM data set that is partially completed at the time of the restart. It is recommended that you try to quiesce system activity as much as feasible before doing a restart, or at least attempt to minimize the use of catalogs.

When you enter MODIFY CATALOG,RESTART, message IEC363D is displayed as follows:

IS THIS RESTART RELATED TO AN EXISTING CATALOG PROBLEM (Y OR N)?

If you answer 'Y', the message IEC364D is displayed as follows:
```
HAS AN SVC DUMP OF THE CATALOG ADDRESS SPACE ALREADY BEEN TAKEN (Y OR N)?
```
- If you answer 'Y', the catalog address space ends abnormally with an 81A ABEND, which causes a restart.
- If you answer 'N', an SVC dump is automatically taken before the catalog address space ends abnormally with an 81A ABEND, which causes a restart.
If you answer 'N', the catalog address space ends abnormally with an 81A ABEND, which causes a restart.

All catalog tasks that were in process at the time of the 81A ABEND are restarted from the beginning.

The restart of CAS in a new address space should be transparent to all users. However, even when all requests are redriven successfully and receive a return code 0, the system might produce indicative dumps on the console, the system log, and on user job logs. There is no way to suppress these indicative dumps.

As noted above, a request might not successfully be restarted. If this is the case, the appropriate return and reason code information, associated messages, and possibly system dumps will be produced.

The catalog address space is designed to recover from cross-memory failures that can occur during CAS restart. CAS recognizes and recovers from the following abend codes, that might occur during a restart: 052, 058, 066, 070, 073, and 0Dx. You can ignore any indicative dumps produced by the system for these abend codes. Only the final catalog return code, which should be 0, is significant.