Easytrieve Cross-Reference Options

Cross-reference options control whether the compiler builds an alphabetical index of where each symbol is defined and referenced—a maintenance tool as valuable as ISPF search when you inherit a payroll program written decades ago. DEBUG XREF on PARM requests the section; DEBUG XREF LONG expands detail; NOXREF suppresses it when site defaults would otherwise print pages of indices. Configuration Manager Options Table XREF accepts L, S, or N values establishing installation baseline overridable per compile. Beginners confuse XREF with DMAP: DMAP answers byte offsets in records; XREF answers who uses the name NET-PAY across JOB, REPORT, and PROC sections. Duplicate field names between FILE and working storage, typos between EMPLNO and EMP-NO, dead DEFINE fields never referenced—all surface faster in XREF than manual scrolling. This page explains enabling XREF, LONG versus SHORT trade-offs, reading define and reference columns, workflow with compiler listings, pairing with LIST options, production listing diet, and migration when old Plus listings used different section headers.

Progress0 of 0 lessons

Enabling Cross-Reference

Primary control is PARM DEBUG clause. Typical development line includes XREF alongside DMAP and PMAP. Options Table XREF=L sets long form site-wide; individual program can shorten with DEBUG XREF SHORT or disable with DEBUG NOXREF when compiling stable modules in mass rebuild.

text
1
2
3
4
5
6
7
8
9
10
PARM DEBUG(PMAP DMAP XREF LONG) LIST FILE FILE PERSNL FB(80 800) EMP-NO 1 6 N NAME 7 20 A DEFINE TOT-GROSS W 7 P 2 JOB INPUT PERSNL TOT-GROSS = TOT-GROSS + GROSS

After compile, open XREF section—search EMP-NO, TOT-GROSS, PERSNL. Reference list shows statement numbers for JOB arithmetic, FILE definition, and any REPORT LINE usage.

Options Table XREF Values

Configuration Manager XREF (Compiler Options)
ValueMeaningPARM override
L (Long)Detailed cross-reference listingDEBUG XREF LONG or SHORT
S (Short)Abbreviated cross-referenceDEBUG XREF SHORT
N (None)No cross-reference unless PARM requestsDEBUG XREF

Reading the XREF Section

Symbols appear alphabetically. Each entry lists definition statement number—FILE DEFINE line or PROC label—and reference lines where compiler saw the name in expressions, IF tests, LINE lists, or SORT keys. Qualified names may show FILE:FIELD form when ambiguity exists. Statement numbers tie back to numbered column in statement listing—jump in ISPF with SEU or PDF editor using listing as map.

Maintenance Workflow Example

  1. Compile with DEBUG XREF LONG after checkout from source control.
  2. Locate field to rename in XREF definition line.
  3. Enumerate every reference statement number before editing.
  4. After rename, recompile and diff XREF—orphan old name should vanish.
  5. Run regression test on representative input.

XREF for Duplicate and Dead Symbol Detection

Duplicate names across FILE and W storage require qualification in logic—XREF reveals unqualified references that might bind wrong symbol. Fields defined but never referenced appear with definition only—candidates for cleanup though some DEFINE fields exist for future expansion or external copybook contract. REPORT-only fields used solely in LINE may show sparse reference list—normal.

XREF LONG Versus Listing Size

LONG multiplies pages on programs with thousands of symbols—macro-heavy libraries worst case. Nightly mass compile of unchanged sources may use NOXREF or site SHORT default. Active defect investigation on one member uses LONG for single compile cost acceptable.

XREF Versus Other Index Tools

ISPF search finds text but not semantic symbol table after macros expand differently than you expect. Compiler XREF reflects post-macro symbol universe for that compile. External repository cross-ref tools may lag if not rebuilt after compile—listing XREF is authoritative for that object version.

Common Cross-Reference Mistakes

  • Skipping XREF on inherited program before first change.
  • Assuming zero references means safe delete without macro side effects.
  • Using XREF instead of DMAP for offset bugs—different questions.
  • LONG XREF on every prod compile—spool and time waste.
  • Ignoring qualified versus unqualified entries in audit.
  • Comparing XREF from different compile dates after PARM change.

Explain It Like I'm Five

Cross-reference is the index at the back of a textbook telling every page where each character name appears. LONG index lists every mention in detail; SHORT index summarizes. If you skip the index, finding where NET-PAY is used means reading the whole book.

Exercises

  1. Compile sample program with DEBUG XREF LONG; locate three symbols.
  2. Explain Options Table XREF=N with PARM DEBUG XREF override.
  3. Find unreferenced DEFINE in XREF and document before deleting.
  4. Compare listing page count XREF LONG versus NOXREF.
  5. Trace qualified FILE:FIELD entry through statement listing numbers.

Quiz

Test Your Knowledge

1. DEBUG XREF on PARM requests:

  • A name cross-reference section in the compile listing
  • Runtime SORT of symbols
  • Automatic field renaming
  • Db2 catalog cross-reference

2. DEBUG XREF LONG compared to SHORT:

  • LONG expands cross-reference detail at cost of listing size
  • LONG disables XREF entirely
  • SHORT is invalid syntax
  • LONG affects BUFNO only

3. Options Table XREF setting:

  • Site default overridable by PARM DEBUG XREF
  • Runtime only—cannot override
  • JCL-only parameter
  • SCREEN map attribute

4. XREF helps find:

  • Where each field name is defined and referenced
  • JCL condition codes
  • CICS transaction id
  • Tape volume serial

5. NOXREF on PARM:

  • Suppresses cross-reference section when site default would print it
  • Deletes all fields
  • Prevents compilation
  • Turns off SYSDATE
Published
Read time14 min
AuthorMainframeMaster
Reviewed by MainframeMaster teamVerified: Broadcom Easytrieve 11.6 PARM DEBUG XREF; Compiler Options XREF L S NSources: Broadcom PARM Statement, Compiler Options, Controlling CompilationApplies to: Easytrieve cross-reference compile options