If we step back and look at the file structure I just described, we see a two-dimensional table, the rows representing records and the columns representing fields in the records. The developers reasoned the most efficient approach would be to build a System/38 file as a simple two-dimensional table in memory. They also thought processing performance would be enhanced if the table could be processed in place without the need to reorder the records with a sort. To accomplish this design, they built an index into the table in such a way that sorting would never be required (see “Machine Indexes” later in this chapter). In fact, they believed there would never be a sort program on the System/38.

But there was — and is — a sort program. Dick Bains wrote the program and named it “Conversion Reformat Utility,” probably to disguise what it was and to keep application developers from using it for new projects. This program was, however — and may still be today — the fastest way to sort and select records from large files. Jim Sloan, a former developer and planner who helped build the CL compiler, developed a user tool in his set of QUSRTOOLs that used externally defined field names as an interface to the sort.

As the database definition proceeded, Perry Taylor, one of the lead developers, came across an IBM technical report written by E. F. Codd. Codd, who is generally credited with creating the relational database, was working on a project called System/R (R for relational) at IBM’s research facility in California. Codd had defined a two-dimensional table, on which four primitive operations could be performed, for his database. The first operation he called order, which allowed either rows or columns to be processed in some order using a key field. The second he called selection, which allowed rows to be selected based on the value in a key field. The third he called projection, which allowed specific fields to be selected from the table. Finally, his fourth operation, which he called join, allowed multiple tables to be treated as if they were one large table. A relational database was simply a two-dimensional table with the operations of order, selection, projection, and join.

Perry immediately recognized that the System/38 developers were building a very similar database, with the exception that their database was missing the join. He telephoned Codd to tell him about the work in Rochester and to offer support for Codd’s ideas on database. But Codd’s reaction was that relational databases are only for large systems; a small system needs only a sort and a merge. According to Perry, the conversation was cordial. Perry likened Codd’s tone to that of the police officers in the O. J. Simpson trial when they were being cross-examined by defense attorneys — respectful, but not forthcoming. E. F. Codd and Perry Taylor never spoke again. Three years after the announcement of the System/38, the System/R database was announced as DB2 and was identified as the “first” relational database.² Because the System/38 did not originally have the join function, it was recognized as the first commercial database product with relational capabilities.

---

²After leaving Rochester, Tom Furey became the general manager of the DB2 organization. At that time, DB2 was about to celebrate its tenth anniversary. The press releases proudly pointed to DB2 as the first relational database. Tom had to remind them that the System/38 database was the first.

---

The Two Faces of Database

When we talk about a database, we are not referring to just some place to put data. We are talking about a database management system (DBMS). A DBMS is a framework for storing and retrieving data that includes definitions of what the data means, rules of data integrity and the mechanisms for enforcing them, and the operations for storing and retrieving data. A DBMS must have an interface so that users can access and manipulate the data. In this section, we introduce the two interfaces to the AS/400 DBMS: Data Description Specifications (DDS) and Structured Query Language (SQL). In later sections, we discuss the DBMS in detail.

When IBM first introduced the System/38, there were no standard interfaces for a relational database. So the designers had to develop a native interface that was unique to the System/38. Not surprisingly, the native DDS interface looked very much like the file system it was meant to replace. The designers provided several system commands and utility functions to manipulate the database. They also created instructions at the MI to perform operations such as read, write, update, and delete. Programmers could access these instructions directly from languages such as RPG and Cobol. For example, many AS/400 shops use DDS-RPG: DDS for data definitions, RPG instructions for data access. The native DDS interface from the System/38 was carried forward to the AS/400. System/38 applications continued to use the native interface. In fact, many users still favor this interface. Mainframe customers who have moved to the AS/400 also like the native interface, because it is similar to the one used by IBM’s large system database, Information Management System (IMS).

At about the time the AS/400 was being developed, an effort was underway in IBM, and in the industry, to standardize on SQL as the relational database language. SQL came out of System/R. Far from being quickly adopted, it took nearly a decade for SQL to emerge as the standard. Ingres for years used a competing language, QUEL, until it, too, succumbed to the trend. At its introduction in 1988, the AS/400 supported both the native DDS interface and SQL. SQL statements can be embedded directly into RPG, Cobol, and C programs. These SQL statements replace the native instructions such as read, write, and update. DB2/400 contains precompilers that translate the SQL statements.