Db2 Origins of SQL: From SQUARE and SEQUEL to Mainframe SQL

SQL grew from relational research into Db2 work.

An embedded SQL statement in a COBOL program looks ordinary now:

EXEC SQL
    SELECT ACCT_NO, BALANCE
      INTO :WS-ACCT-NO, :WS-BALANCE
      FROM ACCOUNT
     WHERE CUST_NO = :WS-CUST-NO
END-EXEC.

That syntax has roots in IBM research from the 1970s. SQL did not start as a mainframe coding habit. It came from attempts to make the relational model usable by people who needed to ask for rows and columns without describing every physical access step.

This refresh keeps the original history intent, but connects the origin of SQL to Db2 and COBOL work: host variables, predicates, SELECT lists, bind packages, and optimizer choices.

Start with Codd's Relational Model

In 1970, E. F. Codd described the relational model while working at IBM. The important shift was logical data access. Data could be described as relations, which application developers usually see as tables with rows and columns.

That idea changed the question a program asks. Instead of saying, "follow this pointer, read this record, then read the next child," the program can state the result it wants:

SELECT EMPNO,
       LASTNAME,
       WORKDEPT
  FROM EMP
 WHERE WORKDEPT = :WS-DEPT

The database engine is responsible for the access path. The application is responsible for stating the required result correctly.

SQUARE Came Before SEQUEL

Before SQL, IBM researchers worked on SQUARE, commonly expanded as Specifying Queries As Relational Expressions or Specifying Queries in A Relational Environment in historical notes. SQUARE followed relational ideas closely, but it was not the friendly SQL syntax most developers recognize today.

The useful point is not the name expansion. The useful point is that early query language work tried to express relational algebra in a form programmers and analysts could use. SQUARE was part of that path, but it was not the final answer.

SEQUEL Made Queries Easier to Read

Donald Chamberlin and Raymond Boyce worked on SEQUEL, short for Structured English Query Language. SEQUEL aimed to make relational queries read more like structured English, while still keeping enough formal structure for a database engine to process.

The old spelling explains why many developers still pronounce SQL as "sequel." In practice, both "S-Q-L" and "sequel" are heard in Db2 shops. The spelling changed, but the idea stayed: use a declarative language to ask for sets of data.

SEQUEL Became SQL

The name SEQUEL was shortened to SQL. Historical accounts usually tie the name change to trademark issues. Over time, SQL became the language name attached to relational database products, standards work, and application programming interfaces.

For a mainframe developer, the name change is trivia. The language behavior is not. SQL lets a COBOL program describe data access with tables, columns, predicates, joins, ordering, and grouping.

System R Proved the Idea in Practice

IBM's System R project tested whether the relational model and SQL-style access could work beyond papers and small examples. It helped prove that a database engine could parse SQL, choose an access path, and support multi-user database activity.

That research path later influenced commercial products, including IBM SQL/DS and Db2. The related Db2 Early Vendor Implementations article covers the vendor side of that timeline.

Why SQL Fit Mainframe Applications

Mainframe applications handle repeatable business rules: account lookups, policy updates, claim checks, nightly batch selection, and CICS transaction reads. SQL fits that work because many requests are naturally set-based.

Business request	SQL expression	Mainframe effect
Find active accounts for one customer	WHERE CUST_NO = :WS-CUST-NO AND STATUS = 'A'	COBOL passes host variables and processes qualified rows.
Read unpaid claims over a threshold	WHERE PAID_IND = 'N' AND CLAIM_AMT > :WS-AMT	Batch job can process a defined worklist.
List department employees	WHERE WORKDEPT = :WS-DEPT	CICS screen can fetch only rows for the current request.

SQL Changed COBOL Build and Runtime Work

When COBOL uses embedded SQL, the SQL is not treated like ordinary COBOL statements. A precompile step extracts SQL, creates a DBRM, and leaves calls that Db2 can process at runtime. The DBRM is then bound into a package or plan.

That build path is why SQL history matters in day-to-day maintenance. A small predicate change can require precompile, compile, link-edit, bind or rebind, promotion, and runtime verification. See Db2 Packages Guide for COBOL Static SQL for the package side.

Declarative SQL Still Needs Careful Coding

SQL is declarative, but it is not magic. A poor predicate, mismatched host variable, stale statistics, or missing index can turn a simple SELECT into a slow production path.

• Name the columns you need instead of using SELECT *.
• Use host variables with compatible Db2 data types.
• Write predicates that can use available indexes where the access path depends on them.
• Check SQLCODE and SQLSTATE after database calls.
• Use EXPLAIN and current statistics when a query becomes a performance problem.

The Db2 SQL Optimization Tips for COBOL Programs guide covers practical access-path review.

SQL Standards and Db2 Dialect

SQL later became a formal standard. The current ISO SQL family is published as ISO/IEC 9075, and ISO's SQL framework page describes the framework used by other parts of the standard to define SQL grammar and processing terms.

Production Db2 work still needs Db2-specific documentation. Standards explain the common language family; Db2 manuals explain what your subsystem supports, how SQL interacts with packages, and which syntax is available for a particular Db2 level.

How This Article Differs from the Vendor History Post

This post focuses on language origin: Codd, SQUARE, SEQUEL, SQL, and the SQL statement shape that reached COBOL programs. The previous vendor post focuses on products and companies: Oracle, Ingres, SQL/DS, and Db2.

Keeping those angles separate avoids duplicate search intent. Readers who want SQL language history can stay here. Readers who want product history can use the vendor timeline.

References for Further Reading

• ISO/IEC 9075-1:2023 SQL Framework
• IBM Db2 for z/OS
• Computer History Museum oral history: Donald Chamberlin

FAQ

Who created SQL?

SQL came from IBM research work led by people including Donald Chamberlin and Raymond Boyce, building on Codd's relational model and earlier query language experiments such as SQUARE.

Why was SEQUEL renamed SQL?

Historical accounts usually tie the name change to trademark issues. The language kept the same direction: a structured, declarative way to query relational data.

Why does SQL history matter to COBOL developers?

COBOL developers still use SQL through embedded statements, host variables, DBRMs, packages, and Db2 runtime calls. The history explains why the program states the result while Db2 chooses the access path.

The practical lesson is still visible in every EXEC SQL block: state the rows you need, define the host variables cleanly, and let Db2 do the access-path work under control.