IBM i Chief Architect Steve Will has seen the evolution of the AS/400 from the beginning having joined IBM in 1985. This webinar discussion he had with me has been so popular on our site, I figured it’d be worth recapping in a blog post.
Simply put, the IBM i architecture has gone through many iterations since it was introduced as the AS/400 in June 1988. Although there are core elements from the AS/400 (and even from System/38 and System/36) that are still part of IBM i today, the architecture has truly grown and evolved into something very different than how it started. Let’s explore this fascinating history!
Technology Independent Machine Interface (TIMI)
When the AS/400 launched, it had a fundamentally different makeup from the other operating systems of the day. This was due to its layered architecture and ability to translate and compile down into the virtual machine interface instructions without disruption.
DB2 for IBM i and Single-Level Storage
The AS/400 also featured single-level storage. Starting with System/38, all storage across physical memory and disk space was available in one area. This allowed data to be spread out, maximizing throughput on the platform. This is still the case today except for when storage area networks (SANs) handle components.
The architecture also dealt with virtual addresses, which divided into four-word pointers. Each featured a tag to indicate it was a pointer located in single-level storage. From System/38 to AS/400, this changed into multiple single-level stores, which were groups of disks called auxiliary storage pools (ASPs). All —pointerseven across ASPs—were controlled by the operating system.
Object-Based Architecture
With roots in System/38, AS/400 protected the integrity of the overall system by making it difficult to edit programs. It wasn’t possible to simply perform any operation on any object; it had to be an operation that was valid for that object. This prevented viruses from being introduced as often as they were on other platforms.
Need help with your AS/400 (IBM i)? Fortra has software and services that can really make your server sing. Schedule time with our experts today »
Inciting Incidents That Affected AS/400
C Programming Language
When the C language was introduced, there were ramifications for the AS/400 platform. Specifically, this new language contained pointers, meaning it could manipulate data and therefore alter OS code. IBM had to add Security Level 50 and initial hardware support to protect the integrity of the pointers in the AS/400.
Standard, Hierarchical File System
Although System/38 had one file system, hierarchical file systems were on the scene by the late 1970s. Eventually, the industry wanted to create a standard, hierarchical file system as part of the POSIX standards. Because AS/400 lacked this type of structure, it had to be created. The integrated file system (IFS) was born, and today’s modern applications assume a standard, hierarchical file system. This was a major change because the IFS could sit on top of several different implementations of file systems.
Another component of this were the monolithic programming techniques. Early software was written in monolithic programs that made it difficult to call from one program to another. As programming developed, it became possible to do things modularly and make calls more efficiently from one program to another. This required a new programming module, the Integrated Language Environment (ILE), which led to a new architectural component called the Activation Engine. Now it was possible to have fast calls to other programs and control the birth, life, and death of a process and its activation groups.
Multithreading
Jobs and processes used to take a long time to set up, but applications needed to start working asynchronously and frequently. The IBM platform was not able to handle these lightweight pieces of work, so developers had to determine whether to proceed with adding multithreading to the system. The decision to add the popular Lotus Notes solution to the platform became the compelling event, and the team completed this major architectural change to address the needs of the market. The advent of multithreading in the OS laid the groundwork for something all web programming requires today.
CISC to RISC Transition
The original AS/400 hardware was a 48-bit CISC processor. When it moved to a 64-bit RISC processor, significant code rewrites had to happen below the machine instruction layer and above the 48-bit processor. This meant major architectural changes below the TIMI—a major change underneath the covers of the AS/400, but it did not impact the end user's applications, so customers on AS/400 were able to move to this new technology with ease.
The World Wide Web
When hypertext transfer protocol (HTTP) came on the scene, the industry took notice, and IBM needed to integrate an open source Apache-based web server. Other architectural changes followed, such as requirements for digital certificates that proved one’s identity and high-performance temporary storage space called Teraspace.
DB2 Opportunities
Although queries in the system effectively yielded DB2 answers, users increasingly wanted to submit more complex queries via SQL that reflected learnings from past queries. The team developed the SQL Query Engine to live alongside the original Query Engine, and both are still in place today. The SQL Query Engine is highly adaptable and delivers answers based on previous requests.
The Change to IBM i
IBM i 6.1 had to retranslate all programs to improve security and performance as well as to remove limitations. Before this was done, all programs ran on a single stack. This change moved the system to a split stack, making ILE calls between modules faster. The new machine interface instructions offered improved efficiency, and Teraspace enhanced performance. However, there was still one gap that needed to be fixed. Administrators could still get to data in the OS, so the team closed this security issue by making it impossible to access and alter this information.
Technology Advancements
Now the platform can run AIX executables within IBM i, enhancing how people manage and work with the system. Green screens are being replaced over time, and administrators can manage the platform on any device that uses Java. IBM has made advancements in storage technology, I/O, and networking, and is working on how best to incorporate the advent of DevOps, blockchain, and microservices without disruption. IBM Watson and IBM Bluemix can also talk to IBM i. Today's IBM POWER6 through POWER9 processors can run the IBM i, AIX, and Linux operating systems alongside each other in a vitural (partitioned) environment.
Through all the technonolgy changes, IBM protected the customer's investment. Steve reiterated that IBM’s goal is creating beautiful architecture that continues to change and be used, serving up solutions for today’s marketplace.
If you missed Steve Will’s live webinar, don’t worry. You can still watch the recording here.
