Before you write FILE, JOB, or REPORT statements, it helps to see how an Easytrieve program is organized as a whole. Broadcom divides source into Environment, Library, and Activity sections. Each section has a distinct job: options and standards, data descriptions, and executable logic. Beginners who mix REPORT lines into the Library section or place PROCs before REPORT definitions create compile errors that look mysterious until you understand the skeleton. This page maps that skeleton so every later topic—field definitions, job logic, reports, and screens—has a clear home.
An Easytrieve program is not a flat list of commands. Broadcom expects sections in a predictable order so the compiler can build symbol tables before validating executable logic. Think of Environment as program-wide settings, Library as your data dictionary, and Activity as where processing happens. Only Activity is strictly required, but batch report programs almost always use Library too.
| Section | Required? | Role |
|---|---|---|
| Environment | Optional | PARM and options that customize compile and execute behavior for this program |
| Library | Optional (usually required) | FILE, DEFINE, and working storage describing input, output, and fields |
| Activity | At least one required | PROGRAM, JOB, SORT, or SCREEN logic plus PROCs and REPORT subactivities |
Broadcom documentation shows a general template: PARM in Environment; FILE and DEFINE in Library; then Activity blocks. Within each JOB activity, executable statements come first, job PROCs next, then REPORT subactivities, then any REPORT PROCs tied to each report. SCREEN activities follow a similar pattern with screen procedures at the end. Deviating from this order usually produces compile errors rather than silent bugs.
123456789101112131415PARM LINK(PAYRPT) DEBUG(STATE) FILE PERSNL FB(150 1800) EMPNO 1 5 N DEPT 6 3 A GROSS 40 7 P 2 JOB INPUT PERSNL IF DEPT EQ 'ACC' PRINT EMPNO GROSS END-IF REPORT PAY-RPT LINESIZE 80 TITLE 01 'PAYROLL BY DEPARTMENT' LINE 01 DEPT EMPNO GROSS
PARM opens the Environment section. FILE begins Library definitions for the personnel file. JOB starts an Activity that reads PERSNL and conditionally prints detail lines. REPORT defines formatted output at the end of the JOB activity. This miniature program shows how sections cooperate: Library names the fields JOB logic references; REPORT formats what PRINT selected.
The Environment section customizes standards for one program. The PARM statement is its anchor: it can set LINK name, DEBUG options, ABEXIT behavior, listing controls, and other compile and execute parameters documented in the PARM reference. Site options tables provide defaults; PARM overrides them for this source member. For example, FLOW tracing helps during test abends but adds overhead, so you enable it here rather than changing global site options for every program.
Environment choices can affect efficiency. Broadcom notes trade-offs between automatic debugging aids and runtime speed. A program compiled with extensive field checking may catch data problems early at the cost of CPU. Structure Environment decisions at the top so reviewers see program-wide behavior before scrolling through business logic.
The Library section describes data the program touches. FILE statements declare files and their record layouts; DEFINE creates working storage fields not tied to a particular record position. When you reference EMPNO in a JOB IF statement, the compiler looks here first. Accurate Library coding reduces runtime conversion overhead—defining a field with the correct type and length avoids expensive implicit conversions during execution.
Library is optional only when no file I/O occurs. That might apply to a tiny utility manipulating working storage alone. Report generators, payroll extracts, and file matchers always need Library definitions. Beginners should assume Library is required until they can justify omitting it.
Activity is where executable and declarative processing statements live. Broadcom defines four activity types, each suited to different workloads. Most batch tutorials emphasize JOB activities because they read files and drive reports. SORT activities build ordered files. SCREEN activities support interactive terminal work. PROGRAM activities coordinate others.
| Activity type | Typical use |
|---|---|
| PROGRAM | Top-down driver logic; can EXECUTE JOB, SORT, or SCREEN activities |
| JOB | Batch file read, update, write, and report initiation |
| SORT | Create sequenced or ordered output files |
| SCREEN | Display and accept terminal data; may EXECUTE batch activities |
Procedures (PROCs) are reusable code modules at the end of an activity. Job PROCs follow the executable statements in a JOB. REPORT subactivities describe formatted reports and appear after job PROCs if any. REPORT PROCs must immediately follow the REPORT subactivity that uses them. This nesting rules out placing a REPORT in the middle of JOB IF logic—report definitions are declarative areas, not inline statements within the read loop.
Within Activity, some statements execute during the run (procedural) and others describe structure the compiler records (declarative). JOB INPUT and IF bodies are procedural—they run as records arrive. REPORT TITLE and LINE are declarative—they define layout consumed by the report writer when PRINT or automatic reporting triggers output. Confusing the two leads to coding REPORT inside an IF block where the compiler expects procedural syntax.
Labels identify PROGRAM, JOB, SCREEN, SORT, PROC, and REPORT names. They can be long and may include national characters in documented rules, but must follow delimiter and uniqueness constraints. Multiple labeled JOB activities let one source member support several batch processes; a PROGRAM activity can EXECUTE only the job needed for the current run. This pattern reduces JCL proliferation when related processes share field definitions in one Library section.
Teams that respect section boundaries maintain programs faster. Data analysts find field changes in Library without reading report titles. Operations can grep JOB INPUT lines to learn which files a program touches. Report designers adjust LINE layouts without touching calculation PROCs. Structure is not bureaucracy—it is navigation for humans and the compiler alike.
An Easytrieve program is like a school play script. The Environment page is the rule sheet—how loud the microphones are and whether you record the show. The Library page lists every character and prop—who is on stage and what they hold. The Activity pages are the scenes—what actors do and say. Reports are the printed programs you hand to the audience. If you write a scene before introducing the characters, the director—the compiler—will stop rehearsal and ask you to fix the script order.
1. The only required Easytrieve program section is:
2. The Library section primarily defines:
3. REPORT subactivities are coded:
4. A PROGRAM activity is used to:
5. Environment section options such as FLOW affect: