Easytrieve Macro Reuse

Macro reuse is why mainframe shops adopt the Macro Facility in the first place—one authoritative PERSNL layout, dozens of programs, zero copy-paste drift. Reuse succeeds when libraries are governed like production source: named owners, Endevor promotions, regression compiles, and documented parameter contracts. Reuse fails when developers embed instream test macros in production members, when positional parameter order changes without a migration plan, or when nobody recompiles dependent programs after a silent library update. This page covers library architecture, composable macro design, naming conventions, change-control workflows, team patterns for FILE versus REPORT macros, anti-patterns to avoid, and handoff between application releases and macro library levels. Treat it as the operational companion to syntax, arguments, and expansion tutorials—you know how macros work; here is how organizations keep them working for decades.

Progress0 of 0 lessons

Shared Library Architecture

Enterprise installations catalog macro libraries in compile JCL or IDE host profiles. Preprocessor search order may include application-private macros first, then department standard library, then site-wide layout library. Document search order so a duplicate macro name in two libraries does not surprise developers with wrong expansion.

Typical library tiers
TierTypical contentsChange rigor
Site-widePERSNL, GL-MASTER, standard TITLE blocksHighest— CAB approval
ApplicationApp-specific FILE variantsApplication lead review
Developer testMSTART instream prototypesLocal only—never production invoke

Composable Macro Design

Instead of one MEGA-LAYOUT macro emitting FILE, fifty DEFINE fields, REPORT headers, and working storage, split responsibilities. Callers compose invocations in library section order matching valid Easytrieve structure.

text
1
2
3
4
5
6
%PERSNL-FILE %PERSNL-WORK %STD-PAGE-HDR PAY-RPT JOB INPUT PERSNL PRINT PAY-RPT
  • PERSNL-FILE — FILE and record fields from data dictionary.
  • PERSNL-WORK — working storage DEFINE used across payroll programs.
  • STD-PAGE-HDR — parameterized REPORT TITLE/LINE with report name argument.

Naming Conventions

Suggested naming patterns
PatternExampleMeaning
FILE suffixPERSNL-FFILE/DEFINE layout only
RPT prefixRPT-STDReport skeleton lines
Version suffixPERSN2Parallel migration macro
App prefixPY-PERSNLPayroll-specific variant

Eight-character default limit forces abbreviations—publish a site dictionary mapping abbreviations to full file names.

Change-Control Workflow

  1. Analyst requests layout change with data dictionary reference.
  2. Developer edits macro member in test library; full expansion listing attached to ticket.
  3. Regression-compile pilot programs from each invoking application family.
  4. QA compares job output to baseline files for key reports.
  5. Endevor promotion to production library with release note listing macro level.
  6. Application teams schedule recompile of dependent programs in same or follow-on release.

Parameter Contract Documentation

Header comment block on each macro member should list positional order, keyword defaults, invoking example, owning team, and last data dictionary version. Future maintainers should not reverse-engineer invocation from body alone.

text
1
2
3
4
5
6
* MACRO: PERSNL-F OWNER: HR-DATA DICT: 2026-03 * POS: none KEY: RECLEN default 150 BLKSIZE default 1800 * EXAMPLE: %PERSNL-F RECLEN=200 MACRO 0 RECLEN 150 BLKSIZE 1800 ... MEND

Reuse Patterns by Domain

Master file layouts

Single source for FILE offsets—highest reuse value. Pair with data dictionary automation where available.

Report cosmetics

TITLE and LINE macros enforce audit headers (date, page, department name) consistently across regulated reports.

SQL field bundles

Db2 table macros generate INCLUDE field sets for programs accessing same tables—reduce drift between online and batch Easytrieve SQL.

Site constants

Parameterized DEFINE VALUE blocks for application ID or company code in multi-tenant batch streams.

Anti-Patterns

  • Instream-only macros in production programs—breaks when member copied without test block.
  • Macro containing JOB logic tied to one program—belongs in source not shared library.
  • Undocumented positional reorder breaking fifty callers silently until recompile.
  • Over-parameterizing rarely changed values—adds invocation errors without maintenance win.
  • Skipping regression because change looks small—one-byte offset shift corrupts totals.

Migration and Versioning Strategies

Breaking changes need explicit strategy. Parallel macro name (PERSNL2) lets teams migrate program-by-program. Big-bang migration updates all invocations in one release window with full regression suite. Never change production macro in place without caller inventory—grep source libraries for %MACRONAME before edit.

Inventory and Impact Analysis

Before any shared macro edit, run source search across PDS libraries for % invocations. Endevor impact analysis may list elements including macro references in compile control cards. Maintain spreadsheet of top invoking programs for quick regression subset.

Training New Developers

Onboarding should include: where macro libraries live, how to read expansion listings, parameter header comments, and who approves site-wide changes. Junior developers invoke macros first; senior owners edit library members after review.

Explain It Like I'm Five

Reuse is sharing one good recipe card in the school kitchen instead of every kid writing their own. If the recipe card gets a typo fix, every kid who uses the card gets the fix next time they cook—but only if they pick up the new card. The library is the recipe box; change control is the teacher approving recipe edits.

Exercises

  1. Design three composable macros for a payroll report program.
  2. Write a six-step change-control workflow for a DEPT offset change.
  3. List programs you would include in regression after PERSNL macro edit.
  4. Propose naming convention for your site with eight-character limit.
  5. Describe parallel macro versioning versus big-bang migration tradeoffs.

Quiz

Test Your Knowledge

1. Production macros should live in:

  • Shared change-controlled libraries
  • Developer personal datasets only
  • SYSPRINT
  • Temporary work files

2. After editing a shared FILE macro you should:

  • Regression-compile representative invoking programs
  • Only restart CICS
  • Skip compile
  • Delete load modules

3. Macro reuse differs from copy-paste because:

  • One library update propagates on recompile
  • Macros run faster at runtime
  • Copy-paste is change-controlled
  • Macros need no parameters

4. Breaking change to positional parameter order requires:

  • Updating every invocation or versioning macro name
  • Nothing—automatic fix
  • JCL change only
  • Runtime PERFORM change

5. Good macro reuse candidate is:

  • Enterprise PERSNL FILE layout used in 40 programs
  • One-line comment
  • Single-use report title
  • Unique one-off logic
Published
Read time18 min
AuthorMainframeMaster
Reviewed by MainframeMaster teamVerified: Broadcom Easytrieve Report Generator 11.6 macro library reuse practicesSources: Broadcom Easytrieve 11.6 Macro Facility, enterprise change control patternsApplies to: Easytrieve shared macro libraries and governance