The Origins of the IBM i: A Trip Through Computer History

Don't worry: We won't discuss how the IBM i was once the eServer iSeries, and before that, the System i5. That story has been told, and it is a boring one.

No, we will skip over the contemporary history and go straight back to the beginning of time, I mean, of the AS/400, and, cover three of the central concepts of the platform, which characterized the AS/400 then and to this day still characterize today's IBM i: single-level store, the layered OS, and objects.

Single-Level Store

Single-level store is the capability to address stretches of RAM and stretches of other storage that is not quite as fast as RAM, but still fast enough to be useful, through a single kind of memory address. *

Essentially if you look at it and squint a bit, single-level is virtual memory. Yes. Really. That is what virtual memory does: Letting you treat slow memory and fast memory through a single kind of address.

The first implementation of virtual memory was in the Atlas** OS in 1962. (When I say "first implementation", I know I am asking for the wrath of the Gods and for sure someone will point out that Babbage, or Zuse, or Vannevar Bush did something that in some way can be interpreted as virtual memory.) Atlas influenced Multics***, Multics begat IBM's TSS/360, TSS/360 begat IBM's Future System, an eventually abandoned project that however heavily influenced System/38, which was merged with other technology into the AS/400.

• Atlas: Single-level store - Wikipedia
• Multics: FAQ Multics General (faqs.org)
• TSS-360: A time-shared operating system
• System/38: IBM_System_38_Technical_Developments_Dec1978.pdf (mirrorservice.org), p. 48

Hardware Independence & Machine Interface

George Radin, one of IBM's architects, stated in an internal IBM memo from 1971:

I have been asked very frequently of late to explain the purpose of the ADI, EDI, and NMI as the major FS interfaces. ...

(Source: radin_adi_11_23_71.pdf (clemson.edu))

The ADI, EDI and NMI were three interfaces that were conceptually stacked one on top of the other. This stacking was a crucial piece of the the high-level architecture of the Future System project.

Mark Smotherman, in IBM Future System (FS) — 1970s, describes the roles of these interfaces as follows:

• ADI — application development interface — provided by a single optimizing compiler

• EDI — execution discipline interface — provided by an OS

• NMI — new machine interface — provided by hardware and microcode

Source: Overview of IBM Future System -- Mark Smotherman (clemson.edu)

That sounds a bit cryptic, so let's translate it. The ADI is the entirety of what we would call APIs today. We are used to those being shipped with operating systems today, but 'twas not always so. In the proposed architecture, a compiler would compile down from high-level language programs using those APIs to the next-lower level.

Underneath the ADI layer, the EDI and NMI deal with the dirty job of presenting a consistent virtualized machine to the unwitting higher-up levels. I know you paid attention in your philosophy classes, so this will have immediately and mightily struck you as an application of Descartes' concept of a demon that presents a fictitious outer world to an unassuming mind. Not to be confused with Maxwell's demon, of course. But I digress.

The EDI corresponds to the "Machine Interface" or MI in today's IBM i (aka TIMI, the "technology independent machine interface", in previous iterations of the platform's marketing).

The motivation was for EDI was, in Radin's words:

... to define a logical machine which would be functionally invariant under different processor/storage/memory/I/O configurations... a level which effectively masks all physical configuration differences from programs above it.

And in 1971, an IBM internal report mentions:

The Endicott Advanced System Group has worked on ... [an] effort during the past several years. ... recently, Endicott ASG representatives have worked with ... Ray Larner, who has formulated a proposal for a high level interface called M1 (Machine Language).

Source: AFS_Fundamental_Concepts_and_System_Lanuage_3ed_Mar1971.pdf (mirrorservice.org), page 9

The NMI is what we would call the firmware/driver level.

The underlying reason for this stratification, which Soltis mentions in Inside/AS400, were two trends: increasing processor power, and a desire to develop software using higher levels of abstraction than were provided by low-level programming languages. Ultimately, these trends aimed at making the development process more efficient (and, it is my unproven assumption, less boring). From the "top", the drive towards higher-level languages was pulling the design up, while at the "bottom", the greatest efficiency gains were tied to simple processor instructions, keeping the design weighed "down". What to do?

Already in the 1970s, it became clear that trying to map higher-level language concepts directly to silicon would not work. Yes, you could, in theory, directly turn high-level commands like "Make me a database file" into silicon circuits, but doing so would make your chip layout very complex and very inflexible. As Soltis found, with the technology available in the 1970s, it would also run like a bear. And I don't mean any bear; I mean a bear on tranquilizers that just had had a big meal and absolutely could not be bothered. Tranquilizer bear.

The solution for this bear of a problem—the pulls in opposite directions from the "top" and the processor "bottom"—was to add layers that successively translate from the "Make me a database file" at the top level to whatever dance of electrons is finally executed on the processor itself. Layering effectively decouples these requirements from each other, giving a system the flexibility to satisfy both (at the cost of additional development work for the new layers). Today, this layering is standard; your Windows, Mac, ... you name operating systems, have hardware abstraction layers and nobody even pays attention to it. But back at the beginning of the 70's, this was so advanced, it might as well have something that Scotty used on Star Trek.

A very similar layering has happened inside processors: Both the POWER and the X86/X64 are layered systems-within-a-system. Both processor families feature an external interface, the instruction set, that supports high-level-ish commands like "AES-encrypt me these data". Inside the processors themselves, a microcode layer translates those instructions into the actual low-level, much simpler multiplications, additions, byte shifts, ... which the actual hardware does very efficiently.

Of course, if you go back even further in computer history, you will find that in a kind of primordial pre-electronic ur-computer, data and programs were all mushed together, and that dividing them into hardware and software had been the first layering.

Anyways, the future is layers.

Object Orientation

Objects in the general, everyday meaning of the word are something that is so common to us, it is difficult to even try to describe the world without referring to them. We are by virtue of our biological "hardware" primed to interpret the onslaught of data that we receive from our senses as belonging to objects with shapes and a certain stick-around-ness, what biologists refer to as "object perception" and "object persistence". Objects, space, time, and relations between them are how we think of the world.

Given that biological heritage, it was only a matter of time until objects would find their way into of programming. (Programming can only deal with mathematics, logic, and metaphors about things in the physical world. The proof of this statement is left to the reader.)

The same 1971 report that introduced the "Machine Language" also describes the now-familiar concept of objects and their relevance for an operating system:

The association of a process with every resource derives trom Dijkstra's approach in T.H.E. Multiprogramming System and from Ule-Johann Dahl's approach to objects in SIMULA 67. Dijkstra associates a process with every resource in his system; the process is solely responsible for allocating that resource and acts as a central clearinghouse for all accesses to it. ...all objects ... have the properties of Dijkstra's resources and naturally fit into a general scheme of resource management. ... simulation languages might provide a suitable basis for an operating systems language since they have the best developed concepts of event and process; the AFS concept of objects as processes is a generalization of the objects in the simulation language SIMULA 67.

It was the SIMULA programming language that first introduced a "processes" concept, which eventually became the concept of the things that are involved in processes: objects. All of today's object-oriented technology is ultimately based on SIMULA, be it C++, Java, Visual Basic, PowerShell, Rust, etc. etc. And the IBM i.

SIMULA had been developed in the 1960s by Ole-Johan Dahl and Kristen Nygaard at the Norwegian Computing Centre. From 1949 to 1950, Nygaard had worked on mathematical simulations, used to create Norway's first nuclear reactor. At that time, those calculations were carried out manually. Dahl, in the 1950s, could already use computers to carry out his simulations for operations research. When the Norwegian Computing Centre felt a need to improve existing programming languages, Dahl's and Nygaard's experience with simulating physical processes and physical objects became a major factor in the design of a language that could model both.

Object orientation covers several concepts, and the IBM i only includes a subset of those. The most important object-related concepts for the IBM i are:

1. Objects have types.
2. Objects "contain" or "store" data.
3. An object's type defines how the data "in" (another physical metaphor) can be used.

Or, to quote from the 1971 IBM report :

An object is the basic entity in the system; lt has an active part called an access machine and a passive part called an owned resource. Its active part responds to requests by other Objects and may in turn generate requests of its own.

Two years before that report, Nygaard had been able to convince IBM that SIMULA was the future, and IBM had donated 240 hours of computing time for the development of a SIMULA compiler for the IBM/360/370 platform. IBM not only assumed that SIMULA would make its platform more attractive; it also did not want to cede ground to its competitor Univac, who had already committed to creating a SIMULA compiler for their platform. IBM's SIMULA compiler was released in 1972.

The use of objects in IBM i has several advantages, and security is one of them. Unlike other operating systems, IBM i does not simply allow you access data directly; you have to do it through the "access machine" of the object. You can only do with an object of type "file" what the IBM i OS developers thought you should be able to do with files. Contrast this to other operating systems where you can simply read from, or write into a file's (or spreadsheets) bytestream. A whole class of security issues is obliterated by not allowing such frivolous byte manipulation. Of course, there are enough other types of security issues on an IBM i—it is still a computer!

But more of that another time. For today, I hope you enjoyed this little trip down memory (or storage) lane. Let me know if you thought it was worth your time!

Footnotes

* The IBM i has a specific flavor of single-level store. If you are interested in the details, I recommend Mark Funk's excellent article on The Next Platform (another publication of Timothy Prickett Morgan's).

** This ATLAS is the British supercomputer from the 1960s, not to be confused with the special-purpose codebreaking computer developed in the 1950s in St. Paul, Minnesota.

*** Multics was the predecessor of the first Unix. "Multi"= many, "uni" = one—the inventors of Unix wanted to rub it in that their system was simpler. The first Unix begat many other Unix operating systems, including IBM's own brew, AIX, a much-reduced version of which can be found on IBM i partitions in the form of PASE; while another much-reduced and specialized version of AIX runs on POWER and handles I/O. You know it as VIOS. Of course, Unix indirectly brought into existence Linux, which also runs on POWER. As you can see, these developments make for a satisfyingly convoluted bloodline.