Easytrieve Variable Lifetime

Program Run Lifetime

When the Easytrieve step starts, the runtime allocates working storage defined in the library and prepares file buffers. Those allocations last until the step ends. Separate batch executions are separate lifetimes—even the same source member re-run starts fresh unless you read persisted totals from datasets. JCL symbols and PARM values exist only for that step invocation.

FILE Variable Lifetime: One Record at a Time

FILE fields are views into the current record buffer. Their values are meaningful for the record currently loaded. JOB INPUT PERSNL reads repeatedly; each iteration replaces NAME, GROSS, and every other FILE column with new bytes. The previous record values are gone unless you copied them to working storage first. OUTPUT FILE fields live until you PUT or WRITE the record—then the buffer may be reused for the next output row.

1
2
3
4
5
6
7
8
9
10
11
12
FILE PERSNL FB(150 1800)
NAME  17 20 A
GROSS 94  4 P 2
 
DEFINE SAVE-NAME W 20 A
 
JOB INPUT PERSNL
  SAVE-NAME = NAME
  IF GROSS GT 100000
     DISPLAY SAVE-NAME GROSS
  END-IF
END-JOB

SAVE-NAME outlives the current PERSNL record because working storage persists across reads within the JOB. NAME alone would change on the next automatic read.

W Working Storage Lifetime and RESET

W fields exist for the program run but their values may reinitialize at activity starts when RESET is coded. DEFINE LINE-CNT W 5 N RESET VALUE 0 begins each JOB with zero. Without RESET, LINE-CNT would keep counting across JOB boundaries—sometimes desired for grand totals, often a bug for per-job statistics.

S Static Storage Lifetime Through Reports

S fields persist in static storage for the run. Broadcom documents that S values remain available when the report formatter runs—after PRINT may have snapshotted W fields to work files. If you increment RUN-TOTAL in an S field during JOB processing, the report PROC reading RUN-TOTAL sees the latest value at format time. If you used W for RUN-TOTAL and changed it after PRINT, printed totals can disagree with final S-style expectations.

1
2
3
4
5
6
7
8
9
DEFINE RUN-TOTAL S 9 P 2
DEFINE SNAP-TOT W 9 P 2 RESET VALUE 0
 
JOB INPUT PERSNL
  RUN-TOTAL = RUN-TOTAL + GROSS
  SNAP-TOT = RUN-TOT
  PRINT REPORT-A
  RUN-TOTAL = RUN-TOTAL + 1000
END-JOB

This exaggerated pattern shows timing risk: SNAP-TOT at PRINT may not include the post-PRINT adjustment to RUN-TOTAL on the report if W spooling froze an earlier value. Prefer S for totals referenced during report formatting.

VALUE Initialization Lifetime

VALUE on DEFINE sets the first content when storage is allocated and whenever RESET reloads W fields. It does not re-apply on every FILE read. Numeric W and S without VALUE start at zero; alphabetic at blanks. VALUE literals must fit field length and type rules.

Activity-Local DEFINE Lifetime

Fields defined inside a JOB activity enter the dictionary when compiled and exist for the program run, but you should only reference them within intended activities. TEMP-HOLD defined in JOB A is still allocated during JOB B even if unused—wasting little storage but confusing maintainers. Prefer library DEFINE for true shared lifetime; activity DEFINE for scratch with clear single-JOB intent.

PROC and PERFORM Lifetime

PERFORM does not create new variable lifetimes. CALC-NET mutates the same WS-NET field whether called once or fifty times per record. Loop counters in W fields accumulate within the JOB until RESET or reassignment. Stack-like local lifetimes do not exist—document which PROCs clear scratch fields before return.

Report System Field Lifetime

LEVEL, BREAK-LEVEL, TALLY, and related report system fields are meaningful during report processing windows—control breaks, line printing, page overflow. Their values are not reliable lifetime markers in arbitrary batch logic between PRINT calls. FIRST-DETAIL and POST-BREAK conditions tie to detail line lifetime within a report exit PROC.

SQL Host Variable Lifetime

Host variables hold one row result after FETCH or SELECT INTO until the next SQL operation overwrites them. NULL indicators share that row lifetime—test NULL before using values in assignment that outlives the FETCH. Cursors define fetch loops where host fields refresh each iteration.

1
2
3
4
5
6
7
8
JOB SQL INPUT
  SELECT NAME SALARY INTO :EMP-NAME :EMP-SAL
  FROM PAYROLL WHERE DEPT = '100'
  IF EMP-SAL NULL
     EMP-SAL = 0
  END-IF
  DISPLAY EMP-NAME EMP-SAL
END-JOB

Overlay Lifetime

Overlays share parent lifetime. When the parent FILE buffer reloads, every overlay view changes simultaneously. Saving overlay bytes to W fields extends their meaningful lifetime beyond one record the same way as parent fields.

Cross-JOB Totals: Intentional vs Accidental

Library S totals without RESET accumulate across JOB activities for the entire step. Per-job totals should use RESET W fields or explicit zero assignment at JOB start. Writing totals to output files extends lifetime beyond the step when downstream jobs read them—classic batch persistence pattern.

Comparison: W vs S vs FILE Lifetime

Common Lifetime Mistakes

1. Using FILE field after read loop ends expecting last record without saving.
2. Per-job counter without RESET on W field.
3. Post-PRINT changes to W fields used on the report.
4. Assuming VALUE re-applies each input record on FILE fields.
5. SQL host variable used after next FETCH without copying.
6. Grand total in W with SORT reordering report work files.

Explain It Like I'm Five

Lifetime is how long a sticker on a box stays true. FILE stickers change every time a new card is read. WORK stickers with RESET get wiped and rewritten at the start of each new game (JOB). WORK stickers without RESET keep adding up. S stickers stay on the shelf until you change them—and the report reader looks at S stickers when printing, not old copies of W stickers you already mailed away at PRINT time.

Exercises

1. Trace LINE-CNT with RESET across two JOB activities.
2. Save NAME to W before next READ; explain why DISPLAY needs SAVE-NAME.
3. Design per-job and run-total fields using W RESET versus S.
4. Document when RUN-TOTAL must be S for report PROC accuracy.
5. Write SQL loop copying host salary to W before next FETCH.