IBM i

IBM i
Company type	Operating system
Industry	Computer software
Predecessor	System/38 CPF, System/36 SSP, AIX
Founded	1988; 38 years ago
Founder	IBM
Headquarters	Armonk, United States
Area served	Worldwide
Products	IBM i operating system
Owner	IBM
Parent	IBM Power Systems
Website	www.ibm.com/it-infrastructure/power/os/ibm-i

IBM i (with the i signifying integrated) is an operating system created by IBM specifically for IBM Power Systems. Initially launched in 1988 under the name OS/400 for the IBM AS/400 series, it underwent rebranding to i5/OS in 2004 and later became known as IBM i in 2008. This OS traces its roots back to the System/38 CPF operating system, offering compatibility layers that support applications from System/36 SSP and AIX.

Key innovations inherited from System/38 include the Machine Interface, which facilitates hardware abstraction, an object-based addressing scheme utilizing a single-level store, and a built-in relational database seamlessly integrated into the operating system.

Origins

Development of OS/400 began concurrently with the AS/400 hardware platform in December 1985, following IBM’s cancellation of the Fort Knox project—a failed initiative that left a gap in IBM’s midrange system offerings. Within Fort Knox, a specialized team at Rochester developed code allowing System/36 applications to run on System/38 hardware. After Fort Knox was discontinued, this effort evolved into the Silverlake project, designed to unify System/36 and System/38 by delivering a consolidated hardware and software solution. The project took its name from Silver Lake in Rochester, Minnesota.

The Silverlake operating system, internally called XPF (Extended Control Program Facility), started as a CPF port adapted for Fort Knox hardware. It included support for System/36 applications and preserved certain user interface elements from System/36 to improve user experience.

Following field trials beginning in June 1988, Silverlake was officially introduced in August as the Application System/400, with its OS designated Operating System/400.

Transition to PowerPC Architecture

Adapting to PowerPC architecture necessitated a comprehensive rewrite of nearly all code beneath the Technology Independent Machine Interface (TIMI). Earlier versions of OS/400 incorporated Horizontal and Vertical Microcode layers inherited from System/38, renamed as Horizontal Licensed Internal Code (HLIC) and Vertical Licensed Internal Code (VLIC). The migration to PowerPC replaced the IMPI instruction set with the PowerPC AS instruction set, requiring VLIC to be rewritten and HLIC functionalities to be relocated.

This transformation resulted in consolidating HLIC and VLIC into a unified layer called System Licensed Internal Code (SLIC), developed using an object-oriented approach comprising more than two million lines of C++ code. To accomplish this, IBM Rochester recruited several hundred C++ developers who worked on SLIC while continuing revisions on VLIC for CISC-based AS/400 systems. Support for PowerPC hardware was first introduced in OS/400 with release V3R6.

Rebranding

Throughout the 1990s and 2000s, the AS/400 product family experienced multiple rebranding efforts. In 2004, IBM introduced the name eServer i5 for the hardware, while OS/400 was retitled as i5/OS, with the "5" signifying the incorporation of POWER5 processors. IBM characterized the initial i5/OS release, V5R3, as fundamentally the same operating system under a different designation.

In 2006, the platform was renamed System i. By April 2008, IBM consolidated System i with the System p lineup, creating the unified IBM Power Systems brand. At this point, i5/OS was rebranded as IBM i to reflect a shift away from exclusive association with POWER5 processors. The then-current releases, i5/OS V5R4 and V6R1, were correspondingly renamed IBM i 5.4 and 6.1.

With the transition to IBM i branding, version numbering moved away from the traditional Version, Release, Modification format (such as V2R1M1) toward a streamlined Version.Release system (for example, 6.1). Starting with IBM i 7.1, IBM replaced Modification releases with Technology Refreshes, which are optional PTFs that introduce new features or extend hardware compatibility within specific OS versions.

Architecture

Architectural layers of the IBM i operating system and their relation to hardware and software
Native Applications	S/36 and S/38 Environment Applications	UNIX Applications
XPF		PASE
TIMI		syscall Interface
SLIC
IBM Power Hardware

Initially launched as OS/400, IBM i architecture is structured into two principal layers: the hardware-dependent System Licensed Internal Code (SLIC) and the hardware-agnostic Extended Control Program Facility (XPF). These layers are separated by a hardware abstraction interface known as the Technology Independent Machine Interface (TIMI). Later releases incorporated additional components such as the AIX-compatible layer called Portable Application Solutions Environment (PASE), along with the Advanced 36 Machine environment that enables execution of System/36 SSP applications through emulation.

IBM employs various terms for TIMI, SLIC, and XPF across its documentation and marketing materials; for example, in IBM i 7.4 these are referred to as the IBM i Machine Interface, IBM i Licensed Internal Code, and IBM i Operating System, respectively.

Technology Independent Machine Interface (TIMI)

TIMI functions by abstracting hardware specifics—including processor instruction set architecture, address space dimensions, and I/O plus persistence mechanisms—from users and applications. This abstraction is implemented through two primary approaches:

Instead of generating native machine code directly, IBM i compilers produce a high-level intermediate representation defined by TIMI. At runtime, this representation undergoes an ahead-of-time transformation into native code by the operating system, which caches the resulting machine instructions for subsequent executions. This process allows applications to run on new CPU architectures without requiring source recompilation.
TIMI operates on an object-based model rather than direct memory addresses. Every piece of data—including files, source code, programs, and memory segments—is encapsulated as typed objects managed by the OS itself. This abstraction removes concerns about physical storage locations since retrieval and persistence are handled automatically by the system.

This level of hardware abstraction enabled IBM to migrate from the AS/400’s original 48-bit IMPI architecture to a 64-bit RS64 platform in 1995 without necessitating application recompilation or modifications while benefiting from expanded addressing capabilities.

TIMI instructions exist in two variants: Original Machine Interface (OMI) and New Machine Interface (NMI). OMI closely resembles the original System/38 Machine interface, whereas NMI is a lower-level format comparable to IBM’s internal "W-code" intermediate representation. Early AS/400 compilers generate OMI instructions; newer Integrated Language Environment compilers produce NMI code. During the transition to PowerPC processors, native OMI support was replaced by a translator converting OMI instructions into NMI.

The practice of retaining TIMI instructions alongside native code—termed observability—enhances system adaptability. However, changes introduced in i5/OS V6R1 in 2008 altered TIMI in ways that created compatibility challenges for third-party vendors who removed observability from application objects.

SLIC

The SLIC serves as the fundamental operating system kernel on the IBM Power architecture by implementing the TIMI. It converts TIMI instructions into executable machine code and facilitates advanced capabilities such as IBM i's built-in relational database system. Managing IBM i's object-oriented storage, SLIC employs a single-level store addressing model that merges primary and secondary storage into one unified virtual memory space. Written primarily in C++, it superseded the previous HLIC and VLIC layers present before the OS/400 V3R6 release.

XPF

XPF represents the hardware-agnostic layer of the OS, containing components compiled into TIMI instructions. This layer encompasses the user interface, Control Language, data handling, development environments, and system utilities. Additionally, XPF maintains compatibility with legacy systems through the System/36 Environment and System/38 Environment, supporting SSP and CPF applications respectively. Originating from the System/38’s Control Program Facility, XPF is predominantly implemented in PL/MI.

PASE

PASE (Portable Applications Solutions Environment) offers binary compatibility for AIX user-mode executables, supporting both 32-bit and 64-bit AIX Application Binary Interfaces. Initially introduced in OS/400 V4R3 to accommodate Smalltalk and officially released with V4R5, PASE executes AIX userspace programs atop a system call interface provided by SLIC. This design allows seamless interaction between PASE and native IBM i applications, including access to the integrated database and cross-calling functionality.

A notable feature of PASE is Teraspace, which allocates a private 1TiB address space per process using 64-bit pointers, overcoming IBM i’s traditional shared address space constraints. Unlike native IBM i applications that compile to TIMI instructions, PASE binaries are compiled directly into Power machine code.

Ports of open source software for IBM i typically target PASE for easier adaptation, often utilizing RPM packages managed through YUM. It is important to distinguish PASE from Qshell, which provides a Unix shell environment based on IBM i’s native POSIX-compatible interfaces.

Advanced 36 Machine

Launched in 1994, the Advanced/36 platform enabled unaltered System/36 applications and the SSP operating system to run in emulation mode on OS/400’s SLIC, leveraging hardware similar to contemporary AS/400 systems. Between OS/400 versions V3R6 and V4R4, this functionality was incorporated directly into OS/400, allowing up to four System/36 "virtual machines" via the Advanced 36 Machine feature. Support for this ended with V4R5, coinciding with IBM discontinuing the Advanced/36 product line. This capability is distinct from the System/36 Environment included in the initial OS/400 release and still supported in IBM i.

Traditional System/36 systems utilized two processors: the Main Storage Processor (MSP) handling most SSP OS and user programs, and the Control Storage Processor (CSP) managing microcode for core OS functions and input/output operations. Within Advanced/36, CSP microcode was reimplemented inside SLIC, which also incorporated an MSP emulator known as the Technology Independent Emulation Interface. Despite emulation overhead, Advanced/36 machines outperformed original System/36 hardware due to their use of PowerPC AS processors.

Database management

IBM i incorporates a built-in relational database system called IBM Db2 for IBM i. Originating from the non-relational System/38 database, it later incorporated relational and SQL capabilities. Although it initially lacked a formal name, it was designated DB2/400 in 1994 to align with IBM’s broader Db2 product family. Despite sharing the Db2 branding, Db2 for IBM i is a unique codebase deeply embedded within the IBM i SLIC layer, rather than being an add-on product.

Access to the database is provided through a native interface modeled on System/38’s approach using Data Description Specifications (DDS) and commands such as OPNQRYF, complemented by comprehensive SQL support. Certain functionalities, including object-relational features, are accessible exclusively via SQL. IBM i utilizes two distinct query optimizers—the Classic Query Engine (CQE) and the SQL Query Engine (SQE)—with a Query Dispatcher determining which optimizer to apply based on the query type. For remote connections, Distributed Data Management Architecture (DDM) supports the native interface, while Distributed Relational Database Architecture (DRDA) handles SQL communication.

The storage engine IBMDB2I allows MySQL and MariaDB applications to use Db2 for i as their backend database. Furthermore, open-source databases such as PostgreSQL, MongoDB, and Redis have been adapted to run on IBM i via the PASE environment; these operate independently from the integrated Db2 system.

Networking

IBM i supports networking through both the TCP/IP and IBM’s proprietary Systems Network Architecture. Historically, users accessed the system via IBM 5250 terminals connected through twinax, but contemporary IBM i environments mainly employ 5250 terminal emulators. IBM provides two primary emulator solutions for IBM i:

IBM i Access Client Solutions, a Java-based client compatible with Linux, macOS, and Windows platforms.
IBM i Access for Web/Mobile, which delivers web-based 5250 terminal emulation.

In addition, IBM offers IBM Navigator for i, a web-based tool designed for system management and performance monitoring.

Programming

The programming environment on IBM i supports languages such as RPG, Control Language, C, C++, Java, EGL, COBOL, and REXX. Support for Pascal, BASIC, PL/I, and Smalltalk compilers has been discontinued. The Integrated Language Environment (ILE) facilitates combining ILE-compatible languages—including C, C++, COBOL, RPG, and CL—into unified executables with seamless cross-language procedure calls.

Initially, compiling code in the PASE environment required an AIX platform; this changed with OS/400 V5R2 when the IBM XL compiler suite enabled native compilation directly within PASE. Subsequently, other compilers such as the gcc have been ported to PASE.

Development tools available include the Source Edit Utility (SEU) and Programming Development Manager running directly on IBM i. Additionally, IBM offers an Eclipse-based integrated development environment called IBM Rational Developer for i that runs on developers’ workstations. Earlier IDEs included CODE/400 for OS/2 and VisualAge-based IDEs tailored for Windows systems.

IBM i primarily uses EBCDIC character encoding but also supports ASCII, UCS-2, and UTF-16.

Storage

Within IBM i, disk drives may be organized into an auxiliary storage pool (ASP) to facilitate data management, minimize the consequences of storage device failures, and shorten recovery durations. When a disk malfunctions, only the data stored within that particular pool must undergo restoration. Additionally, ASPs can improve system efficiency by segregating objects with similar traits—such as journal receivers—into distinct pools.

By default, all disks are allocated to pool 1. These IBM i pools resemble Unix/Linux volume groups; nonetheless, it is typical for all disks to be contained within a single ASP.

Security

Security in IBM i is governed by authorities, which specify permissions for particular operations on system objects. These authorities can be granted to individual users (user profiles), groups (group profiles), or the public. Objects that are related can be grouped into an authorization list, enabling consolidated management of permissions.

User profiles possess a user class that dictates their baseline authorities. The five classes, ordered by level of privilege, include: Workstation User, System Operator, System Programmer, Security Administrator, and Security Officer. IBM i provides default profiles for each class; notably, the Security Officer profile (QSECOFR) serves a role analogous to the Unix root user.

IBM i implements five distinct security levels that determine the rigor of security enforcement:

Level 10 – No password is necessary; users receive unrestricted access; unknown usernames automatically generate profiles.
Level 20 – Login mandates valid credentials; grants nearly full access; restricts profile management; allows limited access accounts.
Level 30 – Enforces authorities; users must have explicit permissions on objects.
Level 40 – Limits access to certain system programs and instructions exclusively to operating system code.
Level 50 – Incorporates TCSEC C2 compliance features along with security audit journaling.

Security levels 10 through 30 correspond to earlier OS/400 security frameworks. Level 40 became the default starting with OS/400 V1R3, replacing System/38 capability addressing. Level 50 was introduced in V2R3 alongside TCSEC C2 certification.

Release timeline

Branding	Version	Release date	End of Program Support
OS/400	Template:Version^{[n 1]}	1988-08-26	1993-05-31
	Template:Version^{[n 2]}	1988-11-25
	Template:Version	1989-10-27
	Template:Version	1990-09-28
	Template:Version	1991-05-24	1994-06-30
	Template:Version	1992-03-06	1994-06-30
	Template:Version	1992-09-18	1995-03-31
	Template:Version	1993-12-17	1996-05-31
	Template:Version	1994-05-04	1997-05-31
	Template:Version	1994-11-25	1998-10-31
	Template:Version	1996-06-21	2000-05-31
	Template:Version	1995-12-22	1998-10-31
	Template:Version	1996-11-08	1999-06-30
	Template:Version	1997-08-29	2000-05-31
	Template:Version	1998-02-27	2000-05-31
	Template:Version	1998-09-11	2001-01-31
	Template:Version	1999-05-21	2001-05-31
	Template:Version	2000-07-28	2002-07-31
	Template:Version	2001-05-25	2005-09-30
	Template:Version	2002-08-30	2007-04-30

|- ! Branding ! Version ! Release date ! End of Program
Support |- | i5/OS |

| 2004-06-11 | 2009-04-30 |- | rowspan=2 | i5/OS,
later IBM i |

| 2006-02-14 | 2013-09-30 |- |

| 2008-03-21 | rowspan=2 | 2015-09-30 |- | rowspan=7 | IBM i |

| 2009-10-23 | |- |

| 2010-04-23 | 2018-04-30 |- |

| 2014-05-02 | 2021-04-30 |- |

| 2016-04-15 | 2023-09-30 |- |

| 2019-06-21 |

|- |

| 2022-05-10 |