Why use design patterns in Easytrieve?

Patterns shorten design time for common jobs—weekly control reports, file copy utilities, validation-heavy feeds—by reusing skeletons that already worked in production elsewhere on the site.

Where should I start after this overview?

Pick the pattern matching your next assignment: reusable report framework for listing jobs, batch processing pattern for multi-step file jobs, validation framework for inbound feeds with error files.

Can patterns combine?

Yes. A retail sales rollup might use batch processing pattern for extract order, lookup tables for SKU descriptions, control breaks for store totals, and error handling pattern for bad records.

Are patterns the same as PROC modules?

PROC modules are language building blocks. Patterns describe how multiple statements, activities, and files fit together—a higher-level blueprint you implement with PROCs, macros, and REPORT structure.

Easytrieve Design Patterns Overview - Reusable Batch and Report Solutions

Easytrieve Design Patterns Overview

Design patterns are named, repeatable ways to structure Easytrieve programs that solve problems your site hits again and again. Insurance firms generate control-break premium reports; banks copy reconciliation files between regions; retailers validate POS extracts before loading warehouses. Each problem has a skeleton: which activities to use, where validation lives, how errors exit, how reports share TITLE and footing macros. Patterns are not Broadcom syntax—they are organizational knowledge expressed in Easytrieve building blocks (JOB, REPORT, PROC, macros, SORT, FILE). This overview maps the pattern catalog in section 29, explains when to choose each pattern, shows how patterns connect to best practices and modular design, and gives beginners a decision path before opening the dedicated pattern pages. Treat patterns as templates to adapt, not copy-paste without thought for your file layouts and schedule constraints.

Patterns Versus Best Practices

Best practices tell you to name fields clearly and measure before tuning BUFNO. Design patterns tell you how to lay out a validation-heavy inbound feed: macro for FILE layout, INIT procedure to load codes table, PERFORM VALIDATE-RECORD with error file WRITE, separate PERFORM for transform. Practices are principles; patterns are blueprints. You need both—patterns implemented with sloppy names still hurt maintainability.

Pattern Catalog

Section 29 patterns at a glance
Pattern	Problem it solves	Deep dive page
Reusable report framework	Many similar listing reports with shared headers/footers	reusable-report-framework
Validation framework	Inbound feeds with invalid records routed to exception files	validation-framework
Batch processing	Multi-step read-transform-write nightly jobs	batch-processing
Error handling	Consistent counters, messages, and stop/continue rules	error-handling
File copy utility	Format-preserving or light-touch copy between datasets	file-copy-utility
Control break processing	Subtotals and headings when keys change	control-break-processing
Lookup tables	Code-to-description and rate tables at runtime	lookup-tables
Reusable procedures	Shared PERFORM libraries within application areas	reusable-procedures

Choosing a Pattern

Start from outputs and failure modes. If operations needs a formatted listing with standard corporate headers, start with reusable report framework. If data quality dominates—half the feed has bad store numbers—validation framework plus error handling pattern. If the job is mostly moving and filtering records without complex report formatting, batch processing or file copy utility may suffice. If users ask for subtotals by region and department, control break processing. Reference data scattered across codes in input files points to lookup tables. Multiple programs share the same tax CALC PERFORM blocks—reusable procedures pattern inside modular design standards.

Pattern Composition Example

A nightly retail sales job might chain patterns as follows. Batch processing pattern defines JOB INPUT reading POS extract, PERFORM VALIDATE-LINE (validation framework), PERFORM ENRICH-SKU via table LOOKUP (lookup tables), WRITE clean work file. Second step REPORT activity uses control break processing on STORE-NUM with reusable report framework macros for TITLE and footing. Error handling pattern increments BAD-COUNT and writes SALES.EXCEP file rows with reason codes. One real job implements several patterns; the overview helps you name what you are building when documenting in change tickets.

text

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
JOB INPUT POS-FILE
  PERFORM VALIDATE-LINE
  IF RECORD-OK
     PERFORM ENRICH-FROM-SKU-TABLE
     WRITE CLEAN-FILE
  ELSE
     PERFORM LOG-EXCEPTION
  END-IF
END
 
REPORT SALES-RPT
  BREAK-LEVEL STORE-NUM
  BEFORE-BREAK. PROC
    PERFORM RESET-STORE-ACCUM
  END-PROC
  AFTER-BREAK. PROC
    PERFORM PRINT-STORE-SUBTOTAL
  END-PROC

Implementing With Macros and PROCs

Patterns often ship as macro libraries plus PROC skeletons. Report framework macros generate TITLE and PAGE hooks; validation framework supplies VALIDATE-HEADER and VALIDATE-DETAIL procedure stubs developers fill with field rules. Keep pattern artifacts in a governed library with version numbers. Teams customize inside designated PROC bodies without editing macro core each time—extension points are part of good pattern design.

When Not to Force a Pattern

One-off thirty-line jobs may not justify framework overhead.
Pattern mismatch—do not use report framework for pure file copy with no PRINT.
Legacy programs mid-life: partial pattern adoption beats big-bang rewrite without tests.
Performance-critical paths where extra indirection adds measurable CPU—document exception.

Learning Path

Read this overview and best practices section (modular design, coding standards).
Study the pattern page closest to your assigned job type.
Walk through a production sample member on your LPAR if available.
Prototype pattern skeleton with test data before adding business rules.
Contribute improvements back to site pattern library via change control.

Explain It Like I'm Five

Design patterns are like cookie cutters for programs. You have a star cutter for holiday reports and a round cutter for simple lists. The dough (your data) changes, but the shape (structure) is already known to work in the oven (batch window). You do not invent a new cutter for every cookie unless the cookie is truly weird. Patterns save time and make cookies look like they came from the same bakery.

Exercises

Match three fictional job descriptions to patterns from the catalog table.
Draw a flow combining validation and error handling for a bad-record feed.
Explain difference between reusable report framework and control break processing.
List extension points you would leave in a validation framework macro.
Name two patterns a payroll exception report likely uses.

Quiz

Test Your Knowledge

1. A design pattern in Easytrieve is:

A proven reusable solution to a recurring problem
A JCL utility
A reserved word
A compiler bug

2. Validation framework pattern typically separates:

Input checks from core business calculation
JCL from COBOL
CICS from batch only
TITLE from LINE always

3. Lookup table pattern fits when:

Reference data maps codes to descriptions at runtime
No files exist
Only online screens run
SORT is forbidden

4. Control break processing pattern uses:

Report break levels and AFTER-BREAK procedures
Only SCREEN activities
Macro expansion only
JCL IF statements

5. Patterns differ from best practices because patterns:

Provide concrete structural templates for specific problems
Replace Broadcom syntax
Are optional compiler flags
Apply only to macros