Easytrieve Formatting Standards

Library Versus Activity Layout

The Library section describes data and reports: PARM if present, FILE, DEFINE, REPORT blocks. The Activity section executes: JOB INPUT loops, SCREEN activities, SORT, procedures invoked by name. Standards require Library first, Activity second, with banner comments separating them. Some shops insert a column of asterisks for visual break. Mixed order—JOB before FILE—confuses newcomers and breaks macro expansion expectations when macros assume FILE precedes JOB.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
***********************************************************************
* LIBRARY SECTION
***********************************************************************
FILE PAYROLL FB(150 1800)
  EMPNAME  17  8  A
  DEPT     98  3  N
 
REPORT PAY-RPT LINESIZE 80
  TITLE 01 'PAYROLL BY DEPT'
  LINE 01 DEPT EMPNAME
 
***********************************************************************
* ACTIVITY SECTION
***********************************************************************
JOB INPUT PAYROLL
  PRINT PAY-RPT

FILE Definition Columns

Align field name, starting position, length, and type in fixed columns so reviewers scan vertically. A one-byte start position typo is obvious when 98 and 99 sit in the same column for adjacent fields. Type codes (A, N, P, U, B) and decimal places for packed fields deserve their own column. FILE statement parameters (FB, VB, VSAM organization) stay on the FILE line; continuations indent two spaces under FILE when needed.

DEFINE Block Formatting

Group DEFINE statements after FILE blocks they depend on, or in a dedicated working-storage subsection. One DEFINE per line unless small related flags share a comment block. Initialize VALUE on the same line when static; put complex VALUE expressions on continuation lines indented. RESET fields used in SCREEN activities should be grouped with a comment noting SCREEN behavior.

REPORT Block Formatting

REPORT name and options on the first line (LINESIZE, LINES, CONTROL). TITLE and LINE statements indent two spaces under REPORT; multiple TITLE lines use consistent line numbers (01, 02). Field lists on LINE statements align with spaces or tabs so adding a column is a clean diff. FOOTING and CONTROL BREAK lines follow the same indent as LINE. When reports span many lines, sub-comment headers group control breaks versus detail lines.

Activity and JOB Formatting

JOB INPUT file name on its own line; body statements indent two spaces. Nested IF adds two spaces per level. END-IF aligns with its IF or with body standard—pick one rule site-wide. PRINT, SORT, and CALL at the same indent level within a JOB block unless nested in IF. Blank line between logical groups (validation block, print block) improves readability without affecting compile.

1
2
3
4
5
6
7
JOB INPUT PAYROLL
  IF DEPT EQ 911
     IF PAY-GROSS GT 0
        ADD PAY-GROSS WS-TOT-GROSS
        PRINT PAY-RPT
     END-IF
  END-IF

PROC and END-PROC

PROC name on column 1 or with standard label indent; END-PROC matches. Procedure body indents like JOB body. Special-name procedures (BEFORE-LINE. PROC) use documented spelling with period where required. Avoid trailing spaces on PROC lines—some editors show them as noise in diffs.

Comments and Blank Lines

Full-line comments use * or slash-star per shop rule in column 1. End-of-line comments align after code when short; move long explanations to full-line comments above the statement. Use blank lines sparingly between major sections—not after every LINE. Comment banners for change tickets (CHG12345) go above the changed IF block, not only in header—listings then show context in excerpts.

Continuation Lines

Long PARM, TITLE, or FILE statements continue on following lines according to Language Reference—often leading spaces and a continuation marker or implicit continuation when string literals break. Standards document the approved pattern for your release. Never break a quoted string mid-word without knowing continuation rules; compile errors from broken literals waste review cycles. For long string titles, prefer multiple TITLE lines instead of one unmaintainable row.

PARM Line Formatting

PARM at top of Library when program-specific; site defaults live in options table. Break DEBUG options on continuations with aligned parentheses—DEBUG(PMAP DMAP XREF) is easier to toggle than one long line. Comment out development PARM with star prefix rather than deleting—shows promotion path to production PARM.

Macro Source Formatting

Macros should be formatted as if they were main program Library sections—future readers expand macros mentally. Macro header comment block includes author, date, field layout version, and upstream copybook reference. Parameters in MACRO statement documented on following lines. Poorly formatted macros multiply confusion across every dependent program.

Listing-Friendly Layout

Compile listings interleave line numbers and diagnostics. Source without trailing garbage and with consistent margins prints cleanly on SYSPRINT. Some teams limit line length to 72 or 80 so side-by-side listing compare tools align. When errors reference line numbers, matching editor line numbers to listing saves hours—avoid reformatting that shuffles lines without functional need right before cutover.

Formatting Anti-Patterns

• Random indentation that hides END-IF pairing.
• FILE fields not aligned—position errors hide in noise.
• Activity before Library definitions.
• Trailing spaces causing false diffs in Git.
• Mixing tab widths between developers.
• One-line REPORT with ten TITLE clauses—unmaintainable.

Explain It Like I'm Five

Formatting is making your homework neat so the teacher can grade it. If all the numbers line up in columns, the teacher spots a wrong number fast. If your IF boxes are indented like stairs, you see which END-IF closes which IF. Messy homework is still homework—but nobody wants to fix it at bedtime.

Exercises

1. Reformat a scrambled FILE block using the column grid.
2. Add Library/Activity banner comments to a sample program.
3. Indent a three-level IF nest consistently.
4. Split an overlong TITLE into two TITLE lines.
5. List three formatting rules you would enforce in code review.