IBM i (OS/400) The Database Operating System – OSAdmins

Skip to content

Switch to dark mode

Open Search

Search for:

Choose a language<br>🇺🇸 EN<br>🇵🇱 PL

Main Menu

Today, I wanted to show you one of the most fascinating and surprising operating systems ever created. It’s not another Unix, Linux, or Windows. It is an architecture that went its own way and proved that systems engineering design can look completely different.

I’m talking about IBM’s child, which for many might be synonymous with "boring banking systems," but in reality, is one of the most uncompromising projects in IT history. While we get excited about abstraction and virtualization today, thinking we are discovering new lands, this system was doing it decades ago. Imagine a system that doesn’t know the concept of a "file" in the way we understand it. A system where everything is an object, and all disk and operational memory form one vast, flat space. If you are looking for proof that true engineering doesn’t need buzzwords to blow you away, I invite you to read on.

The Birth of AS/400 (IBM i)

To understand this phenomenon, we must go back to the 1980s and transport ourselves to the IBM laboratory in Rochester, Minnesota. This is where the project codenamed "Silver Lake" was born. Engineers faced the breakneck task of merging two different worlds. On one side, we had the System/38. It was a machine ahead of its time, already boasting an integrated relational database and innovative memory management, but it was expensive and difficult to use. On the other side was the incredibly popular System/36, prized for its simplicity and intuitive interface, though architecturally much simpler.

The goal of the Silver Lake project was to create a platform that adopted the technological power of the System/38 and clothed it in the user-friendliness of the System/36. The result of this work was the premiere of the AS/400 (Application System/400) platform in June 1988. It should be noted that AS/400 refers to the hardware/platform, while OS/400 was the dedicated operating system. The architecture designed by Dr. Frank Soltis was not just a compromise, but a technological leap. A key assumption was protecting client investment in software. Thanks to the TIMI (Technology Independent Machine Interface) abstraction layer, companies could migrate their applications from older systems to the new platform without rewriting code from scratch. This approach defined the system’s identity for decades to come. Although the marketing name changed many times—from AS/400, through iSeries, System i, to the current IBM i—the foundation poured by Soltis in Rochester remained intact. It is this continuity that allows a program written in 1990 to run natively on a server produced this year. The AS/400 hardware no longer exists, but the operating system remains and runs on the IBM Power platform.

A Database Operating System

In the software world, we are used to a clear division. We have the operating system managing hardware and applications running on top of it. In a typical Windows or Linux environment, a database like Oracle or SQL Server is just another program that needs to be bought, installed, and maintained separately. In the case of IBM i, the situation is completely different, and this aspect constitutes the absolute uniqueness of this platform. Here, the relational database Db2 for i is not an overlay. It is built directly into the system kernel, below the machine interface level.

This architecture makes the operating system and the database an inseparable unity. The OS does not treat a data table like an ordinary stream of bytes on a disk whose content is indifferent to it. The operating system perfectly "understands" the structure of business data and treats an SQL table like any other native system object. Thanks to this, mechanisms such as authorization, space management, or record locking are handled at the lowest, most efficient kernel level, not by an external application fighting for CPU resources. This approach eliminates communication overhead and has made the platform dominant in OLTP (Online Transaction Processing) for decades.

The Object Nature of the System

The philosophy of this system stands in opposition to the Unix approach of treating everything as a file. In IBM i, the fundamental unit is the object. Whether we are talking about a program (*PGM), a data file (*FILE), or a user profile (*USRPRF), every resource has a strictly defined structure with a header and a functional part. Such a construction drastically raises the level of security through the mechanism of encapsulation. The system simply will not allow you to edit a compiled program in a text editor or execute code that has not been correctly processed. Access to the interior of an object is possible only through interfaces and commands defined by the system. Thanks to this, viruses or malicious scripts trying to overwrite executable code hit a wall at the system...