Architecture of the IBM AS/400

Vincent LeVequeJames Madison University

CS511March 2001

05/05/11 4:58 A5/P5 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

05/05/11 4:58 A5/P5 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.

05/05/11 4:58 A5/P5 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.

05/05/11 4:58 A5/P5 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.

05/05/11 4:58 A5/P5 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.

05/05/11 4:58 A5/P5 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

05/05/11 4:58 A5/P5 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

05/05/11 4:58 A5/P5 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.

05/05/11 4:58 A5/P5 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:

05/05/11 4:58 A5/P5 8

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

OS/400The 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

05/05/11 4:58 A5/P5 9

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

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

I n t e r m e d i a t eR 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 mR e s o l u t i o n

M o n i t o r

P r o g r a m T e m p l a t e

P r o g r a m C o m p i l eP r o c e s s , v i a 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

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

T r a n s l a t o r

P o w e r P C A SI n s t r u c t i o n S t r e a m

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

o p e r a t i o n s

P o w e r P C A S m a h c i n ei n 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 r o g r a m ' so p e r a t i o n s

P r o g r a m E x e c u t i o nP 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

I N s t r u c t i o nS t r e a m

E x e c u t i o n o nP o w e r P C A S

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.

SummaryThe 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.

BibliographyFinal 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.

05/05/11 4:58 A5/P5 10