Easytrieve Variable Memory

Three Storage Regions

Static S Storage

S fields allocate in static working storage when the program loads. GRAND-TOT S 9 P 2 occupies packed decimal bytes for the entire step regardless of how many JOB activities execute. Assignments update those bytes in place. Report formatting reads S fields directly from static storage when LINE or SUM references them, so totals that accumulate in S during JOB processing match what the report writer sees at format time—assuming you understand when PRINT fires relative to your assignments. Use S for program totals, control-break accumulators referenced from report PROCs, and values that must stay coherent across spooled report phases.

1
2
3
4
5
6
DEFINE GRAND-GROSS S 11 P 2
 
JOB INPUT PAYROLL
  GRAND-GROSS = GRAND-GROSS + GROSS
  PRINT PAY-RPT
END-JOB

Non-Static W Storage

W fields allocate in non-static working storage. During ordinary batch JOB logic, W behaves like S—you assign and read the same bytes. The divergence appears when variables participate in report processing. Broadcom states W fields copy to report work files when PRINT selects records. Later changes to W in JOB logic may not match bytes already captured for spooled report formatting, while S updates remain visible. Sequenced reports that spool work files before final printing amplify this timing gap. Beginners building scratch calculations on the same PRINT line should prefer S when the report must see live totals, or design JOB order so W assignments complete before PRINT captures them.

1
2
3
4
5
6
7
8
9
10
DEFINE SCRATCH-W W 7 P 2
DEFINE SCRATCH-S S 7 P 2
 
JOB INPUT FILE1
  SCRATCH-W = GROSS * 0.10
  SCRATCH-S = GROSS * 0.10
  PRINT TAX-RPT
  SCRATCH-W = SCRATCH-W + 1
  SCRATCH-S = SCRATCH-S + 1
END-JOB

Understand which field the report writer read at PRINT versus what DISPLAY after PRINT shows—W snapshot timing may differ from S live value depending on report options and sequencing.

FILE Record Buffers

Each FILE definition owns a record buffer sized to the file record length in your declaration. Field lines NAME 17 20 A and GROSS 94 4 P 2 are offsets into that buffer—not separate heap objects. READ loads dataset bytes into the buffer; assignment to GROSS changes those buffer bytes before PUT on output files. Multiple FILE definitions mean multiple buffers. When JOB logic activates more than one file, qualify references: PERSNL:GROSS versus BONUS:GROSS. Unqualified GROSS resolves using current file context from the last FILE statement or automatic rules—ambiguous names are compile or runtime errors depending on situation.

1
2
3
4
5
6
7
8
9
10
11
FILE PERSNL FB(150 1800)
NAME  17 20 A
GROSS 94  4 P 2
 
FILE BONUS FB(80 800)
NAME   1 20 A
AMOUNT 21  5 P 2
 
JOB INPUT PERSNL
  DISPLAY PERSNL:NAME PERSNL:GROSS
END-JOB

Overlays Share Parent Bytes

Overlay definitions place a second name on a byte range inside a parent field. DATE-OF-HIRE 45 8 A with HIRE-MM on DATE-OF-HIRE 1 2 A maps HIRE-MM to the first two bytes of the eight-byte parent. Assigning HIRE-MM = 03 changes parent bytes; MOVE SPACE TO DATE-OF-HIRE clears HIRE-MM as well. Overlays do not receive separate W or S allocation. RESET on overlay fields is invalid. Memory planning must treat overlay groups as one unit when initializing or validating content.

1
2
3
4
5
6
7
8
DATE-OF-HIRE  45  8 A
HIRE-MM       ON DATE-OF-HIRE  1  2 A
HIRE-DD       ON DATE-OF-HIRE  3  2 A
HIRE-YY       ON DATE-OF-HIRE  5  4 A
 
HIRE-MM = 06
HIRE-DD = 15
HIRE-YY = 2024

OCCURS and Array Layout

OCCURS on W or FILE fields repeats a substructure contiguously in memory. TABLE-ENTRY W 10 A OCCURS 12 allocates twelve consecutive ten-byte elements in working storage order. Subscripts select which element—you are addressing offset math within one allocation block. Changing element 3 affects adjacent layout only within that element bytes, not other variables elsewhere in the dictionary unless your subscript is wrong and stomps adjacent memory through length mistakes—a rare but severe bug when element length declarations disagree with usage.

Activity DEFINE and Memory

DEFINE inside JOB adds entries to the same program dictionary and allocates working storage according to W rules. Memory is not stack-scoped like C locals—the bytes persist for the program run unless RESET clears W fields at the next activity boundary. Activity DEFINE is about visibility ordering in source, not a separate memory heap per JOB.

PROC Memory Model

PERFORM CALC-NET does not push a stack frame with private variables. The PROC reads and writes the same S, W, and FILE buffers visible to the caller. Shop convention uses WS-IN and WS-OUT working storage names as implicit parameters. Two concurrent PERFORM paths are not possible in classic batch—sequential PERFORM means no re-entrancy concern—but nested PERFORM must still avoid clobbering the same scratch W names without saving/restoring in disciplined patterns.

Report SUMFILE and Control Field Memory

Control fields and totals in report processing may reference SUMFILE data—Broadcom uses internal summary file buffers so CONTROL break totals match printed reports. LEVEL and BREAK-LEVEL system fields reflect report writer state, not arbitrary FILE buffer bytes. Memory for report control is managed by the report subsystem; beginners should not assume those names map to DEFINE storage you allocated manually.

Program Boundary and Persistence

All S, W, and FILE buffer allocations last for one execution of the compiled Easytrieve program step. When the step ends, memory is released. The next JCL job step—even the same source re-run—starts fresh unless you persisted values to a dataset or VSAM file. Cross-step memory sharing does not exist. Long-running online regions follow product rules for SCREEN activities but still respect program load boundaries per session documentation for your release.

Memory and Data Types

Type codes affect how many bytes a name covers and how assignment moves data—packed P versus zoned N versus alphabetic A—but do not change which region owns the bytes. Binary B fields occupy two or four bytes typically; floating U and I use longer representations. Assigning a zoned value into a packed field triggers conversion rules that rewrite the same memory location with different encoding. See data type pages for encoding; this page focuses on which pool holds the bytes.

Debugging Memory Misunderstandings

1. DISPLAY HEX on suspect field after READ to see raw buffer bytes.
2. Qualify FILE names when multiple buffers are active.
3. Compare W versus S behavior on a one-record test report with PRINT.
4. Trace overlay assignments through parent field DISPLAY.
5. Enable FLDCHK in test PARM to catch invalid numeric buffer patterns.

Common Memory Mistakes

• Treating overlay subfields as independent storage.
• Using W scratch in sequenced report without understanding PRINT snapshot.
• Assuming PROC has private memory for scratch names.
• Unqualified field name after switching FILE context.
• Expecting memory to survive across separate JCL steps without files.
• RESET on overlay—invalid and confusing when attempted.

Explain It Like I'm Five

Memory is the actual box where your toy lives. S boxes sit on a shelf that stays until the party ends. W boxes get their picture taken when you print a report page—if you change the toy after the picture, the printed page might still show the old toy. File boxes are delivery crates—each file has its own crate, and reading loads toys from the truck into that crate. Overlay names are sticky labels on one section of a bigger toy—coloring one label area changes the whole toy section underneath.

Exercises

1. Draw a byte map for an eight-byte date field with three overlays.
2. Explain why GRAND-TOT S is preferred over SCRATCH W for report totals.
3. Write two-FILE JOB with qualified NAME references.
4. Describe what happens to W bytes at PRINT versus S bytes.
5. List storage regions that survive from JOB1 to JOB2 in one program run.