The CODASYL Data Base Task Group Report — A Proposed Standard for the Network Data Model

In October 1969 a committee of computer manufacturers and large users published a report proposing how programs should define and manipulate a database. It came from the Data Base Task Group of CODASYL, the Conference on Data Systems Languages—the same body that had produced COBOL. A revised report followed in April 1971. Together they turned one company's product, General Electric's Integrated Data Store, into a vendor-neutral specification, and gave the industry much of the vocabulary it still uses for databases.

A COBOL Committee Takes On the Database

By the mid-1960s COBOL was the standard language of business data processing, and it handled files on magnetic tape well. What it lacked was any standard way to work with the random-access disk files that were now arriving. Charles Bachman's IDS at GE showed one answer, but it ran only on GE machines.

CODASYL's answer was to set up a group. According to Thomas Haigh's research, cited in his interview with Bachman, it was founded in October 1965 as the List Processing Task Group and renamed in 1967. Bachman credited Warren Simmons of United States Steel, a professional standards man who had worked on COBOL, with starting it; Simmons had looked at IDS's linked lists and called it a list processing system, a name Bachman thought misleading. The renaming to Data Base Task Group came, Bachman remembered, once "data base" was familiar enough that people could understand what such a group was about.

The members came mostly from computer manufacturers. Looking at the October 1969 report during the interview, Bachman listed members from General Motors, Southern Railways, Allstate, RCA, Travelers Insurance, Honeywell, Univac and Burroughs—and noted there was no one from IBM at the beginning. William Olle of RCA chaired the group by the time it published. Bachman himself represented GE and, by Haigh's account, was an active member from 1966 to 1968.

The October 1969 Report: DDL, DML and Sets

The first year, Bachman said, was largely an education programme in what IDS did. He then "wrote, rewrote, and rewrote" the specification, which began as the text of the GE IDS documentation. IDS's "master" and "detail" records became the DBTG's owner and member records, and the linked chains between them became sets. His stated goal was to keep IDS's functionality, not its exact command syntax.

What the October 1969 report proposed is well documented by a contemporary reader. A University of Minnesota newsletter of February 1971 summarised it for faculty who might want to buy it—from the ACM, for $4.00—and described its core as two separate languages:

• a data description language (DDL) to describe the database, and
• a data manipulation language (DML) that is not free-standing but is embedded in a host language such as COBOL, PL/I or FORTRAN.

The newsletter singled out that separation as the important idea: if data were described independently of the host language, many programs in many languages could share the same database. It also noted what the report deliberately left out. The DML was a language for programmers, not an inquiry language for non-programmers; the task group recognised the need for one but deferred it.

Haigh lists further concepts in the 1969 report: schemas, data independence and program independence, and security features beyond early IDS, including "privacy locks" and sub-schemas that restricted a program to a defined subset of the database, roughly what relational systems later called views.

The April 1971 Report

The group's next report, dated April 1971, was published by the Association for Computing Machinery in New York and runs to iv and 269 pages. It specified the DDL and DML for the network model and is the document usually meant by "the DBTG specification"; schema and subschema are the terms most closely associated with it.

The 1971 report was not the end of the process, and it was not a formal standard. Bachman was emphatic about this: the DBTG produced a report, and there is an important difference between a report and an ANSI standard. The work was reorganised in 1971, with the data description language passing to a separate CODASYL committee and the COBOL DML to the COBOL language committee; further specifications followed through the 1970s.

Vendors Adopt the Network Model; IBM Does Not

Report or not, it shaped the market. Haigh writes that while IBM refused to support the CODASYL approach, many other computer vendors endorsed the recommendations and eventually shipped systems incorporating them. The best-known implementations include GE's own successor, IDS/II, Univac's DMS-1100 and Digital Equipment's DBMS for VMS.

The most commercially successful system in this family, IDMS, shows how loosely "CODASYL" could be applied. Haigh calls it the most successful CODASYL system. Bachman's recollection is that Cullinane never changed IDMS from the original IDS specification, whereas GE did bring out IDS II to follow the CODASYL text. The family resemblance came from the shared ancestor as much as from the report.

IBM's absence mattered. Its IMS used the hierarchical model, and Haigh notes the DBTG chose Bachman's network approach over the less flexible hierarchical one that IBM backed. The database market of the 1970s therefore split along that line: IBM's hierarchical IMS on one side, CODASYL network systems from many of the other vendors on the other.

What the DBTG Gave the Database Field

The specific network model did not survive as the mainstream. Edgar Codd's relational model of 1970 attacked exactly what the DBTG had standardised: programs navigating owner–member sets one record at a time. By the end of the 1990s relational systems had eclipsed CODASYL ones.

But Haigh argues that the committee's lasting contribution was conceptual rather than technical. Its reports, he writes, were significant primarily for formulating and spreading the very idea of a "data base management system": a separate data definition language and data manipulation language, a schema describing the whole database and sub-schemas for each application's view, support for both batch and interactive use against one shared database. Codd's relational systems replaced the DBTG's data model, but kept this architecture, along with much of its vocabulary.