Easytrieve

Easytrieve is a report generator and data-retrieval language for IBM mainframes, and one of the longest-lived commercial programming products still being shipped. Its premise is in the name: retrieving data should be easy. Instead of writing a COBOL program with an IDENTIFICATION DIVISION, a FILE SECTION, an explicit read loop, an at-end condition, page-break logic, and accumulator handling, an Easytrieve programmer declares where the fields sit in the record, states which records to keep, and describes the report they want. The compiler generates the loop, the sorting, the control breaks, the totals, the headings, and the pagination.

That trade - a narrow problem domain in exchange for a very short program - is what a fourth-generation language was supposed to be, and Easytrieve is one of the few 4GLs from the era that is still commercially supported today. Its lineage runs from a small independent software firm through Pansophic Systems, then Computer Associates, and now Broadcom, spanning roughly five decades of continuous product life.

History and Origins

Easytrieve was not a Pansophic invention, though Pansophic is the name most associated with it. The product came from Ribek Corporation, a small firm named for its owner Robert I. Beckler, and was written for IBM System/360 and System/370 machines and the RCA Series 70. Dating the first release precisely is difficult and sources disagree: the product is widely dated to 1969, while other accounts describe it as developed by a handful of people in Maryland around 1970-71 with an initial release around 1971 or 1972. What is not disputed is that it was on the market and selling well by the early-to-mid 1970s.

The commercial history is clearer. Pansophic Systems - founded in 1969 in Oak Brook, Illinois by Joseph A. Piscopo with four employees and $150,000 of startup capital - became the exclusive North American reseller of Easytrieve in 1973, and bought the product outright from Ribek in 1979 for a figure reported at around $8 million. Alongside Panvalet, Pansophic’s source code management system, Easytrieve became one of the two products that carried the company through its rapid growth in the 1970s and 1980s. It has been described as one of the most successful software products of the 1970s.

Pansophic reportedly tried and failed to replace it once. Around 1979 the company is said to have introduced a more ambitious product, Pro/Grammer, which did not succeed commercially. By these accounts the technology behind that effort resurfaced as Easytrieve Plus, distributed to the existing customer base, and Plus went on to supersede the original product - now called Easytrieve Classic - during the 1980s. Crucially, Plus was a redesign, not a superset: the two are not runtime-compatible, and moving programs between them requires recompilation and, usually, source changes. That single decision shaped decades of migration work at Easytrieve sites.

Computer Associates acquired Pansophic in 1991 - the price is variously reported at approximately $290 to $300 million - at a point when Easytrieve was reportedly installed at more than 10,000 IBM mainframe sites. Under CA the product was rebranded CA-Easytrieve Plus and later CA Easytrieve Report Generator, and was extended off the mainframe onto PCs, Windows, and UNIX. Broadcom acquired CA in 2018 and continues to publish and maintain the product.

Design Philosophy

Easytrieve is built on three commitments that were unusual for its era and that explain both its longevity and its limits.

Declare the data, do not parse it. There is no record parsing code in an Easytrieve program. A field is declared by its starting byte position within the record, its length, and its type - A for alphanumeric, N for zoned decimal, P for packed decimal, B for binary - and from that point on it is simply a name. This maps exactly onto the fixed-format, positionally-defined record layouts that dominate mainframe data, and it means an Easytrieve field declaration is often a direct transcription of a COBOL copybook entry.

The loop is implicit. JOB INPUT filename means: for every record in that file, execute the following statements. There is no open, no read, no end-of-file test, no close. This removes the single most common source of boilerplate - and of bugs - in file-processing COBOL.

The report is a specification, not a procedure. A REPORT block states the sort order (SEQUENCE), the grouping (CONTROL), the page headings (TITLE, HEADING), and the detail line (LINE). Subtotals at each control break, grand totals, page breaks, page numbering, and column headings are generated. The programmer never writes the accumulator arithmetic or the break-detection logic that this implies.

The cost of these commitments is generality. Easytrieve is excellent at “read records, select some, summarize, print” and progressively less comfortable the further a task moves from that shape. It is not a general-purpose language and was never marketed as one.

Program Structure

An Easytrieve program has up to three sections, in a fixed order.

JOB activities read files, examine and manipulate data, write files, and initiate reports. SORT activities produce sequenced files. SCREEN activities handle terminal-oriented transactions. PROGRAM is a straightforward top-down sequence of statements with no implicit file loop.

A representative program

* Library section - describe the file and where the fields live
FILE PERSNL FB(150 1800)
   EMP-NAME     17  16  A
   DEPT         98   3  N
   GROSS       127   4  P 2

* Activity section - the loop is implicit
JOB INPUT PERSNL NAME PAYROLL-EXTRACT
   IF DEPT = 911
      PRINT PAYRPT
   END-IF

* Report subactivity - a specification, not a procedure
REPORT PAYRPT LINESIZE 80
   SEQUENCE DEPT EMP-NAME
   CONTROL  DEPT
   TITLE 1 'PAYROLL REPORT BY DEPARTMENT'
   LINE     DEPT EMP-NAME GROSS

Everything a COBOL version of this would spell out - opening the file, the read loop, the end-of-file flag, sorting into department order, detecting when the department changes, accumulating and printing a department subtotal, printing a grand total, counting lines and starting a new page with repeated headings - is generated from those last six lines. CONTROL DEPT alone is responsible for the break logic and the subtotals.

Field types

The positional type system is small and closely tied to mainframe storage formats:

• A - alphanumeric, plain EBCDIC characters
• N - zoned decimal (display numeric), the format numbers usually arrive in on flat files
• P - packed decimal, the mainframe’s native business arithmetic format, with an optional decimal-place count
• B - binary
• U - unsigned/numeric variants depending on release and platform

A field declaration is therefore a statement about bytes on disk, not an abstract type. This is a limitation in the abstract and an enormous convenience in practice, because the data really is bytes at fixed offsets.

Evolution

The product’s evolution splits cleanly into three phases.

Classic (1970s). The original Ribek product: a mainframe report generator, batch-oriented, aimed squarely at System/360 and System/370 shops.

Plus (1980s-1990s). A redesign that broadened the language considerably - more statements, procedures, macro libraries, online and CICS integration, and eventually editions off the mainframe. Reported milestones - drawn from secondary product histories rather than vendor release notes - include a DOS workstation edition around 1990, a PC compiler version around April 1992, and a debugger and an online edition around 1994. Because Plus is not runtime-compatible with Classic, CA maintained Classic compilation paths so that sites could migrate incrementally rather than all at once.

CA / Broadcom releases (1990s-present). Release 6.4 was the mainframe workhorse for a long stretch and has since been through an end-of-service announcement; the current documented release is 11.6, and Broadcom publishes a dedicated 6.4-to-11.6 migration path, including a “new function mode” for behavior changes in input and output handling.

Release 11.6 shows what modernization looks like for a language of this age. According to Broadcom’s own documentation, it adds installation in a Linux PC environment; a Windows-based Workbench IDE and a Visual Studio Code extension for editing and testing programs; XML report output alongside the traditional print format; ODBC SQL processing on Windows and UNIX; C-ISAM file handling on UNIX including variable-length and relative record formats; multiple Db2 subsystem ID support through the PAN/SQL feature; 8-byte binary field support so Db2 BIGINT columns are read without data loss; character comparison against a custom collating sequence via CMPUSINGALTSEQ; a workfile option for intermediate report data instead of virtual files; and file activity I/O statistics.

The through-line is notable: the language a 1975 programmer wrote is still the language in the manual, and the additions are almost entirely about what it can connect to rather than how it expresses computation.

Current Relevance

Easytrieve is dormant as a language - nobody is starting new projects in it, there is no open source implementation, no package ecosystem, no Docker image, and no community of the kind that has grown up around younger languages - but it is not abandoned as a product. Broadcom ships release 11.6 and its documentation carries recent revision dates. That combination, actively supported and effectively frozen as a design, is characteristic of the mainframe software market.

Where it survives, it survives in volume. Batch reporting estates built in the 1980s tend to contain hundreds or thousands of small Easytrieve programs, each one doing something narrow and each one still correct. The economics of rewriting them are poor, which is why a visible conversion industry exists offering Easytrieve-to-COBOL, Easytrieve-to-Java, and Easytrieve-to-SQL translation for organizations leaving the platform, and why Broadcom’s own documentation devotes substantial space to migration between releases.

Two practical realities dominate its present. The first is skills: the population of programmers who can read Easytrieve fluently is aging out, and the language is rarely taught. The second is that it is generally reported to be easy to learn - the surface area is small and the semantics are direct, so a developer already familiar with mainframe file layouts typically comes up to speed quickly. That asymmetry is why Easytrieve programs are so often kept rather than rewritten.

Why It Matters

Easytrieve is worth studying as the clearest surviving example of a design philosophy that has largely disappeared: the domain-specific commercial language, sold as a product, aimed at a business problem rather than at a computational model.

Its report specification anticipates ideas that later became mainstream elsewhere. SEQUENCE and CONTROL are, in effect, ORDER BY and GROUP BY with automatic aggregate rollups, expressed years before SQL was widely deployed and applied to flat files rather than tables. The implicit record loop is the same move that makes SQL, awk, and modern dataframe libraries concise - the programmer describes the per-record transformation and the runtime owns the iteration. The declarative report block does for output formatting what a templating language does for HTML.

It also stands as evidence about what makes software live a long time. Easytrieve outlasted the company that created it, the company that made it famous, and the company that bought that company. It did so not by growing into a general-purpose language but by refusing to - by being small enough that programs written in it stay readable and stay correct, and by being narrow enough that the vendor’s job across five decades has mostly been connecting it to new data sources rather than redesigning it. That is a rarer achievement than it sounds, and most languages that tried to be everything have not managed it.