Easytrieve lets analysts produce reports quickly—but speed without discipline creates portfolios nobody wants to inherit. Best practices are the habits that keep FILE definitions consistent, procedures reusable, compile promotion auditable, and month-end jobs predictable. This overview maps the best-practices section for beginners and team leads: naming, formatting, comments, modular design, performance, maintainability, and coding standards. Each child page goes deep on one topic; here you learn how they fit together and why mainframe shops with twenty years of Easytrieve still write standards documents. Treat this as the table of contents for professional Easytrieve work, not optional style advice.
Easytrieve programs are often shorter than COBOL equivalents, which tempts teams to skip standards. The cost appears later: a payroll field moves three bytes in the physical file, and seventy programs with copied FILE blocks need seventy edits. A new reserved word collides with a cryptic field name AMOUNT in one job while AMT-GROSS in another passes compile. Best practices front-load small costs—prefixes, macros, comments—to avoid portfolio-scale fire drills. Auditors and regulators also ask who compiled what, from which source member, with which PARM—practices around promotion and documentation answer those questions without heroics.
| Area | Focus | Deep dive |
|---|---|---|
| Naming standards | Field, file, report, and PROC identifiers | best-practices/naming |
| Formatting standards | Columns, indentation, continuation | best-practices/formatting |
| Comments | Intent, change history, caveats | best-practices/comments |
| Modular design | Macros, PROCs, shared libraries | best-practices/modular-design |
| Performance | I/O, SORT, buffers, large files | best-practices/performance |
| Maintainability | Readability, testing, ownership | best-practices/maintainability |
| Coding standards | Site-wide rules and enforcement | best-practices/coding-standards |
The single highest-leverage practice is centralizing FILE and field definitions in macros maintained by a data dictionary owner. Application programs %INCLUDE or macro-expand standard layouts—PAYROLL, CUSTOMER, GL-BALANCE—instead of retyping column positions. When upstream changes LRECL, one macro update propagates on recompile. Pair macros with naming standards so every field in PAYROLL-MACRO uses the same prefixes as reports that reference those fields. Modular design page expands macro library layout and change control.
1234567%INCLUDE PAYROLL-FILE-MAC * Shared macro — do not duplicate FILE block in application source JOB INPUT PAYROLL IF DEPT EQ 911 PRINT DEPT-RPT END-IF
Development uses personal libraries, verbose DEBUG PARM, and compile-and-go for speed. Production uses approved procs, production source PDS members, standard PARM (LIST FILE without DEBUG), and link-edited load modules stored in program libraries. Never schedule compile-and-go in production batch—SYSPRINT from ad hoc sessions is not reproducible under audit. Tag load modules with compile date and compiler level in your CMDB or change ticket.
Easytrieve divides source into Library (FILE, DEFINE, REPORT layouts) and Activity (JOB, SCREEN, SORT) sections. Best practices keep that separation visible: FILE definitions together at top, REPORT definitions before activities that PRINT them, procedures grouped by purpose. Formatting standards specify indentation for nested IF and for continuation lines in long TITLE statements. Comments explain why a filter exists, not what IF DEPT EQ 911 literally does—reviewers already read Easytrieve.
These three practices reinforce each other. A field named WS-INPUT-GROSS-PAY with a comment referencing ticket PAY-4402 survives staff turnover. ALLCAPS one-letter names do not. Formatting that aligns FILE field start positions in columns makes diff tools useful during macro review. Comments that document assumed sort order prevent someone from removing SORT thinking it redundant. Child pages in this section provide tables of recommended prefixes, anti-patterns, and examples aligned with Broadcom Language Reference identifier rules.
Modular design covers macros, nested PROCs, and callable routines. Design patterns (later tutorial section) show how to assemble modules into validation frameworks or reusable report shells. Best practices say share logic; patterns show proven shapes. A validation PROC invoked from BEFORE-SCREEN and batch JOB alike embodies both. Avoid copy-pasting fifty-line IF ladders—extract to named PROC with parameters documented in comments.
Performance best practices are pragmatic: use indexed access when doing keyed lookups, avoid sorting multi-gigabyte files internally when external SORT with appropriate DYNALLOC is cheaper, set BUFNO based on measurement not superstition, and do not DISPLAY every record in production. Read the performance tutorial section for CPU, I/O, and sort tuning. Best practice is to baseline elapsed time and EXCP counts before tuning—otherwise you optimize the wrong job.
Every production program needs an owner in the CMDB, a last-verified date after compiler upgrades, and a test dataset reference. Maintainability practices include small programs that do one report well, avoiding Swiss-army JOB activities that READ twelve files when three smaller jobs would schedule independently. When business rules complexify, prefer explicit CASE or structured IF with comments over opaque GOTO chains—Easytrieve supports structured flow; use it.
The coding standards page consolidates rules into a checklist enforceable in code review: reserved word scan before check-in, mandatory macro for FILE, maximum procedure depth, forbidden GOTO to unstructured labels in new code. Standards should reference Broadcom documentation, not reinvent language semantics. New hires read standards first; veterans cite exceptions through change control, not silently in production.
Best practices are the rules that help everyone build with the same Lego pieces the same way. If every builder uses different names for red blocks, nobody can share instructions. If instructions are messy, the next builder cannot fix the castle. Macros are shared instruction booklets; comments are sticky notes saying why a wall is short. Following the rules makes fixing and upgrading the castle possible when you are not the one who built it.
1. The highest-impact Easytrieve maintainability practice for large shops is usually:
2. Production Easytrieve programs should typically be promoted as:
3. Naming standards in Easytrieve help primarily by:
4. Formatting standards matter because Easytrieve:
5. Performance best practices in Easytrieve often start with: