What is debugging in Easytrieve?

Systematically finding and fixing errors in Easytrieve programs—from compile failures in listings to wrong report totals at runtime. Tools include compiler listings, DISPLAY traces, dump analysis, and controlled test data.

Where do I start when a program fails compile?

Read the first error in the listing; if macros are involved, enable full expansion listing and check generated FILE/DEFINE lines. Fix source or macro library, then recompile.

Where do I start when batch output is wrong but compile succeeded?

Verify input file content and layout, add DISPLAY at suspect IF branches, compare control totals to expected, and narrow whether logic, data, or file definition is wrong.

What comes next in this section?

Compiler listings, tracing, dump analysis, DISPLAY for debugging, and test data pages—each deepens one debugging technique introduced here.

Easytrieve Debugging Overview - Listings, Traces, Dumps, and Test Strategy

Easytrieve Debugging Overview

Debugging Easytrieve programs means separating compile-time problems from runtime problems—and using the right artifact for each. A missing END-IF fails compile with a listing message pointing to statement number. Wrong DEPT totals may compile cleanly while reading bad offsets from an outdated macro expansion baked into the load module. Online SCREEN programs fail validation paths operators never exercise in batch testing. This section overview maps the debugging toolkit: compiler listings for syntax and macro expansion, tracing execution paths, DISPLAY for field snapshots, dump analysis when the region abends, and disciplined test data so you reproduce bugs in minutes not days. Beginners often change random logic when the FILE definition is wrong; systematic debugging verifies assumptions in order—compile clean, data correct, logic correct, environment correct. Use this page as the roadmap before diving into compiler listings, tracing, dump analysis, DISPLAY debugging, and test data tutorials.

Compile-Time Versus Runtime Errors

Two error worlds
Phase	Symptoms	Primary tool
Compile / preprocess	Non-zero compile RC, no load module	Compiler listing, macro expansion
Runtime batch	Abend, empty report, wrong totals	DISPLAY, dumps, output compare
Runtime online	Wrong screen, validation loops, terminal errors	Screen trace, AFTER-SCREEN DISPLAY, CICS diagnostics

Section Learning Path

Compiler listings — read error messages, statement numbers, macro expansion sections.
Tracing — follow execution without changing business logic permanently.
Dump analysis — interpret abend dumps when DISPLAY was not enough.
DISPLAY for debugging — inject temporary field visibility.
Test data — build minimal files that reproduce defects reliably.

Systematic Debug Workflow

Step 1 — Reproduce

Capture JCL, program source level, macro library level, and input record counts. Without reproduction, fixes are guesses.

Step 2 — Classify

Compile failure? Go to listing. Clean compile with wrong output? Suspect data, FILE layout, or logic order.

Step 3 — Narrow

Binary search the program: comment half the IF filters, run on tiny test file, see if error persists. Add DISPLAY at branch entry points.

Step 4 — Fix and regression

Apply minimal fix; rerun same test JCL; expand to integration test before production promote.

Step 5 — Remove temporary debug

Strip DISPLAY and trace hooks before production compile—leftover debug floods operations logs.

Common Failure Categories

What goes wrong
Category	Example	First check
Syntax	Missing END-IF	Listing error line
Macro expansion	Bad DEFINE after %PERSNL	Expansion listing
File layout	DEPT reads wrong columns	FILE offsets vs dictionary
Logic	Filter excludes all records	DISPLAY DEPT before IF
Data	Empty input file	IDCAMS/listcat or record count
JCL	Wrong DD pointing at old file	JCL listing and DISP

Batch Report Debugging Pattern

text

1
2
3
4
5
6
JOB INPUT PERSNL
  DISPLAY 'REC=' EMP# ' DEPT=' DEPT
  IF DEPT = 911
     DISPLAY 'SELECTED EMP=' EMP#
     PRINT PAY-RPT
  END-IF

Temporary DISPLAY lines show which records enter selection. Compare counts to expected. Remove DISPLAY after fix—see display-debugging page for options and output destinations.

Macro-Related Runtime Mysteries

Program compiled months ago; macro library changed yesterday; load module still has old expansion. Symptom looks like logic bug but is stale object module. Compare compile date of load to macro promotion date. Force recompile after library updates—tie to macro reuse governance from prior section.

Online SCREEN Debugging Notes

AFTER-SCREEN is natural place for DISPLAY of operator input fields. Pair with message field content and cursor position tutorials. Pseudo-conversational programs may need CICS trace alongside Easytrieve DISPLAY depending on deployment.

What Not To Do

Change multiple unrelated areas before rerunning test.
Debug against production master files without read-only safeguards.
Ignore first listing error and chase later cascading messages.
Leave DISPLAY in production source promoted under pressure.
Assume recompile happened because JCL reran—verify load module timestamp.

Tooling Ecosystem

Your shop may add Fault Analyzer, File Manager compare, or Easytrieve IDE breakpoints. This tutorial section focuses on facilities in every Easytrieve installation—listings, DISPLAY, dumps, test files—before optional vendor tools.

Relationship to Prior Sections

Macros section taught expansion listings—first macro debug skill. File processing tutorials explain EOF and file status—verify before blaming IF logic. Control flow pages map IF and PERFORM—DISPLAY at branch labels clarifies path taken. Compile process page orients where listing fits in build pipeline.

Explain It Like I'm Five

Debugging is finding why your toy train stopped. Compile errors mean you built the track wrong— read the instruction booklet (listing). Runtime errors mean the track is built but a bridge is missing—walk the train path (DISPLAY) and look where it falls off (dump). Test data is a small practice track before running the big layout.

Exercises

Classify five sample symptoms as compile or runtime.
Write a minimal test JCL outline for PERSNL filter program.
List checks you would run when report totals are zero.
Explain stale load module after macro change in your own words.
Order the five systematic debug workflow steps.

Quiz

Test Your Knowledge

1. Compile errors are fixed by:

Correcting source and recompiling
Restarting JCL only
Changing DD without recompile
PF key press

2. Runtime errors often need:

Listings plus dumps or DISPLAY trace output
Only the JCL catalog
Deleting the load module
Skipping JOB INPUT

3. DISPLAY statement during debugging:

Writes diagnostic values to listing or log output
Replaces FILE
Stops compile
Only works online

4. After macro library change, first debug step is often:

Review macro expansion in compile listing
Reboot LPAR
Change BLKSIZE randomly
Remove all IF statements

5. Good test data strategy includes:

Small controlled files with known expected output
Production files only
Empty files always
No documentation