Article URL: https://osadmins.com/en/ibm-i-os-400-the-database-operating-system/ Comments URL: https://news.ycombinator.com/item?id=49141937 Points: 13 # Comments: 6

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. 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 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 level. Another pillar of the architecture is the TIMI (Technology Independent Machine Interface) layer. Applications written for this system do not communicate directly with the processor but with a virtual layer. Only lower down does the SLIC layer (equivalent to the kernel and drivers) translate these instructions into machine code for the specific hardware. This solution, brilliant in its simplicity, ensures unprecedented backward compatibility. A program compiled twenty years ago on a processor with a completely different architecture will work today on the latest POWER11 processor without recompilation. The system will automatically translate the instructions. The unique approach to the database goes hand in hand with innovative memory management known as Single Level Storage (SLS). Dr. Frank Soltis pointed to this architecture as the key factor deciding the legendary performance of this platform. It is not a simple paging mechanism, but a total change in mindset that distinguishes this system from the competition. In this environment, an engineer does not have to worry about disk partitioning, drive letters, or mount points, because these concepts simply do not exist here. The system treats all available RAM and all hard drives as one gigantic, flat address space.