IBM i Architecture: How TIMI and SLIC enable hardware independence

IBM i represents a fundamentally different approach to enterprise server architecture compared to modern systems. While contemporary infrastructure relies on containerization and microservices, IBM i employs a sophisticated layered architecture built on two core concepts: TIMI (Technology Independent Machine Interface) and SLIC (System Licensed Internal Code), working in conjunction with LPAR (Logical Partitions) for isolation.

Understanding these components reveals why IBM i systems have remained relevant and reliable for decades, enabling seamless hardware upgrades where 30-year-old applications run unmodified on modern processors without recompilation. This architectural approach solves the fundamental problem of hardware lock-in — a challenge that continues to plague modern enterprises.

This article explores how TIMI and SLIC work together to create an operating system that achieves true hardware independence, and how LPAR complements this architecture by providing isolated execution environments on a single physical server.

Part 1: TIMI — The Hardware Independence Layer

What is TIMI?

TIMI (Technology Independent Machine Interface) is an intermediate bytecode representation that sits between your compiled source code and the native machine code executed by the processor. When you compile an RPG, COBOL, or C program on IBM i, the compiler doesn’t generate native machine instructions for the specific processor. Instead, it produces TIMI instructions — a high-level, hardware-independent representation that the operating system later translates into actual CPU instructions.

The Problem: Hardware Lock-In

The fundamental problem TIMI solves is hardware lock-in. Historically, when a company invested in enterprise systems, their applications were tightly coupled to specific processor architectures. Upgrading to new hardware meant:

- Complete recompilation of all source code

- Rewriting sections of code for new instruction sets

- Testing everything from scratch

- Business disruption and massive costs

- Risk of introducing new bugs during recompilation

IBM i solved this elegantly with TIMI. Instead of compiling directly to processor-specific instructions, TIMI acts as an abstraction layer. Your compiled program is independent of whether the underlying hardware uses IMPI (48-bit), PowerPC, POWER8, POWER9, or POWER10 processors. This separation of concerns — keeping application binaries independent from processor architecture — is the key to effortless hardware upgrades.

How TIMI Works

When you compile a program in IBM i:

RPG/COBOL Source Code
↓
Compiler
↓
TIMI Bytecode (hardware-independent)
↓
Stored in Program Object
↓
When Program Loads:
├─ SLIC translates TIMI → Native Machine Code
└─ Native code cached for future execution

TIMI instructions operate on objects rather than memory addresses. In IBM i, everything is an object: programs, files, data areas, libraries. This object-oriented approach at the OS level (not just the application level) fundamentally differs from traditional Unix/Linux systems where the kernel manages raw memory locations and file descriptors.

The crucial insight is that TIMI bytecode is persistent. It’s stored alongside the native machine code in your program object, remaining dormant but available for re-translation if the hardware changes.

Two TIMI Instruction Formats

IBM i implements TIMI in two formats:

OMI (Original Machine Interface): Essentially compatible with System/38 machine interface instructions. OMI provides remarkable backward compatibility, allowing programs written in the 1980s to still execute on modern hardware.

NMI (New Machine Interface): A lower-level instruction format resembling W-code intermediate representation. When IBM transitioned from IMPI to PowerPC processors, they didn’t ask customers to recompile everything. Instead, they converted OMI instructions to NMI automatically — maintaining compatibility without requiring any customer action.

The PowerPC Transition: TIMI in Action

The 1995 transition from IMPI to PowerPC architecture demonstrates TIMI’s transformative power. IBM didn’t ask customers to:

- Recompile applications

- Modify source code

- Retest everything

- Upgrade gradually with uncertain outcomes

Instead, customers transferred their compiled TIMI bytecode (stored in program objects) to the new PowerPC hardware, and everything ran. This wasn’t emulation — TIMI bytecode was translated to native PowerPC instructions, maintaining full performance. Applications from 1987 could run on 1995 hardware without modification.

This same principle continues today. When IBM announced the POWER10 processor, existing IBM i applications continued running without any action from their owners.

Observability: Storing TIMI Alongside Native Code

IBM’s insight was to store both the TIMI bytecode and the compiled native machine code together in program objects. This “observability” serves multiple purposes:

1. Future Processor Transitions: When new hardware arrives, IBM can re-translate TIMI to new native code without requiring user recompilation

2. Automatic Optimization: IBM can automatically optimize code for new processors (e.g., leveraging POWER8’s advanced features) without touching user source code or requiring action from application owners

3. Debugging and Analysis: System administrators can examine the TIMI representation for diagnostics

4. Permanent Preservation: Your application logic remains intact in TIMI form, immune to processor obsolescence

This dual storage means your program objects are never truly “locked” to specific hardware — they can be transparently migrated to newer processors indefinitely.

Part 2: SLIC — The Translation Engine and Operating System Core

What is SLIC?

SLIC (System Licensed Internal Code) is IBM’s proprietary, closed-source runtime layer that translates TIMI bytecode into native machine code and manages the entire IBM i operating system. Unlike Unix/Linux which have traditional kernels with published APIs and, often, available source code, IBM i’s core is wrapped in Licensed Internal Code — protected by licensing agreements and IBM’s intellectual property.

Why “Licensed Internal Code”?

The name reflects IBM’s strategic approach to protecting their innovation:

Licensed: This code is proprietary to IBM and governed by strict licensing agreements. Users cannot modify, study, or redistribute SLIC. You’re not buying the code — you’re licensing the right to use it. This licensing model allows IBM to make changes to SLIC without backward compatibility concerns that would plague open-source projects.

Internal: SLIC is not exposed to users. Unlike Linux kernels where developers can read source code and understand kernel behavior, SLIC operates as a black box. Developers interact with IBM i’s object model abstraction, not the underlying implementation. This allows IBM to optimize the translation process, change internal structures, and innovate without exposing implementation details that users might depend on.

Code: It’s the actual executable software that manages all IBM i platform operations.

This licensing approach gave IBM tremendous freedom. When they needed to transition from IMPI to PowerPC, they could modify SLIC’s translation engine without updating every customer’s application. When optimizations are discovered for a new processor generation, SLIC can automatically apply them without user involvement.

What SLIC Does

SLIC performs three critical functions:

1. TIMI Translation

SLIC translates TIMI bytecode into native machine code for the specific processor. This translation happens ahead-of-time when a program is loaded into memory, not during execution. Here’s the critical distinction: TIMI translation is expensive work, but it only happens once per program load.

When you run a program:

- SLIC examines the TIMI bytecode

- Translates it to native machine code optimized for the current processor

- Stores the translated code in memory

- Subsequent execution runs at full native speed

The translated native code is cached, so if the program runs again, SLIC recognizes it’s already been translated and uses the cached version.

2. Operating System Management

SLIC manages all traditional OS functions:

- Storage management and memory allocation

- Pointer and address management

- Program and process management

- I/O management (file systems, network, devices)

- Security and access control enforcement

3. Object-Based Abstraction

SLIC enforces IBM i’s unique object-based model. Rather than managing raw memory locations or file descriptors, all resources (programs, files, queues, data areas, libraries) are managed as named objects with properties, ownership, and permissions. This object model permeates everything in IBM i, from file systems to program calls.

Why SLIC’s Overhead Is Minimal

A natural question: Won’t translating TIMI for every LPAR create bottlenecks?

The answer is no, and here’s why:

Hardware-Accelerated Operations: SLIC operations aren’t purely software. Critical operations like TIMI translation and context switching are implemented in firmware and hardware microcode, not as interpreted software running on top of the CPU. This is fundamentally different from a traditional kernel that runs as software on the processor.

Ahead-of-Time Translation: TIMI translation happens once when a program loads, not millions of times during execution. The expensive translation work is front-loaded, leaving program execution as pure native machine code.

Minimal Runtime Involvement: During actual program execution, SLIC only intervenes when necessary (resource contention, I/O operations, partition boundary crossings). Most of the time, your code runs as compiled native machine code with no SLIC involvement.

Enterprise deployments routinely run 10–20 LPARs on single servers with performance overhead of only 1–3%, proving that SLIC’s overhead is negligible.

SLIC vs. Traditional Kernels

The fundamental difference between SLIC and Unix/Linux kernels:

Part 3: LPAR — Logical Partitioning and Isolation Architecture

What is LPAR?

LPAR (Logical Partition) divides a single physical IBM Power System server into multiple independent, isolated execution environments. Each LPAR operates like a separate physical server, with its own operating system, memory, CPU resources, and I/O channels — all sharing the same underlying hardware.

Why IBM Introduced LPAR

Before LPAR, enterprises requiring separate environments (production, test, development, disaster recovery) had to purchase multiple physical servers. This was expensive, inefficient, and wasteful:

- High infrastructure costs

- Significant power consumption

- Complex data center management

- Underutilized hardware in most partitions

LPAR solved this by enabling one expensive high-end server to host multiple isolated environments, dramatically reducing infrastructure costs while maintaining complete isolation.

How LPAR Works

Imagine a physical IBM Power System with 16 CPU cores and 128GB RAM:

IBM Power System (Physical Hardware)
├── Total: 16 cores, 128GB RAM, I/O channels
├── LPAR-Production
│ ├── Allocated: 8 cores, 64GB RAM
│ ├── Runs: IBM i OS (independent instance)
│ └── Isolation: Complete hardware-level separation
├── LPAR-Test
│ ├── Allocated: 4 cores, 32GB RAM
│ ├── Runs: IBM i OS (independent instance)
│ └── Isolation: Cannot access Production's memory or resources
└── LPAR-Dev
├── Allocated: 4 cores, 32GB RAM
├── Runs: IBM i OS (independent instance)
└── Isolation: Cannot access other LPARs' resources

Each LPAR runs a completely independent IBM i operating system instance. If Production’s system crashes, Test and Dev continue running unaffected. If a developer’s runaway query consumes all of Dev’s CPU, Production’s guaranteed allocation remains unaffected.

Hardware Isolation: The Key Difference

LPAR isolation happens at the hardware/firmware level, managed by IBM PowerVM, the hypervisor layer built into the processor complex. This is fundamentally different from process-level isolation in traditional operating systems:

Physical Separation:

- Each LPAR receives dedicated CPU cores that other partitions cannot access

- Each LPAR’s memory allocation is physically isolated at the hardware level

- I/O devices are allocated to specific LPARs or virtualized

Hardware Enforcement:

- The CPU’s memory management unit enforces partition boundaries

- One LPAR’s code literally cannot access another LPAR’s memory addresses

Get Hemanth D’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

- If Production has a security vulnerability, it cannot breach into Test’s address space

Fault Isolation:

- One LPAR’s OS crash cannot corrupt another LPAR’s memory

- A hardware error in one partition doesn’t affect others

- Enables independent troubleshooting and diagnosis

This is significantly stronger isolation than container technologies, which share the same OS kernel and rely on software mechanisms (namespaces, cgroups) for isolation.

LPAR Sizing: Planning for Hardware Independence

When purchasing an IBM Power System, you must determine your LPAR requirements before delivery:

Step 1: Identify Required Environments

- How many isolated environments do you need? (typically: Production, Test, Development)

- What are the workload characteristics for each?

- What are peak resource requirements?

Step 2: Size Each LPAR

Based on workload analysis:

- Production LPAR: 8 cores, 64GB RAM (handles peak transaction load)

- Test LPAR: 4 cores, 32GB RAM (mirrors production at smaller scale)

- Dev LPAR: 2 cores, 16GB RAM (developers need less resources)

Step 3: Add Overhead and Growth

- Total from above: 14 cores, 112GB RAM

- Add 20% headroom: 17 cores, 135GB RAM

- Purchase: Server with 18 cores, 144GB RAM

Step 4: Communicate Requirements to IBM

When placing your order, specify your LPAR requirements. IBM’s solution architects will recommend the appropriate Power System model with necessary capacity.

Can You Add LPARs After Purchase?

Limited flexibility: You can reconfigure existing LPARs within physical hardware limits, but you cannot exceed what you purchased.

If you bought a server with 16 cores and 128GB RAM:

- You can partition it as: 8+4+4 cores (3 LPARs) or 8+8 cores (2 LPARs)

- You can reallocate: Move cores from Dev to Production if needed

- You cannot create a 4th LPAR requiring more cores than physically available

- You cannot allocate more RAM than the system contains

If you need additional capacity:

1. Contact IBM about field upgrades (if your specific model supports them — expensive and rare)

2. Purchase a second server and connect via TCP/IP for multi-server deployments

3. This is the standard approach in larger enterprises

One SLIC, Multiple LPARs

An important architectural detail: There is one SLIC per physical server, not one per LPAR. SLIC operates at the hypervisor level, above all partitions:

Physical Server
│
├── SLIC (System Licensed Internal Code)
│ └── One instance managing the entire server
│ ├── Translates TIMI bytecode for all LPARs
│ ├── Allocates CPU and memory to LPARs
│ ├── Enforces isolation between LPARs
│ └── Manages shared resources
│
├── LPAR-Production
│ ├── IBM i OS (independent instance)
│ └── Uses SLIC for translation and resource allocation
│
├── LPAR-Test
│ ├── IBM i OS (independent instance)
│ └── Uses SLIC for translation and resource allocation
│
└── LPAR-Dev
├── IBM i OS (independent instance)
└── Uses SLIC for translation and resource allocation

SLIC acts as the central authority, ensuring isolation while sharing the translation infrastructure across all partitions. This is efficient because:

- TIMI translation infrastructure is resource-intensive and doesn’t need replication

- Hardware-accelerated operations serve all LPARs without overhead

- SLIC manages partition-level resource allocation transparently

Part 4: How TIMI and SLIC Enable Hardware Independence

The Complete Architecture

The architecture forms a layered abstraction:

User Applications (RPG, COBOL, C programs)
↓
IBM i OS Kernel (independent instance per LPAR)
↓
TIMI Bytecode (hardware-independent intermediate layer)
↓
SLIC Translation Engine (one per physical server)
↓
IBM PowerVM Hypervisor (manages LPAR isolation)
↓
Native Machine Code (optimized per processor generation)
↓
IBM Power System Hardware (POWER8, POWER9, POWER10…)

Each layer abstracts away the details of the layer below it.

Real-World Example: Hardware Migration

Scenario: Your enterprise runs three applications across three LPARs on a POWER9 system. Five years later, you purchase a new POWER10 system.

Traditional Approach (without TIMI):

1. Stop all three LPARs

2. Extract source code for each application (if still available)

3. Recompile each application for POWER10 instruction set

4. Test each application thoroughly for platform-specific issues

5. Migrate data

6. Deploy recompiled applications

7. Timeline: Weeks or months of planning and testing

8. Risk: High — new compilation introduces potential bugs

IBM i Approach (with TIMI and SLIC):

1. Create SAVF (save files) containing all program objects from existing LPARs

2. Transfer SAVF to new POWER10 system via FTP

3. Restore program objects into new LPARs

4. Start LPARs

5. Applications begin running immediately

6. SLIC detects TIMI bytecode and translates to optimized POWER10 native code

7. Applications may even run faster due to POWER10 optimizations

8. Timeline: Hours, mostly FTP transfer time

9. Risk: Minimal — no recompilation, same applications, just migrated to new hardware

The critical difference: Your application binaries never knew they were compiled for POWER9. They’re compiled to the hardware-independent TIMI bytecode, which SLIC translates appropriately for whatever processor generation is running.

Why This Matters: The 30-Year Application

Consider an IBM i application written in 1994 in RPG. It was compiled to TIMI bytecode and has been running continuously since then:

- 1994: Ran on IMPI processors

- 1995: Migrated to PowerPC without modification

- 2000: Ran on POWER4 processors

- 2006: Ran on POWER5 processors

- 2012: Ran on POWER7 processors

- 2020: Ran on POWER9 processors

- 2024: Runs on POWER10 processors

The application was compiled once in 1994. It has never been recompiled. It has never had a line of source code modified. It continues running on processor generations that didn’t exist when it was written.

This is only possible because of TIMI’s hardware independence combined with SLIC’s translation capability. The application doesn’t know (and doesn’t care) which processor it runs on — TIMI and SLIC handle that complexity transparently.

Automatic Performance Improvements

As a bonus, when IBM introduces performance optimizations for new processors, existing applications automatically benefit:

1. IBM enhances SLIC’s TIMI translation algorithm to leverage POWER10 features

2. Next time an application loads, SLIC uses the improved translation

3. The application runs faster without any action from its owner

4. No recompilation needed; no source code access required

This continuous optimization happens transparently, year after year.

Application Portability

Because TIMI bytecode is hardware-independent, compiled program objects can be freely transferred between IBM i systems:

Dev System → (compile application) → Program Object (TIMI + Native Code)
↓ (FTP transfer)
Test System ← (restore from SAVF) ← SAVF File
↓ (FTP transfer)
Production System ← (restore from SAVF) ← SAVF File

Each system (Dev, Test, Production) may run different processor generations (POWER8, POWER9, POWER10), but the program object is the same. SLIC on each system translates the TIMI bytecode appropriately for its processor.

Conclusion: Hardware Independence as Architectural Philosophy

IBM i’s approach to hardware independence represents a fundamentally different philosophy from mainstream computing:

Mainstream Philosophy: Applications are disposable; treat hardware as the stable, long-term asset. Embrace cloud-native practices where applications are constantly rewritten.

IBM i Philosophy: Applications are valuable, long-lived assets; treat hardware as temporary. Enable applications to run for decades across multiple hardware generations without modification.

This philosophical difference explains IBM i’s continued relevance in enterprise computing. Organizations with mission-critical applications running 24/7 for decades find tremendous value in a platform that ensures their investments in software development continue to yield returns across hardware generations.

TIMI and SLIC are the technical innovations that enable this philosophy. By separating application binaries from processor architecture through an intermediate bytecode representation, and by providing a closed-source translation layer that can evolve independently, IBM created a platform where:

- Hardware upgrades are routine infrastructure management, not application crisis events

- Long-running applications require no maintenance across processor generations

- Vendor lock-in works in the customer’s favor — IBM is incentivized to keep applications running on new hardware

- Backward compatibility is assured indefinitely

In an industry obsessed with constant change and replacement, IBM i stands apart as a platform designed for stability, longevity, and preservation of software investments across decades.