Easytrieve Program Lifecycle Overview

The Lifecycle at a Glance

1. Create or change Easytrieve source in a controlled library.
2. Submit compile JCL and review SYSPRINT listing for errors.
3. Link object code into a load module when using compile-link-execute flow.
4. Test with representative input in a non-production region.
5. Promote approved load module and JCL to production libraries and scheduler.
6. Execute on schedule and monitor return codes, counts, and report distribution.
7. Maintain source, JCL, and operational documentation as requirements change.
8. Retire or replace the program when business need ends or systems migrate.

Phase 1: Source Development

Lifecycle work starts in source. A developer writes or modifies FILE, JOB, IF, PRINT, REPORT, TITLE, LINE, and related statements. Source may live in a PDS member, PDSE, or an enterprise change-management repository. Good lifecycle practice keeps member names, version history, and business intent documented. A one-line title change can affect regulatory reports, so source control is not optional in mature shops.

1
2
3
4
5
6
7
8
9
FILE INVOICE FB(180 1800)
  INV-NO      1  8  N
  INV-AMT     9  7  P  2
  INV-DATE   16  8  N
 
JOB INPUT INVOICE
  IF INV-AMT > 1000
    PRINT HIGHVAL-RPT
  END-IF

At this phase, the program is just text. It has not been validated by the compiler or run against production volumes. Peer review, unit test planning, and data layout confirmation belong here before promotion discussions begin.

Phase 2: Compilation

Compilation checks syntax and semantics, builds symbol tables, and generates object code. The output is documented on SYSPRINT. Errors at this phase are source or environment problems: undefined fields, bad macros, missing options tables, or invalid report references. A clean compile is the gate to later testing. See the dedicated compilation page for message reading and PARM behavior.

Phase 3: Linking

Object code from SYSLIN is not directly executable in the usual production pattern. A binder step such as IEWL creates a load module and stores it in an application load library. The module name must match the PGM= value used by runtime JCL. Linking resolves references to Easytrieve runtime services and produces the executable artifact operations will run repeatedly.

Phase 4: Testing

Testing validates business results, not just successful return codes. Compare totals, record counts, key subtotals, and sample detail lines against a trusted baseline. Test with empty files, large files, boundary dates, and exception records. A program can complete with RC=0 and still be wrong if filters, masks, or control breaks are incorrect.

Phase 5: Promotion

Promotion moves approved artifacts into production-ready locations: source libraries, load libraries, JCL procedures, scheduler definitions, and operations run books. Mature shops use change tickets, approval workflows, and backout plans. Promotion is more than copying a load module. It includes verifying STEPLIB, DD names, dataset names, security, and report distribution paths in the production environment.

Phase 6: Execution and Operations

Scheduled execution is the visible part of the lifecycle. The scheduler submits JCL, z/OS allocates DD statements, the load module runs, reports are routed, and return codes are recorded. Operations monitors late jobs, abends, reruns, and downstream dependencies. A payroll extract that finishes at 02:17 instead of 01:45 may still be successful but can affect later steps if thresholds are tight.

Phase 7: Maintenance and Retirement

Reports change when regulations, fee schedules, product codes, or file layouts change. Maintenance may be a small source edit or a multi-step migration. Retirement happens when a report is replaced by another system or consolidated into a different job stream. Lifecycle documentation should record why a program was retired and what verified it before decommissioning.

Compile-and-Go vs Production Lifecycle

Artifacts to Track in Each Phase

• Source member name and change history.
• Compile listing on SYSPRINT or archived listing dataset.
• Object dataset or temporary SYSLIN reference.
• Load module name and library after link-edit.
• Runtime JCL procedure and scheduler job definition.
• Operations run book with DD names, expected counts, and contacts.
• Test evidence and approval record for promotion.

Who Fixes What

Lifecycle thinking prevents blame confusion. A compile error is usually a developer source or macro issue. A link error may involve build support or missing runtime libraries. A DD allocation failure may involve operations or storage. A wrong total may be source logic, bad input data, or an upstream extract problem. Naming the phase narrows the search immediately.

Explain It Like I'm Five

Making an Easytrieve report is like baking a cake for the school fair. First you write the recipe. Then someone checks the recipe makes sense. Then the cake is baked and put in the right box. Then someone tastes it before the fair. Then the fair sells the cake every day at the same table. If the cake changes, you update the recipe and test again before selling the new version.

Exercises

1. Draw the lifecycle for one Easytrieve report from source edit to scheduled execution.
2. List the artifact you would inspect for a compile failure, a link failure, and a runtime DD failure.
3. Explain why RC=0 does not always mean the report is business-correct.
4. Compare compile-and-go with the production promotion pattern.
5. Write three questions to ask before retiring an old Easytrieve report.