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.

IBM Systems Magazine is a trademark of International Business Machines Corporation. The editorial content of IBM Systems Magazine is placed on this website by MSP TechMedia under license from International Business Machines Corporation.