Dealing with a corrupt system log

If the system log becomes corrupt, CICS quiesces. After the system log has been corrupted, it cannot be used again; to get CICS back into production, you must perform an initial start.

About this task

To prevent the problem recurring, you also need to gather diagnosis information that will enable IBM® Service to discover why the log was corrupted. Unfortunately, performing an initial start destroys all information from the previous run of CICS. To gather diagnostic information:

Procedure

  1. Scan the failed system log, using a utility such as DFHJUP.
    However, the output produced by DFHJUP in these circumstances is not easy to interpret.
  2. To supplement DFHJUP's output, perform a diagnostic run of CICS, using the corrupt system log, before performing the initial start.
    1. Specify AUTO on the START system initialization parameter.
      If the system log becomes corrupt, CICS:
      • Sets the recovery manager autostart override record in the global catalog so that the next automatic restart of CICS is a diagnostic run (AUTODIAG).
      • Issues message DFHRM0152, saying that the next automatic restart will be a diagnostic run, and should be performed before an initial start.
    2. If the system log is not corrupt, but you still want to perform a diagnostic run, use the recover manager utility program DFHRMUTL.
      For information about DFHRMUTL, see Recovery manager utility (DFHRMUTL).
    On a diagnostic run, CICS:
    1. Produces a dump of the CICS system state, retrieved from the failed system log.
    2. Terminates. Note that, on a diagnostic run, CICS performs no recovery work and no new work.
    The output produced by a diagnostic run is usually passed to IBM Service.