Easytrieve Classic is where the language began: a specialized report tool for mainframe batch shops that needed listings, extracts, and control-break summaries without writing hundreds of lines of COBOL. Released in the early 1970s by Ribek Corporation and expanded under Pansophic Systems, Classic introduced the mental model that still shapes every modern Easytrieve program—a Library of files and fields, followed by Activities that read data, test conditions, accumulate totals, and print formatted output. If you maintain code with Pansophic-era comments, minimal online features, or proc libraries that predate CA-Easytrieve Plus, you are almost certainly touching Classic lineage. Understanding Classic syntax, its limitations compared to Plus and Broadcom Report Generator 11.6, and the migration patterns shops use today is essential for anyone responsible for legacy reporting portfolios.
Robert I. Beckler's Ribek Corporation shipped the first Easytrieve releases around 1971–1972 for IBM System/360 and RCA Series 70. Data centers were transitioning from card-based batch to disk-resident files; reporting still dominated nightly processing windows. COBOL excelled at full applications but felt heavy for "read file, filter records, print columns" jobs. Classic Easytrieve captured those patterns in a concise vocabulary: FILE to describe inputs and outputs, DEFINE or implicit field layouts, JOB to drive processing logic, and REPORT for formatted listing activities.
Pansophic Systems became the exclusive North American reseller in 1973 and acquired the product outright in 1979. Under Pansophic, Classic spread through banking, insurance, and government installations. VSAM support, improved control breaks, and training materials cemented Easytrieve as a listed skill on mainframe job postings. Listings and run books from that era may still show Pansophic copyright notices—useful evidence when dating source libraries before a migration project.
Every Classic program divides into two major regions. The Library holds declarative information: which files exist, record layouts, working storage fields, constants, and sometimes macro invocations. Activities contain executable logic: a JOB activity reads files and performs procedural steps; a REPORT activity defines headings, detail lines, control breaks, and totals. This separation mirrors how report writers think—first declare what data looks like, then describe what to do with it—rather than mixing declaration and procedure the way COBOL DATA DIVISION and PROCEDURE DIVISION do.
Classic Activities use statement blocks familiar to modern readers: IF/ELSE for conditional logic, PERFORM or GOTO-style flow (exact spellings vary by release), SORT when ordering is required, and PRINT or LINE within REPORT for output. The Activity name appears after the keyword—JOB INPUT names a job that processes input files, REPORT SALESRPT names a report layout. Multiple Activities can coexist in one program, with the compiler and runtime coordinating file opens and report emission according to the program structure.
123456789101112* Classic-style batch report skeleton FILE SALES FB(80 10000) DEFINE SALES STORE-NO 5 N SALE-DATE 8 N AMOUNT 7 2 P JOB INPUT SALES IF STORE-NO EQ 100 ADD AMOUNT TO STORE-TOTAL END-IF REPORT STORE-RPT LINE STORE-NO STORE-TOTAL
The sample above is pedagogical—your site's actual Classic programs may use different column positions, mask formats, or REPORT hooks. The important lesson is the flow: FILE and DEFINE in the Library, JOB for record processing, REPORT for printed layout. Modern Plus and 11.6 programs follow the same skeleton even when statement names gained synonyms or new options.
Classic FILE statements describe organization (sequential, indexed, VSAM), record length, buffer counts, and access mode. Fields are defined with picture-like type codes: N for numeric, A for alphanumeric, P for packed decimal, and date or edit masks where supported. Classic shops often centralized FILE layouts in copybook-like macro libraries so dozens of reports shared one record definition—an early form of modular design that migration projects should preserve rather than inlining layouts into every program.
| Element | Purpose | Migration note |
|---|---|---|
| FB (fixed blocked) | Sequential file with fixed record length and block size | Usually maps directly; verify BLKSIZE on target JCL |
| VSAM KSDS/ESDS | Indexed or entry-sequenced file access | Confirm ACCESS mode spelling in 11.6 Language Reference |
| DEFINE / field types | Record layout and working storage | Scan field names against New Reserved Words before 11.6 cutover |
| MACRO libraries | Shared layouts and code fragments | Fix macros once to repair many programs |
REPORT activities in Classic focus on control breaks, headings, detail lines, and totals. BEFORE and AFTER hooks (or era-specific equivalents) let programs print banners when sort keys change, accumulate subtotals, and reset counters. Classic report writers thought in terms of break levels: region, branch, account, or date—each level potentially triggering subtotal lines and page skips. Masked numeric fields aligned columns for accounting readers long before spreadsheet exports.
Classic lacked many Plus conveniences: richer SCREEN online activities, simplified SQL FILE automation, GUI Workbench integration, and modern IDE extensions. Classic programs were overwhelmingly batch: JCL in, SYSPRINT listing out, sequential or VSAM files on DASD. If your portfolio includes online Easytrieve screens, those modules likely already crossed into Plus territory even if comments still say Classic.
CA-Easytrieve Plus (see the Easytrieve Plus tutorial) extended Classic with SQL file support, PROGRAM-level execution parameters, expanded $functions, cross-platform ports, and online SCREEN facilities. Classic source often compiles on Plus with few changes; the reverse is not guaranteed when Plus-only statements appear. Migration from Classic to Broadcom 11.6 is effectively migration to the current Plus/Report Generator line—there is no separate Classic compiler maintained independently in modern TechDocs.
| Topic | Classic era | Plus / 11.6 |
|---|---|---|
| Primary use case | Batch reports and extracts | Batch plus SQL, online, distributed ports |
| Documentation | Pansophic/early CA manuals | Application Guide, Broadcom TechDocs 11.6 |
| Options control | Site table, compile PARM | EZOPTBL file, expanded PARM keywords |
| Reserved words | Smaller keyword set | Grows each release; 11.6 function mode adds many |
Start with inventory metadata: library create dates, programmer comments, and proc names. Search for Pansophic strings, EZTCLASSIC proc steps, or FILE options absent from current Language Reference. Classic programs may use older spellings for report hooks or omit statements that Plus programmers consider standard. Run a pilot compile on the target 11.6 compiler—even if production still runs an older load module—to surface diagnostics early.
Successful Classic migrations treat the compiler upgrade as a portfolio project, not a single program fix. Install 11.6 on a test LPAR; convert the site options table with Broadcom's utility if you are jumping from 6.x formats; update STEPLIB and EZOPTBL DD in standard procs. Mass-compile source with consistent PARM to build an error frequency report. Fix shared macros first—one FILE macro correction may clear dozens of programs. Rename fields that collide with new reserved words (SET, EXECUTE, SYSUSERID, and others documented on the migration-new-reserved-words page). Retest runtime behavior: Classic programs that compile clean may still produce different totals if rounding, SORT stability, or DISPLAY formatting changed between releases.
12345//EZTCOMP EXEC PGM=EZTPA00,REGION=0M //STEPLIB DD DSN=CA.EZTPLUS.R11.LOAD,DISP=SHR //EZOPTBL DD DSN=SITE.EZT.OPTIONS,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSIN DD DSN=LEGACY.CLASSIC.SRC(RPT001),DISP=SHR
Library names vary by installation—the pattern matters more than the DSN spelling. REGION=0M reflects 11.x module sizes. EZOPTBL points at the file-based options table required on modern z/OS releases. Always copy production procs from your operations team rather than inventing DD names from tutorial examples.
Classic programs often run unchanged for years because business rules stabilized and staff turnover was low. New hires trained on Broadcom TechDocs may misread Classic idioms—unlabeled GOTOs, terse field names, REPORT masks without comments. Document internal standards when migrating: prefix renamed fields, require LIST FILE on compile PARM until cutover completes, and store before/after listing PDFs for audit. Change control should keep previous load modules until parallel running proves output equivalence on representative pay periods or fiscal closes.
Easytrieve Classic is the first recipe book for making paper reports from computer files. It tells the computer what files look like (Library) and what steps to follow (Activities) to print neat columns and subtotals. Newer recipe books (Plus and Broadcom 11.6) add more ingredients like SQL and online screens, but many old recipes still work if you check the new book for renamed ingredients—words you used as field names that became special command words.
1. Easytrieve Classic originally targeted which hardware environments?
2. The core program structure in Classic Easytrieve is organized as:
3. When migrating Classic source to Easytrieve Plus or 11.6, the most common first step is:
4. Classic programs often lack which Plus-era capability?
5. Pansophic copyright lines in compile listings indicate:
Easytrieve Classic is the original report-generation language from Ribek and Pansophic, built around Library declarations and Activities such as JOB and REPORT. It focused on batch file processing, control breaks, and formatted listings with far fewer statements than COBOL for the same task.
Broadcom supports CA Easytrieve Report Generator 11.6, not a separate Classic product line. Legacy Classic source usually compiles on modern Plus/Report Generator compilers after syntax updates documented in migration guides—but shops should verify against their installed maintenance level.
Look for older statement spellings, minimal SCREEN usage, Pansophic-era comments, proc names like EZTCLASSIC, and FILE options absent from current Language Reference. Compile listings and internal library naming conventions also reveal age.
Common issues include new reserved words colliding with field names, deprecated FILE or REPORT options, options table format changes (EZOPTBL), and behavioral differences in SORT or DISPLAY formatting documented in release notes.
Usually no for stable batch reports. Migration preserves decades of business rules embedded in control breaks and masks. COBOL rewrite makes sense when the organization is exiting Easytrieve entirely—not as the default first step for a compiler upgrade.