Easytrieve Procedure Parameters

No Formal Parameter List on PROC

PROC opens a module; PERFORM invokes it. Neither statement carries a parenthetical field list in standard Easytrieve grammar. All Library DEFINE fields, FILE record fields, and working storage are visible inside every PROC in the same program. Parameters are therefore a design convention: document which fields the caller must populate before PERFORM and which fields the PROC updates before END-PROC. Teams sometimes prefix names IN- and OUT- or use a comment block above each PROC listing its contract.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
* Caller contract:
*   IN:  WORK-GROSS, WORK-STATE
*   OUT: WORK-TAX-AMT, WORK-ERROR-FLAG
 
MOVE GROSS-PAY TO WORK-GROSS
MOVE STATE-CODE TO WORK-STATE
PERFORM CALC-STATE-TAX
IF WORK-ERROR-FLAG EQ 'N'
   NET-PAY = GROSS-PAY - WORK-TAX-AMT
END-IF
 
CALC-STATE-TAX. PROC
   IF WORK-STATE EQ 'NY'
      WORK-TAX-AMT = WORK-GROSS * 0.08
      WORK-ERROR-FLAG = 'N'
   ELSE IF WORK-STATE EQ SPACES
      WORK-ERROR-FLAG = 'Y'
   ELSE
      WORK-TAX-AMT = WORK-GROSS * 0.05
      WORK-ERROR-FLAG = 'N'
   END-IF
END-PROC

Input Output Field Patterns

Before and After PERFORM Checklist

1. Initialize output fields or use consistent unknown sentinel before PERFORM when failure paths matter.
2. Set every input field the PROC documents—unset fields may hold prior record residue in JOB loops.
3. PERFORM the module once inputs stable.
4. After END-PROC, read output fields before overwriting input fields still needed for audit.
5. Branch on error flags before using numeric outputs that may be undefined on error paths.

Shared Storage and Side Effects

Because PROC does not isolate storage, every MOVE inside a module may change fields the caller did not list as outputs— accidental side effects. A CALC module that reuses WORK-GROSS for intermediate math clobbering the caller's gross value causes subtle bugs on the next IF. Prefer scratch names inside PROC for intermediates or save and restore critical caller fields at module start and end when wrapping legacy logic you cannot refactor immediately.

MACRO Parameters Versus PROC Parameters

MACRO prototypes declare positional and keyword parameters with ampersand substitution in the macro body. Invocation %MYMAC A B KEY=VAL expands at compile time—parameters become literal text in generated statements. Use macros when parameterization is about generating different field names, FILE layouts, or repeated DEFINE blocks. Use PROC when runtime logic executes with real data values in shared fields. A macro cannot replace PERFORM for iterative record processing; a PROC cannot generate ten field definitions from one template without repetitive source.

1
2
3
4
5
6
7
8
9
10
11
* MACRO compile-time parameter example (conceptual):
* MACRO 2 &FNAME &FLEN
* &FNAME &FLEN 1
* MEND
* %MYMAC EMP-NO 6  expands into field definition text
 
* PROC runtime — no & substitution:
PERFORM FORMAT-NAME
FORMAT-NAME. PROC
   OUT-NAME = IN-FIRST || ' ' || IN-LAST
END-PROC

CALL USING Versus PROC Shared Fields

CALL invokes external subprograms with explicit USING lists and optional RETURNS for numeric return codes. Linkage conventions pass addresses per COBOL, Assembler, or C rules documented in the CALL chapter. Use CALL when parameterized logic lives outside Easytrieve or must be binary-shared across languages. Thin PROC wrappers prepare USING fields from Easytrieve working storage, CALL the external module, map RETURNS into ERROR-FLAG, and END-PROC—giving callers a PERFORM interface around external parameters.

PARM and Job-Level Inputs

PARM supplies run-time job parameters—report dates, company id, test versus production flags— often parsed into fields at program start in START. PROC or implied JOB beginning. Those fields behave like global configuration parameters every module may read. They differ from per-invocation PERFORM parameters that change each record. Copy PARM-derived values into WORK fields when a PROC needs a stable snapshot unaffected by later PARM field overwrites in the same run.

Reusing One PROC With Different Inputs

The same CALC-DISCOUNT. PROC serves multiple PERFORM sites by setting DISC-TYPE before each call. First branch MOVE 'EMP' TO DISC-TYPE then PERFORM; second branch MOVE 'SEN' TO DISC-TYPE. The PROC reads DISC-TYPE as an input parameter field selecting logic inside one module instead of duplicating three nearly identical PROCs. Discipline matters: always set every input including mode switches before PERFORM; document allowed DISC-TYPE values in module header comments.

Documentation Standards for Teams

• Header comment block above each PROC: inputs, outputs, side effects, calling prerequisites.
• Prefix convention document in programming standards guide.
• Reject PROCs that modify FILE buffers unless documented—callers may not expect disk-oriented side effects.
• Code review checklist item: PERFORM sites set all inputs listed in PROC header.
• Unit test records in QA with boundary values for each input field documented.

Common Parameter Mistakes

• Expecting PERFORM USING syntax that does not exist in Easytrieve.
• Leaving input fields unset carrying values from previous JOB loop iteration.
• Reading output before checking ERROR-FLAG on validation PROCs.
• Using MACRO when runtime PERFORM with fields is simpler—or vice versa.
• PROC overwriting caller working fields used after return without documentation.
• Confusing PARM job parameters with per-call PERFORM field setup.

Explain It Like I'm Five

PROC does not have a list of labeled slots on the door. You put the ingredients on the shared counter with sticky notes saying input and output, tell the cook to start the recipe—PERFORM—and when they say done—END-PROC—you read the output sticky note. MACRO is like a copy machine that prints different recipe templates before cooking starts. CALL is asking a chef in another kitchen to cook using a tray you hand through the window—USING lists what is on the tray.

Exercises

1. Write a PROC header comment documenting three inputs and two outputs for a validation module.
2. Refactor two similar PROCs into one using a MODE input field set before PERFORM.
3. Compare one task solved with %MACRO versus PERFORM and list pros and cons.
4. Wrap CALL TAXCALC USING inside a PROC with PERFORM-friendly WORK input fields.
5. Trace a JOB loop bug where OUT-AMT was read without clearing ERROR-FLAG from prior record.