Architecture of the IBM AS/400

03/10/11 3:00 A3/P3 1

 Table of Contents

Overview of the IBM AS/400.........................................................................................................1

History........................................................................................................................................1
Target Market.............................................................................................................................1
Distinctive Features....................................................................................................................2
Architectural Overview...............................................................................................................2
Hardware........................................................................................................................................3
CPU............................................................................................................................................3
Memory Management.................................................................................................................4
Single Level Store:..................................................................................................................4
Virtual Address Translation:...................................................................................................4
Tag bits. ................................................................................................................................4
Storage Protection:..................................................................................................................5
Bus..............................................................................................................................................5
SPD Bus:.................................................................................................................................5
PCI Bus:..................................................................................................................................5
Input/Output Processors..............................................................................................................5
System Licensed Internal Code (SLIC) and Hardware...............................................................6
The Machine Interface....................................................................................................................6
Overview....................................................................................................................................6
Application Programming Interfaces..........................................................................................7
Application Code Execution and the MI.....................................................................................7
OS/400............................................................................................................................................9
Summary.......................................................................................................................................10
Bibliography.................................................................................................................................10
Table of Figures
Figure 1 – AS/400 Architectural Overview ....................................................................................3
Figure 2 – Typical AS/400 PCI bus configuration..........................................................................5
Figure 3 – Sample MI Program.......................................................................................................7
Figure 4 – Creating, Interpreting, and Executing Application Code on the AS/400........................9

03/10/11 3:00 A3/P3 2

Overview of the IBM AS/400

History
The AS/400 is the distant though direct descendant of the IBM Series 3 released in the late
1960’s.
The Series 3 were smaller computing machines designed for mid-sized businesses that previously
relied on electromechanical tabulating machines for their computing needs. The influence of card
tabulating equipment has extended into the AS/400, most obviously in the dominance of RPG as
it’s primary programming language.
Following the Series 3 in the 1970’s were the System/32, then the System/34.
After the success of the System/34, IBM released two different minicomputers, which both
became the immediate predecessors of the AS/400. These were the System/36 (S/36) and
System/38 (S/38). The S/36 had a simpler architecture, very close to its roots in the S/34. It
supported a flat-file data store, relying on the RPG programming language. The S/36 did,
however support communications features considered advanced for its time and for its target
market, specifically a perr-to-peer variant of IBM’s mainframe-based SNA communciation
protocol. The S/36’s user interface was menu-driven and friendly. For its power and price range
it filled an important market niche supporting industry-specific turnkey application packages
designed for small-to-medium sized businesses.
The S/38, while less popular, had a more technically advanced architecture. All system
administration and programming functionality were included in the operating system – compilers,
database management systems, and backup/recovery utilities. It was an object-based system,
designed around an abstract machine interface. This abstract machine interface allowed IBM to
upgrade processor hardware at will without affecting application performance or stability.
The S/36 and S/38 contributed to the AS/400 design in different ways. The S/36 contributed it’s
communications capability, friendly menu command interface, large installed base and large
community of software vendors.
The S/38 provided the AS/400’s overall architecture – object-based, imbedded DBMS,
relationship with hardware mediated by an abstract machine interface, and many operating
system utilities.
The combined platform, named the AS/400 was released in 1989. Over the years it has
undergone dramatic changes in underlying processor hardware, peripheral support, and operating
system functionality.
During 1990’s the AS/400 adopted open systems characteristics in response to competition from
UNIX-based systems such as the Hewlett Packard HP-9000 and Sun Microsystems Solaris-based
UNIX systems. Support for TCP/IP, POSIX-compliant Application Programming Interfaces
(APIs) and a UNIX-like file system were among these changes.

Target Market
The AS/400 has traditionally served mid-sized businesses wanting a low maintenance turnkey
system with application software tailored to their particular industry. The AS/400 sees
widespread use in “hard goods” industries such as manufacturing, distribution and retailing.
It’s initial competitors were other non-UNIX minicomputers such as DEC VAX and HP-3000.
The AS/400 was, in fact, dubbed the “VAX Killer” by some, seeing it as IBM’s effort to end
Digital’s competitive threat. Current AS/400 competitors are UNIX-based servers at the high
end, and Windows-NT at low end.

03/10/11 3:00 A3/P3 1

Distinctive Features
The most immediately noticed distinctive feature of the IBM AS/400 is its command syntax and
menu-based command interface. Each command consists of an abbreviated verb, followed by its
target object and optionally other qualifiers. Each is represented by a standard 3 or 1 character
abbreviation, with optional qualifiers or “adjectives”. For example, the command “work with
object description” is WRKOBJD, while “create RPG program” would be CRTRPGPGM. While
a command entry prompt is available, the system provides a series of topic-oriented menus to
facilitate command use.
Dealing with the overall design of the operating system reveals other AS/400 unique features.
The operating system is object based, in that entities are encapsulated, that only operations
defined on an object may be permitted (e.g., program object code cannot be modified via a text
editor, etc.), and that objects posses an atomicity in that they cannot be split or manipulated
except as an entire object. This is in radical opposition to the UNIX model, where all objects are
regarded as files, and a file operation is permitted against any UNIX system object (e.g.,
executable code, devices, etc.)
The AS/400 cannot, however, be regarded as an object oriented operating system. It’s model is
referred to as “object based” rather than “object oriented” because it lacks some of the basic
characteristics of a fully object-oriented model. The AS/400, for example, does not support
subclass creation, and polymorphism is minimally defined.
The AS/400 also provides a fully abstract view of system hardware. End users (including
programmers and system administrators) perform all hardware-related functions via an abstract,
object-based interface referred to as the Machine Interface (MI). Direct access to real memory
locations, disk sectors, and processor resources is prevented through operating system controls
based in hardware protections.
Lastly, the AS/400 possesses an integrated database (DB2/400) as part of the operating system.
Use of third party database management products is not required. Technical database
administration tasks are subsumed into overall system management tasks. Manipulating a
database with SQL commands is as natural a function of the operating system as manipulating the
file system is in UNIX.

Architectural Overview
Currently available AS/400 hardware is RISC-based, using as a processor a variant of the same
PowerPC used in the Apple Macintosh. The AS/400’s variant of the PowerPC is called the
PowerPC AS, nicknamed “Amazon”.
Above the hardware is the System Licensed Internal Code (SLIC). The SLIC is written using
PowerPC AS machine language. Functions such as memory management and task management
are handled by the SLIC. SLIC code is not accessible to end users, nor is the PowerPC AS
instruction set.
Virtual memory is organized by the SLIC as a single level store. All objects existing in a single
large address space, which includes real memory as well as disk storage.
The SLIC supports the Machine Interface(MI), an abstract system interface. The SLIC interprets
MI commands and executes them on the hardware. The MI is an abstract machine, presenting
itself to the system user as the lowest level of machine architecture directly accessible. It is
possible to write code on an AS/400 using the MI language itself, though this is infrequently
done. MI does, however, provide flexibility and speed desired by some programmers,
particularly vendors providing third-party system management products.

03/10/11 3:00 A3/P3 2

The AS/400 operating system, OS/400, runs “above” MI, and is implemented using MI
commands and objects. OS/400 presents the “view” of the AS/400 processor as seen by the vast
majority of AS/400 users, including programmers and system administrators.

Figure 1 – AS/400 Architectural Overview

Hardware

CPU
The AS/400 central processor architecture is referred to as the Amazon architecture, a superset of
the PowerPC (RISC) architecture. The processor chip itself is a member of the PowerPC family,
and is referred to as the PowerPC AS. Three different models of the PowerPC AS processor are
used in the AS/400 series: A10; A30; and A35.
The PowerPC AS processor contains the standard instruction set of the typical PowerPC chip,
though the PowerPC AS includes instructions not present in standard versions. Differences
between the standard PowerPC and the AS/400 variant include:
• Support for tag bits (used for memory protection, discussed shortly)
• Decimal numeric operations
• More efficient data movement
• System call return
• Virtual address translation designed to support single level store.
In the PowerPC AS, instructions are 32 bit, and data pipes are 64 bits. Included with the
processor are both L1 and L2 cache. In L1 cache, instructions are stored separately from data.
Specific documentation on the Amazon processors is not made available to the general public, so
this description is based entirely on secondary sources.

03/10/11 3:00 A3/P3 3

The CPU supports hardware address translation. While 80 bits are available, only 64 bit
addresses are supported by current AS/400 models. The processor contains a Memory
Management Unit (MMU) to specifically handle address translation.
More powerful AS/400 models support multiple processors in a Symmetric Multiprocessing
(SMP) configuration. Management of multiple processors is handled below the MI layer by
SLIC. Multiprocessor operation is thus transparent to the operating system and to user
applications.
The central processing unit includes several other modules besides the processor. Of particular
note is the Service Processor, used for initializing the system and providing debug and diagnostic
functions.

Memory Management

Single Level Store:

The AS/400 stores objects in a single address space, encompassing virtual memory and the file
system. Each object has a single permanent address to which it is referred by all users and
processes. Real memory functions as a cache for objects located on disk, managed by the SLIC,
invisible to the MI or to OS/400. Programs access objects via the object’s permanent address,
rather than copying portions of an object into a user’s address space, then using the temporarily
assigned address in this address space. The system assigns all objects a permanent address in the
virtual address space. Objects are referenced by name or by pointer, with the virtual addressing
mechanism being responsible for moving the object into real memory.
The 64-bit addressing provides for direct address of 16 “exabytes” of disk. This virtual address
space is divided into segments. Real address is in turn divided into “pages” of Kbytes each.
Segments and pages are managed by SLIC. The actual addressing of objects is invisible to MI,
the OS and any applications. SLIC reserves certain segments, for example those which
correspond to real memory addresses. Each segment has a 32 byte segment header, which
includes segment size, storage protection bits, segment addresses, and the segment domain
(system or user). The SLIC assigns objects virtual addresses at object creation time. The object
header contains the object’s

Virtual Address Translation:

Users (including programmers and system administrators) do not have the ability to directly
access real memory. Translates segments (virtual memory units assigned by SLIC) to pages and
addresses within pages (real addresses assigned by SLIC). Segments are translated into pages via
a Hardware Page Table (HPT) and an associated Software Page Table (SPT), which maps the
single-level virtual address to an address on secondary storage (a different mechanism is used if
the page is in fact real-memory resident).

Tag bits.
Each 8 bytes of memory in an AS/400 has a specific bit referred to as a tag bit. If the tag bit is
set, the memory location is treated as a Machine Interface address pointer, used to access data and
MI objects. If a user program modifies any data in the MI address pointer, the tag bits are turned
off by hardware, disabling it’s further use as an object pointer. This automatic clearing of tag bits
is a system integrity and security feature. It is designed to prevent corruption of pointer and
possible access to unauthorized storage.

03/10/11 3:00 A3/P3 4

Storage Protection:
Two bits are set in each virtual memory page for protection purposes. These bits provide
permissions to the virtual page, based on the state (user or system) of the machine. If the
machine’s state does not support loading the page, the load does not complete and an interrupt
occurs. Responding appropriately to protection violation interrupts is the responsibility of the
SLIC.

Bus
The traditional AS/400 bus was the System Products Division (SPD) bus. The PCI bus is
supported with newer AS/400 hardware.

SPD Bus:
The SPD bus is a 32 bit copper or fiber optic bus. The bus connects the AS/400 processor with
input/output devices. A device called a Bus Control Unit (BCU) acts as an arbiter of access to the
bus, by polling each device connected to the bus, and selecting one permitted to access the bus.

PCI Bus:
IBM announcements list advantages of the PCI bus as including faster I/O throughput (claimed to
be as much as ten times faster than the SPD bus), ability to “hot swap” peripherals (permitting
changing peripherals without powering down the processor), and more flexible placement of
peripherals on the bus (the SPD bus required some devices to be in specific bus slots). The
AS/400 PCI bus references 32-bit addresses on a single slot, with a combination of two slots
providing 64-bit device addresses. A logical grouping of eight card slots in a card enclosure is a
“Multi-Adapter Bridge”. All current AS/400 models excluding the low end Model 270 support
multiple Multi-Adapter Bridges. Figure 2 shows a typical PCI bus configuration:

Figure 2 – Typical AS/400 PCI bus configuration

Input/Output Processors
Input/Output processing is managed by specialized bus-connected processors associated with the
input/output peripheral. These processors are call input/output processors (IOPs). IOPs control
workstation, printer, disk, tape, and optical storage devices. IOPs contain microcode to program
device and protocol specific communications, offloading this function from the CPU. Some IOPs

03/10/11 3:00 A3/P3 5

in effect act as a bridge between the proprietary SPD bus and the more standard Small Computer
Standard Interface (SCSI) used by the externally attached device.

System Licensed Internal Code (SLIC) and Hardware

The SLIC provides the Machine Interface to user applications and OS/400. It creates a virtual
machine interface used by these applications to access hardware resources. All management of
the hardware is performed by SLIC. The SLIC executes PowerPC AS machine code, and is the
only part of the AS/400 authorized to do so. The SLIC takes the abstract objects used by the MI
and manages their memory requirements. Basic hardware management functions, such as virtual
address translation and CPU task management, are handled entirely by the SLIC, and are not
accessible in any direct way by the layers above it. While system management functions are
provided for performance tuning and hardware management tasks, they provide system
administrators with an abstract representation of the hardware. The commands and objects used
by AS/400 administrators to allocate real memory to different types of work in fact manipulate
abstract representations of actual memory. The results of these operations must be executed by
the SLIC to perform actual system hardware management.

The Machine Interface

Overview
The MI contains functions required for application execution and for management of the AS/400
itself. MI is a “virtualized” abstract processor. MI instructions operate on MI objects. The MI
instructions are translated by SLIC into PowerPC AS machine instructions. MI objects are
likewise translated into underlying machine data structures and machine instructions.
MI objects are “encapsulated” in that they must be operated upon as a whole. MI instructions do
not have visibility into the inner structure of the MI object. The encapsulated MI object contains:
• An object header, which includes the object’s storage protection class and object address
information.
• A functional part, which contains internal executable functions for the object
• Optionally, as associated space, which contains addressable MI object data
The following are examples of Machine Interface objects:
• Byte string space
• Cursor
• Data Space
• Data Space Index
• User Profile
• Logical Unit Descriptor
Machine Interface objects may map one-to-one with OS/400 objects. For example, a user
accessing a library object is in fact accessing a related MI context object. In other cases there is a
many-to-one mapping between MI objects and OS/400 objects. An OS/400 database is actually
implemented as several MI objects, such as cursors and indices which define the database
structure, as well as a data space which actually contains the records.
Machine Interface instructions may be coded into MI programs, and compiled into an executable
program object. The MI instruction set is the closest an AS/400 programmer will come to
working in assembly language. An example of a short MI program is shown in figure 2. Note

03/10/11 3:00 A3/P3 6

that is looks very much like standard assembly language code. There are significant differences
between MI code and a true hardware-based assembly language. As an example, the symbols
defined in the initial DCL statements are defined as a data type called a “space pointer”, rather
than being defined as a block of addressable storage.

Figure 3 – Sample MI Program

Application Programming Interfaces

Programmers operating in higher level languages may access both OS/400 functions and certain
MI functions through IBM-defined Application Programming Interfaces (APIs). OS/400 APIs
provides application programmers with a variety of interfaces, including operating system
commands, operating system exit functions (where user code may supplement an operating
system function), operating system functions, and MI functions. In an environment where
writing code directly to the hardware is not possible, APIs provide an essential mechanism for
opening the system up to third party products.

Application Code Execution and the MI

Several higher-level language compilers are provided on the IBM AS/400. These include
traditional business-oriented languages such as RPG and COBOL, as well as C and a compiled
shell-script-like language call Control Language (CL).
Higher level languages on an AS/400 are not immediately compiled to PowerPC AS machine
code, but are instead compiled to intermediate code, called a “program template”. Within the
compiler itself, an additional intermediate form is created temporarily. This intermediate code,
called the Intermediate Representation of a Program (IRP), exists fleetingly for purposes of
compile optimization.
This intermediate code is “compiled” again by the MI, creating an encapsulated object with the
actual machine instructions. The encapsulated object includes various integrity checks, such as a
“secure” checksum, designed to prevent tampering.

03/10/11 3:00 A3/P3 7

Use of a program template rather than pure machine code facilitates object portability. By
compiling the program template at the MI layer, the program is oblivious to the underlying
hardware. Transferring code from older proprietary AS/400 systems to the PowerPC models
required only a retranslation at the MI the first time the code was executed.
Integrity checks important to security are performed as part of the MI translation. Certain MI
instructions are “blocked”. No mechanism exists for direct execution of PowerPC AS machine
code, and developing such a mechanism would require tampering with the largely undocumented
SLIC.
The process of creating and executing application code is illustrated in figure 4:

03/10/11 3:00 A3/P3 8

 R P G / 4 0 0 S o u r c e
C o d e

R P G / 4 0 0
C o m p i l e r

I n t e r m e d ia t e
R e p r e s e n t a t i o n o f
P r o g r a m ( I R P )
P
r o g r a m C o m p il e
P r o c e s s , v ia u s e o f
C R T R P G P G M
( C r e a t e R P G P r o g r a m )
C o m m a n d

P r o g r a m
R e s o l u t i o n
M o n i t o r

M I in s t r u c t i o n s r e p r e s e n t i n g
o r i g i n a l R P G / 4 0 0 p P r or o g g r ar a m m ' s T e m p l a t e
o p e r a t i o n s

M a c h in e I n t e r f a c e

T r a n s l a t o r

P r o g r a m E x e c u t io n
P r o c e s s , v i a u s e o f
C A L L
C o m m a n d

P o w e r P C A S m a h c in e
i n s t r u c t i o n s r e p r e s eP n o t wi n e g r P C A S
o r i g i n a l R P G / 4 0 0 p I nr o s g t r r ua cm t i ' o s n S t r e a m
o p e r a t i o n s

I N s t r u c t i o n
S t r e a m
E x e c u t io n o n
P o w e r P C A S

Figure 4 – Creating, Interpreting, and Executing Application Code on the AS/400

OS/400
The Machine Interface does not provide the functionality of a full operating system. The AS/400
operating system, OS/400 is built on the MI layer. It is designed to provide a set of user-
accessible commands and objects designed to support business application functions. The
operating system is not the ultimate controller of real hardware resources – this is the function of
the MI and the SLIC beneath it. The operating system instead coordinates the functioning of

03/10/11 3:00 A3/P3 9

various MI objects, providing a work environment in which end users, system administrators, and
programmers operate.
OS/400 is an object-based operating system, built upon an object-based MI. Functions which are
purely hardware-dependent exist below the MI. The set of objects provided with OS/400 give it a
rich functionality well integrated with the underlying MI. The database management system, for
example, is closely tied to programming languages and to system management functions. There
is no need for a technical database administrator in an AS/400 system. An operating system with
tightly integrated comprehensive objects and isolated from the underlying hardware via an
abstract machine interface has serious drawbacks, though. Using third party products to support
underlying system functions becomes difficult. IBM exercises tight control over interfaces to the
AS/400 hardware. Development of third party alternatives to IBM products is stifled as a result.
Administrators with backgrounds in operating systems such as UNIX often find the AS/400
environment constraining. Technical innovations developed in the UNIX arena may take years to
be ported to the AS/400.

Summary
The two most singularly unique characteristics of the IBM AS/400 are it’s persistent single-level
virtual memory and it’s abstract object-based Machine Interface. Combined, these provide a
system well-designed for its intended market – medium-sized commercial enterprises requiring
database update and transaction processing functions with minimal technical support
requirements. While the high-level interface may be frustrating to programmers used to lower-
level access provided by operating systems like UNIX, it provides stability, integrity, and ease of
use required for mundane business computing requirements.

Bibliography
Final Evaluation Report IBM AS/400 V4R1, National Security Agency, Fort George G. Meade,
Maryland, NCSC-FER-95/006.C, October 19, 1998
Inside the AS/400, Frank Soltis, Duke Communications, Loveland Colorado, 1996
AS/400 Security in a Client/Server Environment, Joseph S. Park, Wiley & Sons, 1995
System API Programming Version 4, IBM Publication SC41-5800-00, August 1997
IBM Hardware Announcement 100-174 June 12, 2000
AS/400e to iSeries Migration: A Guide to System Upgrades at V4R5, IBM Publication
SG24-6055-00, November 2000.

03/10/11 3:00 A3/P3 10