Easytrieve Dump Analysis

Two Kinds of Dumps: Easytrieve vs z/OS

Mainframe troubleshooting vocabulary overloads the word dump. In Easytrieve work, three ideas often appear together but must stay separate in your notebook. First, Easytrieve runtime diagnostics on SYSPRINT explain what the product thought went wrong—file status, data exceptions, report writer errors, and messages tied to your source. Second, when ABEXIT is coded on the PARM statement, Easytrieve can emit an Error Analysis report and optionally request a dump through ABEXIT SNAP. Third, z/OS may also capture an operating-system dump when a severe error occurs. That system dump is valuable to systems programming but is not a substitute for reading Easytrieve's own report.

Treat Easytrieve diagnostics as the application transcript. Treat z/OS dumps as the machine room recording. A payroll programmer fixing invalid packed decimal data should live in SYSPRINT, the listing, and the Error Analysis report long before attempting low-level storage analysis. Conversely, repeated S0C4 failures with no clear Easytrieve message may need systems help even after you read SYSPRINT carefully.

What Enables Easytrieve Dump Output

Easytrieve does not silently produce an Error Analysis report on every failure. Broadcom ties that report to ABEXIT on the PARM statement used at compile or according to your installation's options table. ABEXIT SNAP asks for a dump in addition to the report. ABEXIT NOSNAP asks for the report without a dump. Test JCL commonly carries explicit DEBUG options; production may inherit defaults that are lighter for performance. Always compare test and production PARM behavior before copying a failing job's diagnostics expectations into a high-volume schedule.

1
2
3
4
5
6
7
8
9
PARM LINK(PAYAUD) ABEXIT(SNAP) DEBUG(STATE,FLOW) FLOWSIZ(20)
FILE PERSNL FB(150 1800)
  EMPNO    5  5  N
  GROSS   40  7  P 2
JOB INPUT PERSNL
  IF GROSS > LIMIT
     DISPLAY 'OVER LIMIT' EMPNO GROSS
  END-IF
  TOTAL = TOTAL + GROSS

In this pattern, ABEXIT SNAP enables Error Analysis and a dump request if the step terminates abnormally. DEBUG STATE records the current statement number at failure time. DEBUG FLOW keeps a rolling history of executed statement numbers; FLOWSIZ controls how many entries are retained. These options add runtime cost, which is acceptable in unit test but may be disabled after diagnosis is complete.

Reading the Error Analysis Report

When ABEXIT processing runs, the Error Analysis report is the structured centerpiece of Easytrieve dump analysis. It identifies the program name, describes the error that caused termination, and may reference statement numbers or flow information when DEBUG options were active. Read it immediately after checking whether the step abended and before editing source. Copy the program name, error text, and any statement numbers into your incident notes so comparisons across reruns stay factual.

Correlate statement numbers with the compile listing, not with your unexpanded source member line count if macros are involved. The listing shows the statement numbers Easytrieve executed. Search the listing for the reported number, then read the surrounding logic for file operations, arithmetic on packed fields, or report procedures that might fail only on certain input keys.

FLOW and EZABX016

When DEBUG FLOW is active, abend processing may list recently executed statement numbers, sometimes associated with message EZABX016 in Broadcom documentation. The newest entries appear first, giving you a short stack of where execution traveled before failure. FLOW is not a step-by-step trace of every field value; it is a map of statement numbers. Pair FLOW output with DISPLAY traces you may have coded to see both where execution went and what data looked like at key branches.

SYSPRINT: The Developer Transcript

Even without ABEXIT, SYSPRINT is the default transcript for runtime behavior. File open messages, record counts, report writer notices, sort diagnostics, and DISPLAY output appear there when JCL routes SYSPRINT to a spool class or data set. Many failures that feel like dump problems are visible as plain text on SYSPRINT: missing DD names, invalid DCB attributes, empty files treated as errors, or completion codes that do not match business expectations.

1
2
3
4
5
6
//AUDRUN   EXEC PGM=PAYAUD
//STEPLIB  DD  DSN=DEV.APP.LOADLIB,DISP=SHR
//         DD  DSN=DEV.EZT.CBAALOAD,DISP=SHR
//PERSNL   DD  DSN=DEV.HR.PERSONNEL.TEST,DISP=SHR
//SYSPRINT DD  SYSOUT=*
//AUDRPT   DD  SYSOUT=*

SYSPRINT DD SYSOUT=* routes diagnostics to the default output class. Keep diagnostic SYSOUT separate from business report DDs when possible so abend evidence is not buried inside a thousand-page report. If your shop purges spool quickly, capture SYSPRINT or the Error Analysis section before rerunning the job.

ABEXIT SNAP Dumps and Site Routing

ABEXIT SNAP requests a dump in addition to the Error Analysis report. Where that dump lands is not universal. Some sites write dump data sets referenced in the JCL, others rely on spool, vendor tools, or automated fault-management products. Dataset naming, authorization, and retention are site policies. This tutorial does not prescribe a single DD name or data set pattern because those details vary. Your run book should document the expected dump destination for Easytrieve test jobs and who may open it.

If you receive a dump data set you cannot open with familiar ISPF tools, stop and escalate. Raw dumps may require IPCS, vendor analyzers, or a support contract. Attempting to guess storage offsets without training risks incorrect conclusions. The Error Analysis report and compile listing solve most application defects without raw dump interpretation.

z/OS Abend Dumps: When They Appear

Severe errors—protection exceptions, some module resolution failures, region shortages—may produce z/OS messages and system dumps alongside Easytrieve output. JES messages and the job log show abend codes such as S0C7 or S0C4. Those codes describe the machine-level exception, while Easytrieve messages describe how the product surfaced the problem. For S0C7 in a packed decimal add, you may see both a data exception and an Easytrieve diagnostic referencing invalid numeric data. Record both the z/OS abend code and the Easytrieve text.

Do not conflate opening a system dump with completing Easytrieve dump analysis. Application developers typically finish their work once they identify the offending statement and input record pattern. Systems programmers use system dumps to investigate loader problems, authorized program facility issues, or repeated failures across unrelated applications. Know your site boundary.

Practical Analysis Workflow

1. Confirm which step failed and whether the step abended or merely ended with a non-zero return code.
2. Open JESJCL and allocation messages for DD, security, or STEPLIB problems that occur before Easytrieve logic.
3. Read SYSPRINT from the failing execute step top to bottom; note file open results and last DISPLAY traces.
4. Locate the Error Analysis report if ABEXIT was active; copy program name, error text, and statement references.
5. Open the compile listing for the same build; map statement numbers to source lines and data definitions.
6. Reproduce with a small test file, adding DISPLAY or DEBUG options only in non-production.
7. Escalate ABEXIT SNAP dumps or unclear system abends per site run-book contacts.

Common Beginner Mistakes

• Searching the business report DD for abend evidence while SYSPRINT holds the diagnostics.
• Assuming every job produces an Error Analysis report without ABEXIT or equivalent options.
• Editing source before mapping listing statement numbers, causing churn without evidence.
• Treating DISPLAY HEX output as a full substitute for ABEXIT dumps—they solve different inspection goals.
• Leaving DEBUG FLOW enabled in production after testing, adding cost and verbose flow tables.
• Confusing compile-time listing errors with execute-time dumps from a different job step.

DISPLAY and HEX During Dump Investigations

Before an abend occurs, DISPLAY statements are often the fastest way to capture intermediate values on SYSPRINT. After an abend, any DISPLAY output that printed before failure remains in the spool transcript. DISPLAY HEX helps inspect packed and binary fields when readable DISPLAY lines show garbage characters. That hexadecimal view is a field-level inspection technique, not the same as an ABEXIT SNAP storage dump. Use DISPLAY for targeted tracing; use ABEXIT and Error Analysis when you need product-level failure documentation.

1
2
3
4
IF INVALID-FLAG = 'Y'
   DISPLAY 'BAD RECORD' EMPNO
   DISPLAY HEX GROSS
END-IF

This pattern labels the logical problem, prints a readable key, and dumps the suspect packed field in hexadecimal. If the job later abends, SYSPRINT may contain these lines immediately above the Error Analysis report, giving you a before-and-after story without opening a raw dump.

Test vs Production Diagnostic Policy

Mature shops document which DEBUG and ABEXIT settings are allowed in each environment. Development and QA often run ABEXIT SNAP, DEBUG STATE, and limited FLOW sizes. Production frequently relies on ABEXIT NOSNAP or site defaults to avoid dump volume and CPU overhead. When promoting a program, verify that production JCL does not accidentally inherit test PARM options from a copied proc. Change-control reviewers should treat diagnostic PARM as sensitive configuration, not as comment text.

Explain It Like I'm Five

Imagine your Easytrieve program is a toy train on a track. When the train crashes, three adults might write notes. The train driver writes what the train was doing—that is SYSPRINT and DISPLAY messages. The Easytrieve safety officer writes a short report about which part broke—that is the Error Analysis report. The building manager might also take a big photograph of the whole room—that is a z/OS system dump. You fix the train by reading the driver's notes and the safety report first. You ask the building manager for help only when the crash is bigger than a broken wheel on one car.

Exercises

1. Write a PARM line with ABEXIT NOSNAP and DEBUG(STATE) and explain what each piece contributes to dump analysis.
2. List four artifacts you would collect after a failing execute step and the order you would read them.
3. Describe one scenario that is solved from SYSPRINT alone without opening any dump data set.
4. Explain the difference between DEBUG FLOW output and DISPLAY HEX for locating bad packed data.
5. Draft three sentences for a systems programmer escalation note when ABEXIT SNAP produced a dump you cannot interpret.

Exercise Answers

Exercise 1

ABEXIT NOSNAP requests the Error Analysis report without asking for a storage dump, which is often enough when SYSPRINT and the listing identify the defect. DEBUG STATE saves the statement number executing at failure time so abend messages can point to a specific line in the compile listing. Together they give structured failure text plus a statement anchor without the storage and routing overhead of SNAP.

Exercise 2

Start with JESJCL and step completion codes to confirm which step failed and whether allocation succeeded. Read SYSPRINT next for runtime messages and any DISPLAY traces. Open the Error Analysis report if present. Finally, use the compile listing from the same build to map statement numbers to source and field definitions. Only then consider ABEXIT SNAP dump data sets or z/OS dumps if policy and skill level allow.

Exercise 3

A missing DD statement for an input file produces allocation or open errors on SYSPRINT and in JES messages before meaningful record processing. The fix is JCL correction, not source changes. No dump interpretation is required because the failure is environmental.

Exercise 4

DEBUG FLOW shows which statement numbers executed recently, helping you narrow which section of logic was active. DISPLAY HEX shows the actual bytes of a field such as a packed decimal amount, helping you see corrupt data. FLOW answers where am I in the program; HEX answers what do the bytes look like for this field.

Exercise 5

Example escalation: Job PAYTEST on job ID JOB12345 abended in step AUDRUN with S0C7. SYSPRINT Error Analysis references statement 42; listing shows an add on packed field GROSS. ABEXIT SNAP produced dump data set DEV.PAY.DUMP.G00V001 which I cannot analyze with standard ISPF browse. Please advise whether this dump should be opened with IPCS or forwarded to vendor support.

Frequently Asked Questions