Suppressing dumps that duplicate previous dumps

If your installation is using dump analysis and elimination (DAE), code your program to provide symptom data that DAE can compare with the symptom data from previous dumps. Through this comparison, DAE can reduce the number of duplicate dumps. Another benefit is that the symptom data, which is stored in the DAE data set, provides a consistent set of data for identifying a failure.

DAE suppresses dumps that match a dump you already have. Each time DAE suppresses a duplicate dump, the system does not collect data for the duplicate or write the duplicate to a data set. In this way, DAE can improve dump management by only dumping unique situations and by minimizing the number of dumps.

To perform dump suppression, DAE builds a symptom string, if the data for it is available. If the symptom string contains the minimum problem data, DAE uses the symptom string to recognize a duplicate SVC dump, SYSMDUMP dump, or Transaction dump requested for a software error. When installation parameters request suppression, DAE suppresses the duplicate dump. The following describes DAE processing.
  1. DAE obtains problem data. DAE receives the data in the system diagnostic work area (SDWA) or from values in a SYMREC parameter on the SDUMP, SDUMPX or IEATDUMP macro that requested the dump.
    • The system supplies system-level data, such as the abend and reason codes, the failing instruction, and the register/PSW difference.
    • The ESTAE routine or the functional recovery routine (FRR) of the failing program supplies module-level information, such as the failing load module name and the failing CSECT name.
  2. DAE forms a symptom string. DAE adds a descriptive keyword to each field of problem data to form a symptom. DAE forms MVS™ symptoms, rather than RETAIN symptoms. DAE combines the symptoms for a requested dump into a symptom string.

    The following tables show the required and optional symptoms. SDWA field names are given for the symptoms the failing program must provide to enable dump suppression. The tables have both MVS and RETAIN symptoms so that you can relate the MVS symptoms DAE uses to the RETAIN symptoms you might use to search the RETAIN data base. An MVS symptom string must contain at least five symptoms that are not null. DAE places symptoms into strings in the order shown in the tables.

    Required symptoms are first and must be present.

    Symptom SDWA Field MVS Keyword RETAIN Keyword
    Name of the failing load module SDWAMODN MOD/name RIDS/name#L
    Name of the failing CSECT SDWACSCT CSECT/name RIDS/name

    Optional symptoms must follow the required symptoms. DAE needs at least three of these optional symptoms to make a useful symptom string.

    Symptom SDWA Field MVS Keyword RETAIN Keyword
    Product/component identifier with the component identifier base SDWACID, SDWACIDB PIDS/name PIDS/name
    System completion (abend) code   AB/S0hhh AB/S0hhh
    User completion (abend) code   AB/Udddd AB/Udddd
    Recovery routine name SDWAREXN REXN/name RIDS/name#R
    Failing instruction area   FI/area VALU/Harea
    PSW/register difference   REGS/hhhhh REGS/hhhhh
    Reason code, accompanying the abend code or from the REASON parameter of the macro that requests the dump   HRC1/nnnn PRCS/nnnn
    Subcomponent or module subfunction SDWASC SUB1/name VALU/Cname
  3. DAE tries to match the symptom string from the dump to a symptom string for a previous dump of the same type, that is, SVC dumps, with SVC dumps and SYSMDUMP, or Transaction dumps with a previous SYSMDUMP or Transaction dump. When DAE finds a match, DAE considers the dump to be a duplicate.

    When DAE is started, usually during IPL, DAE selects from the symptom strings (stored in the DAE data set) that were active in the last 60 days: either the string was created for a unique dump within the last 60 days, or its dump count was updated within the last 60 days. The selected symptom strings are placed in virtual storage.

    The systems in a sysplex can share the DAE data set to suppress duplicate dumps across the sysplex. While each system in a sysplex can use its own DAE data set, IBM® recommends that systems in a sysplex share a DAE data set so that:
    • DAE can write a dump on one system and suppress duplicates on other systems in the sysplex.
    • Only one DAE data set is required, rather than a data set for each system.
  4. DAE updates the symptom strings in storage and, later, in the DAE data set, if updating is requested.
    • For a unique symptom string, DAE adds a new record. The record contains the symptom string, the dates of the first and last occurrences, the incidence count for the number of occurrences, and the name of the system that provided the string.
    • For a duplicate symptom string, DAE updates the incidence count for the string, the last-occurrence date, and the name of the last system that found the string.

    In a sysplex, changes to the in-storage strings are propagated to the in-storage strings throughout the sysplex.

  5. DAE suppresses a duplicate dump, if DAE is enabled for dump suppression.

    Note that, if you specify an ACTION of SVCD, TRDUMP, NOSUP, or RECOVERY on a SLIP command, the command overrides DAE suppression and the system writes the dump. Also, dumps requested by the DUMP operator command are not eligible for suppression.

    When DAE does not suppress a dump, the symptom string is in the dump header; you can view it with the IPCS VERBEXIT DAEDATA subcommand. DAE also issues informational messages to indicate why the dump was not suppressed.

    DAE suppresses a dump when all of the following are true:
    • DAE located in the dump the minimum set of symptoms.
    • The symptom string for the dump matches a symptom string for a previous dump of the same type.
    • Either of the following is true:
      • The current ADYSETxx parmlib member specifies SUPPRESS for the type of dump being requested and the VRADAE key is present in the SDWA. To set the VRADAE key, a recovery routine issues the following macro: 
        VRADATA KEY=VRADAE
      • A VRADATA VRAINIT must be done prior to any VRADATA KEY= request in order for the VRA data to be properly processed by both DAE and the SDWA formatter.
      • The current ADYSETxx parmlib member specifies SUPPRESSALL for the type of dump being requested and the VRANODAE key is absent from the SDWA. The VRANODAE key specifies that the dump is not to be suppressed.

    The following table shows the effect of the VRADAE and VRANODAE keys on dump suppression when SUPPRESS and SUPPRESSALL keywords are specified in the ADYSETxx parmlib member. For SUPPRESS, the VRANODAE key can be present or absent; the system does not check it. The table assumes that the symptom string from the dump has matched a previous symptom string.

    ADYSETxx Option VRADAE Key in SDWA VRANODAE Key in SDWA Dump Suppressed?
    SUPPRESS Yes N/A Yes
    SUPPRESS No N/A No
    SUPPRESSALL Yes No Yes
    SUPPRESSALL No Yes No
    SUPPRESSALL No No Yes
    SUPPRESSALL Yes Yes No

    The only way to ensure that a dump is not suppressed, regardless of the contents of the ADYSETxx parmlib member, is to specify the VRANODAE key in the SDWA, or DAE=NO on SYMRBLD used to build a symptom record passed to the SDUMPX or IEATDUMP macro with the SYMREC keyword.

References:
Parent topic: ABEND dumps