IBM i – I’m Impressed

From what little I had heard and read, the IBM AS/400 (later known as iSeries, and now known as simply IBM i) sounded like a fascinating system. I knew that it had a rich OS stack that contained most of the services a program needs, and a JVM-style byte code format for applications that let it change from custom processors to Power Architecture without impacting users at all.  It was supposedly business-critical and IBM-quality rock solid. But that was about it.

So when Software Engineering Radio episode 177 interviewed the i chief architect Steve Will, I was hooked. It turned out that IBM i was cooler than I imagined. Here are my notes on why I think that IBM i is one of the most interesting systems out there in real use.

Independence of Processor

IBM i uses a byte code format for application programs. This byte code (known as technology-independent machine interface, or TIMI) is quite unlike what we have in the JVM or CLR. First of all, it predates the JVM by about 15 years. The first generation of systems, the IBM Series 38, came out in 1980. Second, the TIMI code contains many higher-level operations like database accesses, making it possible to generate far better executable code than if it was just plain API calls. Third, it is compiled before execution, and not just-in-time.

The TIMI was designed as the designers even in 1972 realized that processors will come and go, but software will remain. I would guess that the IBM experience with the System/360 and migrating software to it from older system had something to do with this.

Over its life time, IBM i has gone from the original System 38 CPU to the AS/400 CPU to a customized 64-bit POWER CPU (still called AS/400), and now to a completely standard Power7 processor. Indeed, I did not realize until now that IBM merged the pSeries and iSeries hardware in 2008. Today, IBM i is just a software stack running on a hardware platform that can just as well run AIX or Linux! That is quite a journey for a system over 30 years, and proves that the original design was amazingly sound.

There seems to have been at least one slight imperfection in continuity. The original design used 48-bit pointers, which was very far-sighted for a design team in 1972, when the biggest machines around used 24-bit pointers (like designing a 128-bit pointer into a system of today as the default). Still, this did become too small, and a change was made to 64-bits in 1995 (when the almost-PowerPC RS64 became the processor for the AS/400).  Apparently, this required some side-band information about a program to allow patching even the TIMI code in the right way.

Integrated Database

The i OS (I guess Apple just beat IBM to the trademark, since iOS would seem the natural name for the OS, right?) is an integrated environment that tries to do a lot of things for the user that would normally require third-party software. In particular, it has a database integrated, which can both be accessed from i APIs and lately over SQL. It is branded as “DB2″ and DB2-targeting programs sees no difference between it and DB2 running on AIX. But according to Steve, the core is not DB2 but the database that was built into IBM i from the start.

Integral Security

Where IBM i really stands out is in the decision to forgo the traditional concept of a file system and instead rely on an object storage concept. This has tremendous advantages for security. Both since access rights are powerful and attached to objects, and by avoiding all the dangers of a typical file system. For example, there is no way to make a document executable. Programs are programs, data objects are data objects, and you cannot make a Windows .exe masquerade as a .jpg. All users are associated with a user profile indicating what they can do and work with.

This does require some special treatment for users like programmers. Programmers are always a problem, since they need to create new programs. Same thing with the no-execute protection in recent Windows operating systems and just-in-time compilers. The i solution is to have a special programmer role with special permissions.

Importing APIs

Just like IBM zEnterprise (the latest name for the heritage from System/360), the IBM i system has been modernized in recent years by adding support for many standard APIs and concepts from mainstream computing. They can run Java and use JDBC, for example. IBM does not seem to hesitate to help programmers reuse code written for other platforms on their heavy-duty machines.

A funny part for i is that they had to add a virtual file system in order to make Java happy. Apparently, a JVM cannot work or run most programs without accessing a file system. So, Java pretty much assumes the machine has a file system. Typically a true assumption – except on IBM i.Thus, IBM i Java machine simulates your average hierarchical file system on top of its real data storage mechanisms!

It is also interesting to note the choice in programming languages added to the platform. Java is a given, but IBM has made a big splash around PHP! Turns out that many business applications are migrating towards that kind of web-based platform. PHP replacing COBOL? Not sure that is an improvement…

Internal Tuning

One design goal of IBM i from the outset was to create a system that would be easy to use. In particular, the need for system administrators should be minimal. I don’t know how well this works when it comes to dealing with adding users and things like that, but I guess that if you use roles appropriately, it will be hard to mess that up.

What is more interesting and subtle is the extent to which IBM i tries to avoid needing system administrators around to tune the machine performance. Normally, if you have a large database, you will need to manually tune and tweak the system for maximum performance. In IBM i, the idea is that the system takes care of that for you. There must be a lot interesting algorithms at work in the core of the system for this to work, but apparently it does work.

For example, the handling of the storage hierarchy is transparent to programs. A program allocates an object, but has no idea if it lives in RAM or on disk. The system moves things around as needed to reach the performance needed (you set goals for each subsystem). When solid-state drives were added to i a few years ago, that just introduced yet another level of the storage hierarchy, and the OS core took care of managing it. User programs did not need to change at all. That is pretty cool!

My gut feeling is that this is thanks to the higher-level APIs compared to many other systems, which gives the system a clearer view of what a program is trying to achieve. Working on system-defined objects with known types sure beat trying to make sense of uninterpreted strings of bytes coming out of your typical file-system-oriented program.

Overall, IBM i impresses me by implementing a series of unique and innovative technologies that is largely different from the more well-known UNIX-style of OS design that rose in parallel to the development of IBM i. It demonstrates that there are technical alternatives to the mainstream, and that doing things differently can indeed be a very goo idea. Refreshing, in a world where too many things are me-too designs that just follow the majority herd of thinking.