The AS/400 Machine Interface, and Why IBM i Endures

In the early to mid 1990s, I built a native Xmodem and Ymodem file-transfer toolset, and the asynchronous communications layer beneath it, for the AS/400. (I also wrote a Zmodem implementation that I never published.) These protocols move a file in numbered blocks and verify each block with a CRC, a checksum that changes if any byte changes, so a corrupted block can be caught and resent. Those CRC routines, a CRC16 for Xmodem and Ymodem and a CRC32 for Zmodem, run on every block, so they have to be fast, and each is a tight loop of bit-level operations. The business languages the platform was built for were not designed for that kind of work, and C was not yet commonly available. So I wrote them at the level underneath: the machine interface.

I lost that original code long ago, and the exact instructions are not the point of this article. What stayed with me is what working at that level taught me about how the AS/400, now IBM i, is built. That architecture is the reason these systems are still running decades later, and the reason I treat them as worth modernizing rather than discarding.

What the Machine Interface Was

Most computers expose their hardware fairly directly: the instruction set you program against is, more or less, the instruction set the processor runs. The AS/400 was deliberately different. Between your programs and the physical hardware sat a defined boundary called the Machine Interface, or MI.

The MI is a complete, hardware-independent instruction set. Programs were compiled not to the processor's native instructions but to MI-level program templates. Below the MI, a layer IBM calls the Licensed Internal Code translated those templates into whatever the actual hardware underneath understood. Your program targeted the interface; the hardware was an implementation detail beneath it.

The MI instruction set is higher level than the assembler most programmers picture. It includes operations for arithmetic, for manipulating storage and pointers, and for creating and operating on system objects directly. It is documented in IBM's Application System/400 Machine Interface Functional Reference (Version 2, SC41-8226-02).

Writing to the Machine Directly

Working at the MI level meant thinking the way the machine thought. For a CRC routine, that was exactly what I wanted: a tight, predictable loop close to the hardware, without the overhead of a language built for business reporting rather than bit manipulation.

Creating an MI program was not like editing and compiling an ordinary program. You assembled MI source into a program template, and the system's translator turned that template into something executable. It was unforgiving, detailed work, but it gave a level of control the high-level languages of the day could not.

That control came with a lesson I did not fully appreciate at the time. Because I was writing to the interface rather than to the hardware, the work was not tied to any particular processor. The interface was the contract, and IBM had reserved the right to change everything beneath it.

Single-Level Store and the Object Model

The machine interface was one of several decisions that made the platform unusually durable. The AS/400 also used a single-level store, treating memory and disk as one large address space so that programs addressed objects by pointer regardless of where they physically lived. And it was object-based: a program, a file, a queue were all typed objects the system understood and protected, not just bytes on a disk.

Taken together, these choices describe a machine designed around stability and integrity rather than around any one generation of hardware. The relational database was built in, not bolted on. The result is a platform that resists the slow decay that affects systems assembled from loosely connected parts.

Why a 1980s Design Is a Present-Day Advantage

It is easy to look at a system first sold in 1988 and assume it is a liability. The opposite is often true. The architectural decisions that let an application survive a processor change from CISC to RISC are the same decisions that let your business logic keep running, accurately, across decades of hardware and operating-system upgrades.

That is why I do not start from the assumption that an IBM i system should be replaced. The durable core is usually the most valuable thing the business owns. The practical work is connecting it to everything around it, modernizing the interfaces people actually touch, and keeping it supported, rather than discarding decades of proven logic to chase a rewrite.