dispelledIBM Midrange: From System/3 to IBM i
IBM's midrange systems gave businesses a practical path from card-oriented data processing to interactive applications, integrated databases, and long-lived transaction systems. Across the System/3 family, System/38, AS/400, and IBM i, the names and processors changed while compatibility remained a central promise. The result is an unusual retro-computing story: a platform whose early design ideas still support current production work.
From System/3x to the AS/400
IBM's System/3, System/32, System/34, and System/36 served organizations that needed dependable transaction processing, reports, terminals, and business languages without a mainframe-scale installation. The System/38, announced in 1978, took a more ambitious architectural path. It emphasized object-based storage, an integrated relational database, and an abstraction between programs and machine hardware—ideas intended to support business data and long-lived applications across changing hardware.
IBM introduced the Application System/400 (AS/400) in 1988. It combined a System/38-derived operating environment and database concepts with a broad midrange customer base. The operating system was OS/400. Renaming followed IBM's hardware and portfolio changes: AS/400 became iSeries in 2000, then System i in 2006; OS/400 became i5/OS, and the current name is IBM i. The names changed, but compatibility and application investment were central selling points.
| Period | Name or platform | Continuity |
|---|---|---|
| 1969–1977 | System/3, System/32, System/34, System/36 | Midrange business computing and terminal-oriented workloads establish the market context. |
| 1978 | System/38 | Introduces the architectural ideas later associated with IBM i, including single-level storage and an integrated database. |
| 1988 | AS/400 and OS/400 | Brings the line to a broad commercial platform. |
| 2000–2006 | iSeries, then System i | Branding follows IBM server families; the application environment continues. |
| 2008–today | IBM i on Power | The operating system continues on IBM Power Systems with current releases and support. |
An architecture organized around objects
IBM i presents many system resources as typed objects: programs, files, queues, users, devices, and more. Libraries organize and locate those objects, while authorities define how users and programs may work with them. This integrated model carries through application deployment, access control, backup, and system management.
Single-level storage
A defining System/38 and IBM i idea is single-level storage. Programs address objects in one persistent address space conceptually spanning memory and auxiliary storage. The operating system manages placement and movement; applications are not ordinarily written around explicit disk block addresses. This does not mean storage is magically unlimited or that administrators never plan capacity, performance, recovery, or backups. It means the architectural interface deliberately hides a distinction that is more exposed in conventional file and virtual-memory designs.
TIMI and the machine interface
The Technology Independent Machine Interface (TIMI), historically also called MI, is an abstraction between higher-level programs and the underlying processor implementation. Compiled program representations and system support can be translated or adapted as hardware evolves. IBM has used this separation to carry applications across major processor transitions, including the move from CISC AS/400 hardware to Power-based systems. Compatibility has limits—applications depend on supported interfaces, data formats, and vendor commitments—but the abstraction explains why old business software can outlive a processor generation.
Database and business software are part of the system
Db2 for i is integrated with IBM i rather than installed as a wholly separate conventional database server. Database objects, security, journaling, and system management consequently connect closely to the operating environment. This suited organizations running order entry, inventory, payroll, manufacturing, and finance systems where transactions and reporting had to remain available for years.
RPG and COBOL became durable languages in this setting. RPG's report-processing origins do not make modern RPG applications merely old batch programs: ILE RPG supports modular programs and procedures, and IBM i shops use SQL, web services, Java, and other technologies alongside it. Nor should longevity be mistaken for immobility. The cost and risk of changing working business logic, data, and operations helps explain why these applications persist, while current integrations often demand APIs, auditability, encryption, and skills beyond the original green-screen model.
Power hardware and open-system tools
IBM's adoption of Power processors created shared hardware foundations across several product lines. IBM i and AIX can occupy separate logical partitions on the same Power server, with PowerVM allocating processors, memory, and I/O between workloads. This lets organizations consolidate unlike application environments without rewriting them into one operating model.
IBM i also provides practical bridges to contemporary development. QShell supplies a command environment with POSIX-style utilities for scripting and interoperability. PASE (Portable Application Solutions Environment) provides an AIX-derived runtime under IBM i management, allowing supported applications and libraries to use familiar open-system interfaces.
Open-source packages such as Git, OpenSSH, Python, Node.js, PHP, and related tools are available through IBM-supported and community packaging work. Together with SQL, web services, and APIs, they let teams connect established RPG and COBOL applications to newer systems without pretending decades of working business logic must be replaced all at once.
IBM i application environment
|
+-- objects, libraries, Db2 for i, jobs
|
+-- QShell: POSIX-style command environment
|
+-- PASE: AIX-derived application runtime
PowerVM logical partitions (when configured)
|
+-- IBM i
+-- AIX
+-- LinuxWhy this lineage remains current
IBM i remains a supported operating system on IBM Power hardware, not merely a museum name for AS/400. Its value is often operational continuity: organizations can retain trusted business logic while renewing hardware, database access, security controls, and integration methods. That continuity also creates modernization challenges, including scarce specialized skills and dependencies that must be understood before change. The enduring lesson is that carefully designed interfaces, abstraction layers, and compatibility commitments can carry useful applications across several generations of hardware.