Recovery fault recording
When a terminating condition is subject to recovery fault recording processing, then a skeleton fault entry is created and an associated SDUMP (SVC dump) or IEATDUMP (transaction dump) written.
First a check is made to see if security access is granted to use SDUMP as the recovery fault recording dump type, since this type is the preferred dump type for performance reasons. (For details, see Using the XFACILIT resource class for SDUMP RFR data sets.)
If SDUMP cannot be used, then IEATDUMP is instead used as the recovery fault recording dump type.
The term RFR dump refers to the recovery fault recording dump data set, regardless of which dump type is used.
The RFR dump creates an extra data set, into which MVS™ writes a dump of the address space. This data set takes significantly more DASD space than a minidump, but in these situations, Fault Analyzer has failed to gather the minidump. Subsequently, the RFR dump data set is used in place of the minidump for reanalysis of the skeleton fault entry.
UPDINDEX
parameter must be in effect (this is the default).The history file in which the fault entry is created is either the current history file for the abending job, as determined at the time of the abnormal analysis termination, or the dehistory file for the IDIS subsystem. The current history file that is determined for the abending job is attempted to be used first if it is a PDSE. Otherwise, the IDIS subsystem dehistory file is used.
Message IDI0126I is issued to indicate in which history file the fault entry was created.
If the RFR dump is an IEATDUMP, then it is created from the abending region. However, if it is an SDUMP, then it is created by the IDIS subsystem. The skeleton fault entry is always created by the IDIS subsystem.
Once the recovery fault recording process starts, no user exits are driven for the process, except for any Notification user exits specified in the options available to the IDIS subsystem, which are invoked when creating the skeleton recovery fault recording fault entry. To distinguish a recovery fault recording event from other invocations of Notification user exits, the NFY.NFYTYPE field is set to 'R'. For details about the Notification user exit, see Notification user exit.
If the RFR dump is an IEATDUMP, then the default data set name pattern used
is: IDIRFRHQ.IDIRFR.&SYSNAME..D&YYMMDD..T&HHMMSS..S&SEQ.
.
To change this name (or to disable IEATDUMP RFR dumps), see Changing the default recovery fault recording IEATDUMP data set name (RFRDSN). To permit automatic deletion of IEATDUMP data sets when the fault entries they are associated with are deleted, then changing the default high-level qualifier might be required, subject to installation-specific security rules. See Managing recovery fault recording data set access for more information.
Depending on where in the real-time analysis process the problem occurred, reanalysis of the recovery fault recording fault entry is capable of producing a reanalysis report, which is effectively identical to the one that would have been produced if the real-time analysis had completed normally. The fact that a recovery fault recording fault entry was created instead of the normal real-time fault entry is almost transparent to the user for many of the recovery situations.
When a recovery fault recording fault entry is deleted, then the associated RFR dump data set is also automatically deleted to ensure that these data sets are not taking up disk space unnecessarily. Failure to delete the RFR dump data set results in message IDI0187I.