IBM AS/400

In the early 1980s, IBM management became concerned that IBM's large number of incompatible midrange computer systems was hurting the company's competitiveness, particularly against Digital Equipment Corporation's VAX.^[10] In 1982, a project named Fort Knox commenced, which was intended to consolidate the System/36, the System/38, the IBM 8100, the Series/1 and the IBM 4300 series into a single product line based around an IBM 801-based processor codenamed Iliad, while retaining backwards compatibility with all the systems it was intended to replace.^[11] A new operating system would be created for Fort Knox, but the operating systems of each platform which Fort Knox was intended to replace would also be ported to the Iliad processor to allow customers to migrate their software to the new platform.

The Fort Knox project proved to be overly ambitious, and ran into multiple delays and changes of scope. As the project advanced, the requirement to support IBM 8100 and Series/1 software was dropped.^[12] When IBM's engineers attempted to port the operating systems and software of their existing platforms, they discovered that it would be impossible without making extensive changes to the Iliad processor for each individual operating system – changes which the Iliad's architects were unwilling to make.^[11] The proposed solution to this was to augment Iliad with operating system-specific co-processors which provided hardware support for a single operating system. However, the amount of logic needed in each co-processor grew until the co-processors became the main processor, and the Iliad was relegated to the role of a support processor – thus failing the goal of consolidating on a single processor architecture. The Fort Knox project was ultimately cancelled in 1985.

During the Fort Knox project, a skunkworks project was started at IBM Rochester by engineers who believed that Fort Knox's failure was inevitable. These engineers developed code which allowed System/36 applications to run on top of the System/38,^[12] and when Fort Knox was cancelled, this skunkworks project evolved into an official project to replace both the System/36 and System/38 with a single new hardware platform.^[13] The project became known as Silverlake (named for Silver Lake in Rochester, Minnesota) and officially began in December 1985.^[14] The Silverlake hardware was essentially an evolution of the System/38 which reused some of the technology developed for the Fort Knox project.^[12][15]

Silverlake's goal was to deliver a replacement for the System/36 and System/38 in as short of a timeframe as possible, as the Fort Knox project had stalled new product development at Rochester, leaving IBM without a competitive midrange system.^[16] On its launch in 1986, the System/370-compatible IBM 9370 was positioned as IBM's preferred midrange platform, but failed to achieve the commercial success IBM hoped it would have.^[11][17] Much like Silverlake, the 9370 also reused the co-processor developed during the Fort Knox project as its main processor, and the same SPD I/O bus which was derived from the Series/1 bus.^[11]

On June 21, 1988, IBM officially announced the Silverlake system as the Application System/400 (AS/400). The announcement included more than 1,000 software packages written for it by IBM and IBM Business Partners.^[18] The AS/400 operating system was named Operating System/400 (OS/400).^[12]

The creators of the AS/400 originally planned to use the name System/40, but IBM had adopted a new product nomenclature around the same time, which led to the Application System/400 name.^[13] Firstly, IBM began prefixing "System" in product names with words to indicate the intended use or target market of the system (e.g. Personal System/2 and Enterprise System/9000). Secondly, IBM decided to reserve one and two digit model numbers for personal systems (e.g. PS/2 and PS/55), three digit numbers for midrange systems (e.g. AS/400) and four digit numbers for mainframes (e.g. ES/9000). The reassignment of two digit model numbers from midrange systems to personal systems was to prevent the personal systems from running out of single-digit numbers for new products.

In 1990, IBM Rochester began work to replace the AS/400's original System/38-derived 48-bit CISC processors with a 96-bit architecture known as C-RISC (Commercial RISC).^[11] Rather than being a clean-slate design, C-RISC would have added RISC-style and VLIW-style instructions to the AS/400's processor, while maintaining backwards compatibility with the System/370-style Internal Microprogrammed Interface (IMPI) instruction set and the microcode used to implement it.

In 1991, at the request of IBM president Jack Kuehler, a team under the leadership of Frank Soltis delivered a proposal to adapt the 64-bit PowerPC architecture to support the needs of the AS/400 platform.^[19] Their extensions to the PowerPC architecture, known as Amazon (and later as PowerPC AS), were approved by IBM management instead of the C-RISC design for development into the next AS/400 processor architecture.^[20] These extensions include support for tagged memory,^[21] as well as assistance for decimal arithmetic.^[22]

IBM initially attempted to create a single PowerPC implementation for both AS/400 and high-end RS/6000 systems known as Belatrix.^[11] The Belatrix project proved to be too ambitious, and was cancelled when it became apparent that it would not deliver on schedule. Instead, a pair of AS/400-specific processors were designed at IBM Endicott and IBM Rochester, known as Cobra (for low end systems) and Muskie (for high end systems) respectively. These became the initial implementations of the IBM RS64 processor line. The RS64 series continued to be developed as a separate product line at IBM until the POWER4 merged both the RS64 and POWER product lines together.^[13]

Despite the move from IMPI to an entirely different processor architecture, the AS/400's Technology Independent Machine Interface (TIMI) mostly hid the changes from users and applications, and transparently recompiled applications for the new processor architecture.^[23] The port of OS/400 to the PowerPC AS architecture required a rewrite of most of the code below the TIMI due to the use of IMPI microcode to implement significant quantities of the operating system's low level code.^[13] This led to the creation of the System Licensed Internal Code (SLIC) - a new implementation of the lower levels of the operating system mostly written in C++.

The AS/400 family line was rebranded several times in the 1990s and 2000s as IBM introduced newer generations of hardware and operating system.^[23]

In 1994, the AS/400 Advanced Series name was used for new models, followed by the rebranding of the product line to AS/400e (the e standing for e-business) in 1997.^[13]

In 2000, eServer iSeries was introduced as part of its eServer branding initiative.^[24] The eServer iSeries was built on the POWER4 processor from the RS64 processors used by previous generations, meaning that the same processors were used in both the iSeries and pSeries platforms, the latter of which ran AIX.

In 2004, eServer i5 (along with OS/400 becoming i5/OS) the 5 signifying the use of POWER5 processors, was introduced, replacing the eServer iSeries brand.^[25] Successive generations of iSeries and pSeries hardware converged until they were essentially the same hardware sold under different names and with different operating systems.^[6] Some i5 servers were still using the AS/400-specific IBM Machine Type (MT/M 9406-520), and were able to run AIX in an LPar along i5/OS, while the p5 servers were able to run i5/OS respectively. The licensing for AIX and i5/OS was controlled in the firmware by the POWER hypervisor.

The final rebranding occurred in 2006, when IBM rebranded the eServer i5 to System i.^[26]

In April 2008, IBM introduced the IBM Power Systems line, which was a convergence of System i and System p product lines.^[7] The first Power Systems machines used the POWER6 processors; i5/OS was renamed as IBM i, in order to remove the association with POWER5 processors.^[27] IBM i is sold as one of the operating system options for Power Systems (along with AIX and Linux) instead of being tied to its own hardware platform.

Although announced in 1988, the AS/400 remains IBM's most recent major architectural shift that was developed wholly internally^{[citation needed]}. After the departure of CEO John Akers in 1993, when IBM looked likely to be split up, Bill Gates commented that the only part of IBM that Microsoft would be interested in was the AS/400 division. (At the time, many of Microsoft's business and financial systems ran on the AS/400 platform, which ended around 1999 with the introduction of Windows 2000.^[28][29][30])

According to Frank Soltis, one of the architects of the AS/400 platform, the AS/400's architecture is defined by five architectural principles. Most of these principles are inherited from System/38.^[31]

The high-level instruction set (called TIMI for "Technology Independent Machine Interface" by IBM), allows application programs to take advantage of advances in hardware and software without recompilation. TIMI is a virtual instruction set independent of the underlying machine instruction set of the CPU. User-mode programs contain both TIMI instructions and the machine instructions of the CPU, thus ensuring hardware independence. This is conceptually somewhat similar to the virtual machine architecture of programming environments such as Java and .NET.

Unlike some other virtual-machine architectures in which the virtual instructions are interpreted at run time, TIMI instructions are never interpreted. They constitute an intermediate compile time step and are translated into the processor's instruction set as the final compilation step. The TIMI instructions are stored within the final program object, in addition to the executable machine instructions. This is how application objects compiled on one processor family (e.g., the original CISC AS/400 48-bit processors) could be moved to a new processor (e.g., PowerPC 64-bit) without re-compilation. An application saved from the older 48-bit platform can simply be restored onto the new 64-bit platform where the operating system discards the old machine instructions and re-translates the TIMI instructions into 64-bit instructions for the new processor.

The system's instruction set defines all pointers as 128-bit. This was the original design feature of the System/38 (S/38) in the mid 1970s planning for future use of faster processors, memory and an expanded address space. The original AS/400 CISC models used the same 48-bit address space as the S/38. The address space was expanded in 1995 when the RISC PowerPC RS64 64-bit CPU processor replaced the 48-bit CISC processor.

OS/400 (now known as IBM i) is the native operating system of the AS/400 platform, and was the sole operating system supported on the original AS/400 hardware. Many of the advanced features associated with the AS/400 are implemented in the operating system as opposed to the underlying hardware, which changed significantly throughout the life of the AS/400 platform. Features include a RDBMS (Db2 for i), a menu-driven interface, support for multiple users, block-oriented terminal support (IBM 5250), and printers.

Unlike the "everything is a file" principle of Unix and its derivatives, on IBM i everything is an object (with built-in persistence and garbage collection).^{[citation needed]}

IBM uses a single-level store virtual memory architecture in the AS/400 platform. For 64-bit PowerPC processors, the virtual address resides in the rightmost 64 bits of a pointer while it was 48 bits in the S/38 and CISC AS/400. The 64-bit address space references main memory and disk as a single address set which is the single-level store concept.

Later generations of hardware are also capable of supporting various guest operating systems, including SSP, AIX, Linux, Microsoft Windows 2000 and Windows Server 2003. While OS/400, AIX, and Linux are supported on the POWER processors on LPARs (logical partitions), Windows is supported with either single-processor internal blade servers (IXS) or externally linked multiple-processor servers (IXA and iSCSI). SSP guests were supported using emulation from OS/400 V3R6 through V4R4 using the Advanced 36 Machine facility of the operating system, a feature distinct from the System/36 Environment compatibility layer which requires System/36 software to be recompiled.

• IBM's Power Systems product page
• "IBM Hardware list for "System i"". Retrieved May 28, 2020.^{[dead link]}
• IBM Archives: A Brief History of the IBM AS/400 and iSeries
• The IBM AS400 A technical introduction