DeferredReport

Figure 1. Syntax

FATASKS specification

This option applies to real-time analysis only, and can be used when real-time performance is critical. When used, no real-time analysis report is produced, but a fault entry is written that can later be reanalyzed.

For compatibility with earlier versions of Fault Analyzer, specification of

DeferredReport(CICSFATasks(max_slots<,max_waits>))

is permitted until further notice. This specification is equivalent to

DeferredReport(CICS(FATasks(max_slots<,max_waits>)))

The execution environment under which the DeferredReport option is enabled is specified using the CICS® | NoCICS, IMS™ | NoIMS, or Batch | NoBatch suboptions.

When the DeferredReport option is not specified, the product default is CICS® only:
```
DEFERREDREPORT(CICS(FATASKS(1,20)),NOIMS,NOBATCH)
```
When the DeferredReport option is specified without any suboptions, the default is all execution environments.

As far as the DeferredReport option is concerned, a CICS® transaction that also interfaces with IMS™, is controlled using the CICS® suboption. Hence, specification of

DeferredReport(NoCICS,IMS)

disables the DeferredReport option for such an application, whereas

DeferredReport(CICS,NoIMS)

enables it.

When used with CICS®, the optional FATASKS suboption can be specified:

max_slots

Specifies the maximum number of execution slots that are made available. Each execution slot permits one instance of Fault Analyzer real-time analysis to run, effectively enabling parallel execution or multi-tasking.

The valid range is 1 - 6.

The default is 1.

If NODeferredReport is specified, then the maximum number of execution slots is set to 1.

MaxWaitSeconds(seconds)

Specifies the maximum number of seconds that a fault is allowed to be queued waiting for analysis. If a fault has been waiting for longer than the current limit in effect, then message IDI0132W is issued and the analysis of that fault is skipped, thus requiring normal CICS® transaction dump analysis to be performed (that is, not using Fault Analyzer).

The waiting queue length is always 20 when this suboption is specified. The behavior described for the max_waits suboption is still applicable to faults that occur when 20 queued up faults are already waiting.

The valid range is 0 - 3600. If 0 is specified, then no time limitation is imposed.

The default is 0.

Using MaxWaitSeconds(seconds) instead of max_waits is recommended.

max_waits

Specifies the maximum number of faults allowed to be queued for analysis. If the maximum has already been reached when another fault occurs, then message IDI0118W is issued and the analysis of that fault is skipped, thus requiring normal CICS® transaction dump analysis to be performed (that is, not using Fault Analyzer).

The valid range is 1 - 20.

The default is 20.

Note: It might be desirable to reduce max_waits to a lesser value if analysis is slow in a CPU constrained environment. This reduction could have the effect of abends being rejected from analysis with the IDI0118W message, but that might be preferred during high abend activity to having the task wait for abend processing in an over-committed environment.

Note:

If DeferredReport is in effect, and the MaxMinidumpPages limit is exceeded, then the DeferredReport option is overridden and a report is written. If this situation occurs, then message IDI0133W is issued and a note is added against the DeferredReport option in the "Options in Effect" section of the analysis report. To prevent frequent occurrences of this situation, ensure that the MaxMinidumpPages limit is adequate.
Although fault entries written with the DeferredReport option in effect do not initially contain a saved report, one is added the first time the 'V' line command is used from the Fault Entry List display, given that the user performing this action has update access to the history file.
This option (but not the FATASKS suboption) can be modified or set by an Analysis Control user exit. For details, see Analysis Control user exit.
For maximum Fault Analyzer performance, $$INDEX member caching in the IDIS subsystem should also be considered. For details, see Caching of history file $$INDEX data.