Easytrieve Debugging Options

Debugging options in Easytrieve live primarily on the PARM statement—the first line of source when present—and in site defaults from the Options Table. They split into two families beginners must not confuse: compile-time DEBUG flags that expand listings with maps and cross-references, and runtime ABEXIT and FLOW settings that change what happens when the program abends or when you need execution path visibility. A payroll developer fixing S0C7 packed decimal corruption wants DEBUG DMAP to verify field offsets in the listing and ABEXIT SNAP in test to inspect registers at failure. The same developer promoting to nightly production removes SNAP and often FLOW to avoid dump allocation and CPU overhead. Broadcom best practices and support article 55089 document combinations Technical Support requests when you open a case. This page explains each DEBUG subparameter, ABEXIT SNAP versus NOSNAP versus NO, FLOWSIZ table sizing, FLDCHK field checking, interaction with DISPLAY and tracing, development versus production policy, and how debugging options connect to compiler listings and dump analysis workflows.

Progress0 of 0 lessons

PARM DEBUG Subparameters

DEBUG groups optional diagnostic sections into the compile listing and enables runtime facilities. Each subparameter can often be negated with NO prefix—NODMAP suppresses data map when site default would otherwise print it. Override site Options Table values per program by coding PARM first in source.

DEBUG subparameters (Broadcom 11.6)
OptionCompile effectRuntime effect
PMAP / NOPMAPProgram map listingStructure reference for maintainers
DMAP / NODMAPData map—offsets, types, filesValidates DEFINE layout assumptions
XREF / NOXREFSymbol cross-referenceIndirect—finds bad references at compile
STATE / NOSTATEState-related compile supportStatement number at abend
FLOW / NOFLOWFlow table setupRecent stmt numbers on failure
FLDCHK / NOFLDCHKExtra field checkingCatches some invalid references earlier

Recommended Development PARM

Broadcom best practices and support guidance converge on a verbose test compile while troubleshooting. LIST ON MACROS preserves macro expansion visibility. DEBUG with PMAP, DMAP, STATE, and XREF LONG maximizes listing utility. ABEXIT NO avoids snap dump volume when you are fixing source logic rather than analyzing bad data at failure instant. SORT(MSG(ALL)) surfaces sort diagnostics. LIST FILE routes listing sections appropriately on releases that support it.

text
1
2
3
LIST ON MACROS PARM DEBUG(PMAP DMAP STATE XREF LONG) ABEXIT NO SORT(MSG(ALL)) + LIST FILE

ABEXIT: SNAP, NOSNAP, and NO

ABEXIT controls abnormal termination processing at execution time—not compile time. SNAP produces formatted dump output useful when a data exception leaves you asking which packed field was invalid. NOSNAP still handles abend but suppresses snap formatting per manual rules. NO minimizes abexit intervention—Broadcom suggests NO when debugging source logic problems rather than inspecting failure-time data. Production schedules often inherit ABEXIT NO from Options Table to prevent accidental dump storms on recurring batch.

When to Use SNAP in Test

Reproduce S0C7 or similar with minimal input file. Compile with ABEXIT SNAP. Compare dump registers and flow output with DMAP offsets for suspect arithmetic fields. Once root cause fixed, recompile with production ABEXIT before promotion sign-off.

DEBUG FLOW and FLOWSIZ

FLOW maintains rolling statement number history. When abend processing runs, flow tables help narrow which section executed recently—valuable in large programs with many PROC copies. FLOWSIZ sets table entry count—larger tables consume memory but retain longer history. Balance FLOWSIZ against REGION and below-the-line storage on AMODE31 programs with many buffered files.

text
1
PARM LINK(PAYAUD) ABEXIT(SNAP) DEBUG(STATE,FLOW) FLOWSIZ(20)

DEBUG Versus DISPLAY Versus Tracing

DEBUG options are product-controlled diagnostics tied to compile and abend infrastructure. DISPLAY is explicit application logging you write. Tracing DD dummies and external tools (Abend-Aid, Fault Analyzer) sit outside PARM—coordinate so multiple dumps do not fire on same failure. Best practices list DD DUMMY examples to disable competing products during Easytrieve-native debug sessions.

Options Table Defaults

Configuration Manager sets compile-time defaults for DMAP, XREF, PMAP, and related listing flags. PARM on individual programs overrides for one compile. Document which defaults your shop uses in development versus production compile procs so contractors do not accidentally ship DEBUG FLOW load modules to production JCL.

Production Hardening Checklist

  1. Remove or reduce DEBUG FLOW and STATE if not required operationally.
  2. Set ABEXIT NO or site production default—avoid SNAP on high-volume jobs.
  3. Compare compile summary options against approved baseline proc.
  4. Retain listing archive for module version tied to load library member.
  5. Verify external dump tools DD disposition matches production policy.

Common Debugging Option Mistakes

  • Leaving SNAP enabled on hourly production batch.
  • Requesting DMAP but never opening data map section of listing.
  • Confusing DEBUG XREF compile listing with runtime SYSPRINT.
  • PARM not first statement—options ignored or compile error.
  • FLOWSIZ huge on memory-constrained REGION jobs.
  • Uploading listing to support without LIST ON MACROS when macros involved.

Explain It Like I'm Five

Debugging options are extra pages the compiler adds to your instruction manual and extra helpers that turn on when the program crashes. DMAP draws a picture of where each box of data sits. FLOW remembers which lines you recently ran. SNAP takes a photo when something breaks badly. For real homework turned in every night you use a thin manual without photos; while fixing mistakes you ask for all the extra pages.

Exercises

  1. Write development PARM with DEBUG DMAP and explain what DMAP shows.
  2. Compare ABEXIT SNAP versus NO for a logic bug versus S0C7.
  3. Set FLOWSIZ(10) and describe trade-off versus FLOWSIZ(50).
  4. List five DEBUG subparameters and whether they affect compile or runtime.
  5. Draft production PARM stripping debug overhead from development example.

Quiz

Test Your Knowledge

1. PARM DEBUG DMAP requests:

  • A data map listing of field layouts
  • Deletion of master files
  • Automatic SORT
  • CICS trace

2. DEBUG FLOW helps debugging by:

  • Maintaining a table of recently executed statement numbers
  • Formatting report titles
  • Allocating VSAM buffers
  • Binding Db2 plans

3. ABEXIT SNAP is best suited for:

  • Data exception abends like S0C7 where dump context helps
  • Every production payroll run
  • Suppressing all diagnostics
  • Macro expansion only

4. DEBUG STATE records:

  • Current statement number at failure time
  • Only JCL job name
  • FILE BLKSIZE
  • Sort work dataset names

5. Development debug PARM should be removed or reduced:

  • Before production scheduling due to runtime overhead
  • Never—always use full DEBUG in prod
  • Only when using VSAM
  • When compiling with SYNTAX only
Published
Read time16 min
AuthorMainframeMaster
Reviewed by MainframeMaster teamVerified: Broadcom Easytrieve 11.6 PARM DEBUG ABEXIT; Knowledge Article 55089Sources: Broadcom PARM Statement, Using Best Practices, Controlling CompilationApplies to: Easytrieve debugging compiler and runtime options