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. 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 intitial start destroys all information from the previous run of CICS.

The CICS diagnostic run mechanism

One way to gather the required diagnosis information is to 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. To supplement DFHJUP’s output, you should perform a diagnostic run of CICS, using the corrupt system log, before performing the initial start. 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.

Benefits of a diagnostic run

The advantages of performing a diagnostic run are:

How to perform a diagnostic run

For a diagnostic run to take place, AUTO must be specified on the START system initialization parameter. If the system log becomes corrupt, CICS:

There may be occasions other than when the system log has become unusable when you feel it would be useful to perform a diagnostic run. You can use the recovery manager utility program, DFHRMUTL, to specify a diagnostic run. For information about DFHRMUTL, see the CICS® Operations and Utilities Guide.

Getting dumps of the MVS logger and coupling facility address spaces

For reliable diagnosis, it is important that you have dumps of the MVS logger address space and (if applicable) the coupling facility structures used by the system log. This means that, before performing the diagnostic run, you will probably need to set a SLIP trap, as described in Setting a SLIP trap. You need to set a SLIP if any of the following are true:

When specifying the SLIP, note the following:

  1. Set the trap for the specific DFHLG07xx message that CICS issued when the original failure occurred--see the example SLIP in topic Figure 20. When the diagnostic run occurs and the failure repeats, the message will drive the SLIP.

    Occasionally, the DFHLG07xx message that was issued at the time of the original failure is not repeated during a diagnostic run--instead, a different DFHLG07xx message is issued. Therefore the SLIP is not triggered. If this happens, perform another diagnostic run. This time, however, set the SLIP for the DFHLG07xx message that was issued during the first diagnostic run.

  2. You do not need to specify a dump of the CICS system, because one is taken automatically by the diagnostic run mechanism. Change the JOBLIST parameter in the example SLIP to read:
    JOBLIST=(IXGLOGR,XCFAS),
  3. Specify a dump of the MVS logger address space--see the example SLIP. (If you have applied MVS APAR OW27057, and the original failure occurred because the MVS logger was unable to find a specific log stream block identifier, an extra dump may be produced.)
  4. If the system log uses coupling facility log streams, specify a dump of the coupling facility structure. You can get the name of the structure (or structures) from the two DFHLG0104 messages that were issued when CICS connected to DFHLOG and DFHSHUNT during the run in which the failure occurred.

    If DFHLOG and DFHSHUNT use separate coupling facility structures, dump both structures. Specify the names of both structures on the STRLIST parameter.

Related concepts
Shutdown and restart recovery
Related tasks
Diagnosing problems in the MVS logger
Restarting CICS after a system log failure
Using DFHJUP to read log streams
[[ Contents Previous Page | Next Page Index ]]