TIMI – Protecting Investments and Integrity in IBM i

Today we deliver the next in the series of 25 chapters that are helping us celebrate the IBMi25 campaign, and today’s topic (bit.ly/ibmi25) is clearly one of the major reasons the IBM i operating system has endured while other platforms created around the same time have disappeared: the Technology Independent Machine Interface, affectionately known as TIMI.

I have written briefly about TIMI twice before; once in “The Layers of i” and again in “Why IBM i? Architectural Foundations.” Today, I’ll summarize what I said there, and go a little deeper to explain more of the value of this incredibly powerful piece of the operating system.

TIMI is both easy and difficult to describe. To an application, TIMI is a contract. TIMI provides interfaces that perform known functions, and the contract promises that those functions will continue, unchanged, no matter what hardware platform is used to implement them. This is a pretty easy concept, but how is it accomplished?

Each program that is compiled on IBM i gets turned into a set of TIMI instructions. Essentially, it gets compiled down to a set of intermediate code. For decades, that’s been a pretty common step for a compiler to take – get to an intermediate representation of the program before creating the machine-level instructions. One big difference, though, is that the compiler on IBM i does not go any further. It leaves the intermediate code connected to the program object, and then the lower levels of IBM i act on the intermediate code to translate it into the instructions used by the Power hypervisor and Power processor beneath the OS. IBM i does this only when necessary, not every time the program executes. Typically, the translation takes place once when the program is moved from one release of the operating system to a later one, and never again while it runs on that later release.

This architecture has allowed programs that were written decades ago, even as far back as the System/38, to run on each release of the operating system without being recompiled. As long as that intermediate version of the program is still attached to the compiled object, the translator can turn the program into executable instructions on the system.

Certainly operating systems may have a subset of their Application Programming Interfaces that guarantee that programs that use them will continue to work in the future, but even in these instances the programs must be recompiled. IBM i guarantees that a program, once compiled, will continue to run on any future version of the operating system without recompilation. Other vendors in the 1980s and 1990s tried to incorporate new system technology by forcing their users to recompile, and sometimes even to drastically modify their software. Faced with having to make significant investments, when they had already spent good money developing the software the first time, customers of those vendors were forced to examine whether they wanted to remain on a platform that did not protect their investments in the first place. Large numbers of those customers left, and the rest, as they say, is history.

As if that level of investment protection were not enough reason to appreciate TIMI, it also provides a level of system integrity that has made IBM i one of the most stable and virus-resistant platforms in the market.

Most of my readers have a background in computer programming, and they would have a basic understanding of the concept of a “pointer” in a programming language. For those of you who don’t have such a background, a “pointer” is used to perform an operation on a piece of data stored in a computer’s memory. But, you see, the memory is also where the program itself runs, and it is also where the operating system runs. Everything that runs on a computer runs in the memory. Programs need to have pointers to the data the programs are using. But, if a program has an errant pointer into memory that it should not have, it might write into that memory. And if it can write into that memory, it could put erroneous information into the memory, causing the program to perform erratically. It could even insert malicious code into the program or into the operating system.

On IBM i, this cannot happen. It is architecturally prohibited because of TIMI and the way TIMI’s instructions get translated and run on the Power processor. As I mentioned above, each user program is compiled to an intermediate form, so all uses of “pointers” in those programs are also in intermediate form. The pointers created by user programs are not allowed to point at the parts of memory used by the operating system, so there is no way those user programs can possibly harm the OS, nor can they place malicious code into it. This protects the integrity of the operating system – keeping viruses and other malware from tapping one of their most insidious paths into a system.

I’m afraid I have simplified this quite a bit, and I have only scratched the surface of the power TIMI brings to the IBM i operating system, but I hope I’ve given you a feel for just how critical its role has been in ensuring that our clients can move forward as technology changes. After all, the only thing we can always be certain of, when it comes to technology, is that it will change. Having an architecture that doesn’t simply tolerate change, but at its core was built to embrace change, ensures that your investment and your system will be protected long into the future.