What are Easytrieve coding standards?

Written team rules for naming, layout, comments, error handling, macro usage, and compile promotion that sit on top of Broadcom language syntax—so every program in an application area looks like one team wrote it.

How are coding standards different from formatting standards?

Formatting covers indentation, column alignment, and spacing. Coding standards include formatting plus naming, structure, FILE conventions, review gates, and prohibited patterns—a broader quality contract.

Should standards forbid GOTO entirely?

Many sites restrict unstructured GOTO while allowing labeled exits and documented flow. Standards should match maintainability goals, not ideology—document allowed patterns.

Who owns the standards document?

Typically a lead developer or architecture guild with input from operations and audit. Easytrieve chapters should link to Broadcom manuals for syntax authority.

Easytrieve Coding Standards - Site Rules, Quality Gates, and Team Conventions

Easytrieve Coding Standards

Coding standards are the written rules your organization adds on top of Broadcom's language syntax so every Easytrieve program reads like it came from one disciplined team. Two developers can both write valid JOB and REPORT code that compiles yet one uses cryptic field names, scatters FILE definitions, and ships DEBUG options to production while the other follows site conventions reviewers expect. Standards cover naming, formatting, comments, error handling, macro and PROC patterns, compile procedures, and promotion checklists. They speed code review in Endevor, reduce audit findings, and shorten on-call diagnosis when incidents span dozens of payroll and finance report programs. This page helps beginners understand why enterprises publish Easytrieve standards manuals, what typical rules contain, how standards connect to naming and formatting tutorials in this section, and how to apply a review checklist before your first production promotion.

Standards Versus Language Rules

Broadcom defines what is syntactically legal: PROC must end with END-PROC, reserved words cannot be field names, FILE definitions require documented clauses. Coding standards define what is acceptable on your LPAR: field prefixes by application, maximum PROC length, mandatory program headers, forbidden DISPLAY in production paths. Violating language rules fails compile; violating standards fails peer review or change board policy. Beginners need both manuals—the Language Reference for correctness, the site standards PDF for consistency.

Typical Standard Categories

Common enterprise standard sections
Category	Example rules	Tutorial
Naming	Prefixes by file type; PROC verbs; no single-letter fields	Naming standards
Formatting	Indent PERFORM bodies; column-align IF/END-IF	Formatting standards
Comments	Header block; business why not syntax what	Comments best practices
Structure	Thin JOB; macros for shared FILE; no god PROC	Modular design
Errors	Mandatory EOF handling; error counters; no silent skip	Error handling pattern
Compile/promote	Prod PROC name; no DEBUG FLOW; regression list	Compilation tutorial

Naming Conventions

Standards often mandate prefixes: input file fields start with IN-, report work fields with WR-, counters with CNT- or TOT-. Procedure names use verb-noun form: CALC-FED-TAX, WRITE-DETAIL. Labels for GOTO exits end with purpose: SKIP-RECORD, END-JOB-INPUT. Reserved words and ambiguous product names stay forbidden. Names are limited length—avoid exceeding maintainability when site rules cap identifier size. New hires learn prefixes once and navigate unfamiliar programs faster during incident bridge calls.

Formatting and Layout

Consistent indentation makes Endevor diffs meaningful. Standards specify spaces versus tabs (often spaces on mainframe ISPF), whether FILE blocks align FIELDS, and where macro invocations sit (top of member after header). REPORT activities separate TITLE, LINE, and procedure hooks with banner comments. Mixed styles in one application area force reviewers to waste cycles on whitespace instead of logic.

text

1
2
3
4
5
6
7
8
* --- FILE DEFINITIONS (macros) ---
%PERSNL-FILE  DSN=HR.PERSNL.MASTER
 
* --- JOB PROCESSING ---
JOB INPUT PERSNL
  PERFORM VALIDATE-RECORD
  PERFORM UPDATE-ACCUMULATORS
END

Error Handling Standards

Production standards usually require explicit EOF handling, invalid record branches that increment ERROR-COUNT, and SYSPRINT or audit file messages with record keys—not silent GOTO that drops data. Some sites mandate STOP RUN or controlled abend when error rate exceeds threshold; others write exception files for morning rework. Pick one pattern per application and document it. Mixing styles within one nightly chain confuses reconcile staff.

FILE, Macro, and COPY Rules

Shared layouts must use approved macro library members—no instream duplicate in production.
Dataset names use catalog standards or internal tables—not hardcoded test DSNs left by mistake.
GDG references document generation and retention expectations in header comments.
Environmental options (BUFNO, etc.) require performance ticket reference when non-default.

Compile and Promotion Gates

Standards name the JCL PROC for development versus production compiles. Development may include DEBUG, MAP, or extended LIST; production strips diagnostics that inflate CPU and output. Promotion checklist items: compile return code zero, macro regression list executed, peer review approval, operations runbook updated if schedule or DSN changed, test totals attached to ticket. Skipping gates is how DEBUG FLOW reaches month-end production.

Code Review Checklist

Program header complete and accurate?
Names follow prefix and PROC verb rules?
Shared FILE uses approved macro?
EOF and invalid data paths handled per standard?
No production DISPLAY or DEBUG options?
Logic changes include test evidence in ticket?
Reserved words and deprecated syntax checked against migration notes?

Aligning With Broadcom Releases

When Broadcom adds reserved words or deprecates clauses, update standards and scan programs during migration waves. Compatibility tutorial pages list version traps. Standards should reference current release number and link to internal migration playbook. Static PDF standards without owners become ignored; assign a quarterly review.

Explain It Like I'm Five

Coding standards are classroom rules for writing. Everyone uses the same margin size, puts their name at the top, and writes in neat letters so the teacher can read any paper quickly. If one person uses secret codes and tiny scribbles, grading takes forever and mistakes hide. Standards do not stop you from telling the story—they help everyone read it the same way.

Exercises

Draft five naming rules for a fictional retail reporting application.
Review sample pseudocode against the code review checklist above.
List differences between development and production compile standards.
Write an error-handling standard paragraph for invalid store-number records.
Map each standard category to the matching tutorial in section 28.

Quiz

Test Your Knowledge

1. Site coding standards exist primarily to:

Make code consistent and reviewable across teams
Replace the Broadcom manual
Eliminate PROC
Ban all GOTO

2. Field names in production code should:

Describe business meaning (GROSS-PAY not X1)
Be single letters only
Match JCL step names only
Change every compile

3. Production compiles typically require:

Approved compile PROC without DEBUG in prod
Random options per developer
No LIST ever
Online only

4. Code review should verify:

Logic, standards compliance, and test evidence
Only spelling in comments
Nothing if job runs once
Only macro names

5. Reserved words and new syntax releases mean standards must:

Update when product or site rules change
Never change
Ignore Broadcom bulletins
Remove all IF statements