Advanced Interactive

Executive (AIX) operating

system overview
by L. K. Loucks
C. H. Sauer

The Advanced Interactive Executive (AIX) is the operat- functions—especially those that are taking place at
ing system used in the RT Personal Computer, it is a the request of other users—without mtervention by
portable operating system architecture that is suitahie the workstation's user. In many cases, the distribu-
for a wide range oí computer architectures and cus- tion of resources is not uniform. Users need to be
tomer requirements. Discussed in this paper are the
structure and services of AIX. able to use programs, data, and peripheral devices
that are not local to their own workstations. Perhaps
most important is the fact that workstations require
an operating system that provides an application
execution environment that combines application

T
program portability from IBM and industry environ-
his paper discusses the operating system for the ments with efficient use of the hardware.
RT Personal Computer™ that is known as the
Advanced Interactive Executive (AIX)™. The RT Per- We decided to base the core of the RT Personal
sonal Computer system is a family of workstations Computer operating system on the AT&T UNIX® Sys-
based on the IBM 32-bit (RISC) microprocessor— tem V. ( U N I X is developed and licensed by A T & T ,
named ROMP—and its corresponding high-function and is a registered trademark of AT&T in the U.S.A.
memory management unit. 1 (RT Personal Computer, and other countries.) In addition to System V, we
Advanced Interactive Executive, and AIX are trade- included many enhancements generally available in
marks of the International Business Machines Cor- the industry, most notably some features of System
poration.) With this level of performance and func- V.2, and many from BSD (Berkeley Software Distri-
tionality, IBM workstations reached the point at bution) 4.2 and 4.3. (BSD 4.2 and 4.3 are variants of the
which it was practical and imperative to provide U N I X system developed and distributed by the Uni-
workstation users with an operating system that was versity of California at Berkeley.) We chose the U N I X
as sophisticated as those used in mainframe com- operating system because it provides significant
puters. There were many considerations that com- power to a workstation user, provides multiuser ca-
pelled us to build an operating system for the RT pabilities when needed, and is portable and open-
Personal Computer that incorporated many of the ended. Also important is the fact that the U N I X
currently most advanced system concepts. system has a large user and application base. In
choosing the U N I X system. we accepted the need to
The RT Personal Computer system includes sophis- Copyright 1987 by International Business Machines Corporation.
ticated hardware features, such as high-function vir-
0

Copying in printed form for prívate use is permitted without

tual storage, advanced all-points-addressable (APA) payment of royalty provided that (1) each reproduction is done
displays, real-time capability, and others, which can without alteration and (2) the Journal reference and IBM copyright
be fully exploited only by equally sophisticated soft- notice are included on the first page. The title and abstract, but no
other portions, of this paper may be copied or distributed royalty
ware. Because most workstations opérate in an in- free without further permission by computer-based and other
creasingly interconnected environment, the operat- information-service systems. Permission to republish any other
ing system must be able to deal with communication portion of this paper must be obtained from the Editor.

LOUCKS AND SAUER IBM SYSTEMS JOURNAL. VOL 26. NO 4, 1987

 make significant upwardly compatible enhance- AIX structure
ments over what was available in the industry to
meet our requirements. As is traditional for U N I X - The generality and portability of the UNIX system
based operating systems, an acronym ending in ix are achieved at some cost in optimum use of the
was chosen: thus we have AIX. underlying hardware. We had decided to start with
the U N I X system as a base. In view of our require-
UNIX concepts
ments, however, we were faced with the question of
how best to provide the required enhancements. Two
strategies could be followed. One was to rewrite the
The UNIX operating system was originally created in entire kernel. Although theoretically possible, be-
the 1970s to provide a test bed for computer science cause of the amount of U N I X knowledge available in
experimentation. 2 This operating system differs from IBM at the time, it was unlikely that such an approach
conventional operating systems in several key ways. would achieve upward compatibility with the stan-
Essentially, all of the operating system code is written dard U N I X system. The other was to provide a set of
in c to ensure easy portability from one processor software services for the kernel and modify the kernel
architecture to another. Most of the control struc- and other functions to exploit the facilities provided
tures of the operating system, such as configuration by that layer. We chose the second approach, which
tables, are bound as late as possible. Configuration led to the system structure shown in Figure 2.
information is kept in editable files to allow easy
modification for experimental purposes. The file sys- The Virtual Resource Manager (VRM) controls the
tem, often called the heart of the U N I X system, is a real hardware and provides a stable, high-level ma-
tree-structured hierarchy consisting of directories chine interface to the advanced hardware features
and files. Files are represented as linear byte spaces and devices. (See Figure 3.) The kernel received
rather than records and fields. Directories are struc- corresponding enhancements to use the services of
tured files describing files and other directories. In the VRM and to provide essential additional facilities.
keeping with the objective of portability, most i/o is Although the VRM and the AIX kernel proper have
performed through generic devices. The generic de¬ been tuned to each other, we have not precluded the
vices are mapped to real i/o devices by user-replace- abüity to build other operating systems to exploit
able routines called device drivers. Any part of the the VRM services. Similarly, the techniques we used
nucleus of the system (called the kernel) can be to virtualize existing types of devices would work for
modified by an appropriately authorized user. A new device types as well. Both the VRM and the
command-processing component (called a shell) per- kernel have been deliberately made open-ended to
forms parameter substitution and calis appropriate allow the straightforward addition of new functions
command programs. No real distinction is made and device support.
between command processors supplied with the op-
erating system and those written by the user that
accept the same invocation parameter conventions, We were dealing with a new hardware architecture
and several shells can coexist in a given system. and with large quantities of new and modified soft-
ware in the system. Because of that, we felt that
special efforts were required to ensure excellent per-
Figure 1 shows the overall structure of a typical U N I X formance. We adopted a policy of continuous per-
system. The most significant difference from ordi- formance assessment of the operating system, start-
nary operating systems is the accessibility of all ele- ing with the earliest availability of hardware and
ments of the software to user modification. A U N I X software. The performance group had to develop
system is thus an operating system that provides new tools and procedures to assess the performance
tools for its own reden nition. It is precisely this of the system, while it was still immature. The results
characteristic that has made it the most popular of that effort are visible in the performance of the
operating system in academic computer science. completed product.
Many of the commands and facilities that were
originally developed in the course of computer sci- To achieve one of our primary goals of providing
ence experiments have found their way into produc- users the widest possible choice of applications and
tion UNIX systems. This has greatly enriched the U N I X computing environments, we provided ways of mov-
functional power, while contributing a certain ing applications and data to the RT Personal Com-
amount of inconsistency, especially in the syntax of puter from other systems, such as the IBM Personal
the command language. Computer, other U N I X systems, and IBM mainframes,

IBM SYSTEMS JOURNAL, VOL 26, NO 4, 1987

LOUCKS AND SAUER 327
Figure 3 Interface levéis of AIX

APPLICATION PROGRAM(S)

COMMUNICATIONS USABILITY SERVICES

DATA MANAGEMENT SQL RT DATABASE

ENHANCED TERMINAL SUPPORT COMMAND PROCESSING

(KERNEL INTERFACE)

ENHANCED: LOCAL TERMINAL GENERIC COMMUNICATIONS

VIRTUAL STORAGE SUPPORT DEVICE
FILE SYSTEM DRIVERS
CONFIGURATION
«
•
•

(VIRTUAL MACHINE INTERFACE)

STORAGE l/O COMMUNICATIONS COPROCESSOH

MANAGEMENT SUBSYSTEM SERVICES

as well as many ways to interconnect them. The • There was limited program management with
application development extensions above the kernel code sharing only at the program level and static
were integrated into the existing operating system binding of modules.
structure. In some cases, the extensions were pack- • Real-time facilities, such as absolute priorities,
aged and priced separately, but they were designed kernel-level pre-emption, and multiple-process
to opérate as integral parts of the operating system 1/0, were lacking. These facilities were thought
after installation. useful not only for traditional real-time applica-
tions, b u t also for complex Communications ser-
Creating a virtual environment for the AIX kernel vices.
• There were limited facilities for dealing with dy-
The existing structure and functions of the UNIX namic 1/0 configurations. Most 1/0 changes re-
kernel were not sufficient for exploiting the advanced quired the rebinding of the kernel.
features of the RT Personal Computer hardware. The
major deficiencies fell into the following áreas: Instead of making major changes to the architecture
of the kernel, we used the VRM to provide facilities
• Lack of virtual-memory support had been a per- to overeóme these shortcomings. The VRM provides
ceived deficiency in earlier systems. However, the services to implement a multitasking operating
there were UNix-based systems, such as BSD 4.2, system while insulating the kernel from most of the
that had provided virtual memory, but none of details of the hardware implementation. The kernel
these had the capabilities that were possible with has to be aware of only the problem-state instruc-
the RT Personal Computer. tions. All the other services, such as 1/0 device sup-

IBM SYSTEMS JOURNAL, VOL 26, NO 4, 1987 LOUCKS AND SAUER

 Figure 4 Virtual Resource Manager (VRM) structure

NUCLEUS
SVC HANDLER

l/O SUBSYSTEM
INITIALIZATION

VIRTUAL
TERMINAL
SUBSYSTEM
(VTSS)
NUCLEUS DEVICE
STORAGE SERVICES MANAGER
MANAGEMENT

VIRTUAL MINIDISK DISPATCHER

MEMORY MANAGER
DEVICE
MANAGER (MDM)
HANDLER
(VMM)

SERVICE ABILITY

port, storage management of disk and memory, and dynamic run-time binding of code, direct control of
hardware initialization, are provided. The VRM ser- virtual memory. millisecond-level timer control,
vices are implemented in a comprehensive real-time múltiple pre-emptable interrupt levéis, and an effi-
execution environment. 3 Figure 4 shows the overall cient interprocess communication mechanism for
structure of the VRM. main and interrupt-level processes.
VRM nucleus. The nucleus contains the basic ser- There is a virtual machine interface (VMI) that oper-
vices for the control of the R O M P processor, Memory ates as follows. The kernel accesses the facilities of
Management Unit (MMU), and i/o Channel Control- the VRM via a set of supervisor calis (svc), virtual
ler (iocc). These services include múltiple pre-empt- interrupts, and shared memory control blocks. Ser-
able processes, process creation and priority control, vices may be executed synchronously as a call/return

IBM SYSTEMS JOURNAL, VOL 26, NO 4, 1987

330 LOUCKS AND SAUER

 or asynchronously via a queue to a device driver or the VRM, gives the RT Personal Computer a demand-
process. These services provide the kernel with the paged virtual memory of 1 terabyte, consisting of
capability of enabling and disabling virtual inter- 4096 256-megabyte segments. Segments have a máx-
rupts, returning from a virtual interrupt, processing imum of 256 megabytes, but typically they are much
machine Communications interrupts such as a stor- smaller. The R O M P contains 16-segment registers,
age exception, and dispatching an operating system permitting the addressing of 14 segments [plus i/o
process. These are the basic facilities provided to and Direct Memory Access (DMA) operations] at any
implement a multitasking operating system kernel. time. (See Figure 5.) The VRM performs page-fault
Storage management. A minidisk manager (MDM) handling and manages the allocation of real memory,
provides the services to partition disk storage into paging space, and virtual storage segments. 4 The VRM
logical áreas that are independently managed. A also provides the AIX kernel with interfaces to control
minidisk is a contiguous área of disk storage that can these functions and to respond to a page fault by
be accessed by a logical block number, the size of dispatching another process. These services provide
which is specified by the kernel. This service also a view of virtual memory as a collection of segments
provides error recovery and bad block relocation. and pages that can be managed via svcs. The segment
The VRM resides on a minidisk of its own in a services include créate, destroy, change length, and
standard AIX file system. Installation and space man- protection, with a load-and-clear segment register(s)
agement on that minidisk are performed with stan- to provide addressability. A copy service that delays
dard AIX Utilities. copying pages until they are referenced provides the
necessary support for the UNIX fork primitive. The
Virtual memory manager (VMM). The R O M P / M M U page services that pin, unpin, change protection, and
virtual memory architecture, in combination with purge provide other basic mechanisms for the kernel

Figure 5 Virtual memory addressing

32-BIT ADDRESS FROM CPU

16-SEGMENT REGISTERS

•
•

2 BITS PROTECTION 12 BITS SEGMENT ID

40-BIT VIRTUAL ADDRESS

(i.e., 2 1 2
= 4096 SEGMENTS;
2 2 8
= 256 MB MAXIMUM SEGMENT SIZE)

IBM SYSTEMS JOURNAL, VOL 26, NO 4, 1987

LOUCKS AND SAUER 331
 devices. The devices that the kernel typically sees are
Figure 6 Device handler structure those that are generic, such as generalized fixed-disk
drives (Le., minidisks) or serial ports. In those cases
in which the generic devices are not appropriate or
in which the real-time capabilities of the VRM envi-
ronment are needed by the application, the user or
a third-party programmer can write c or assembler-
DEVICE HANDLER
language code to implement the necessary function
and dynamically add that code to the VRM.
DEFINE
DEVICE
Configuration. The configuration services provide
facilities to add device support to the VRM. The
INITIALIZE
Define Code svc binds an executable module, called
CONTROL
COMMANDS
DEVICE a device handler, into the VRM and Define Device
provides the device-specific parameters to the han-
dler. The correct device handler is typically selected
TERMINATE
DEVICE on the basis of the currently installed hardware or
via operating system configuration files and is dy-
namically bound into the VRM at start-up. However,
EXCEPTION these svcs may be issued to the VRM at any time. A
EXCEPTIONS HANDLER
Query svc provides the ability to determine the
current configuration.
COMMAND
CHECK
PARAMETERS Device handler. A device handler is a very structured
ENQUEUE
module designed to provide a queued interface to a
device. There is a well-defined set of entry points
DATA 1/0 that implement the functions of the driver; the exe-
COMMANDS cution environment for those entry points is strictly
controlled by the VRM. (See Figure 6.) A device
INITIATE

INTERRUPT handler is not a process. Therefore, it runs as a part

HANDLER of the calling process, i.e., the kernel or another VRM
l/O internal process, or on a hardware interrupt level.
INTERRUPTS
OFF LEVEL
INTERRUPT Device manager. A device manager is a structured
HANDLER
VRM process designed to provide additional manage-
ment services that cannot be provided by a device
handler. (See Figure 7.) The execution environment
is a VRM process and therefore has all the standard
process attributes and capabilities, such as the ability
to exploit virtual memory as well as various inter-
process communication (IPC) mechanisms.
to use in controlling the virtual memory environ-
ment. Virtual terminal subsystem (VTSS). At the time AIX
was being implemented, no standard U N I X interface
The VRM also provides a map page service that maps for advanced-function APA displays existed. There-
memory pages within a given segment onto discon- fore, we provided a method to allow múltiple appli-
tinuous disk file blocks, thus providing the primitive cations to access the local consolé hardware. The key
support for creating a single-level store that makes to this ability of AIX to support múltiple simultane-
disk and memory access equivalent operations. ous interactive applications is the virtual terminal. 5
A virtual terminal is a virtual counterpart of the real
I/O subsystem. The VRM provides the operating RT Personal Computer display(s), keyboard, locator
system with an extensive queued interface to the i/o (mouse or tablet), dials (valuator), and lighted pro-
devices, thereby insulating the kernel from the details gram function keys (LPFK). The virtual termináis
of specific devices and the management of shared time-share the use of the real displays and input

IBM SYSTEMS JOURNAL, VOL 26, NO 4, 1987

332 LOUCKS AND SAUER

 devices. A virtual terminal can function either as a
simulated ASCII terminal or as a high-function ter- Figure 7 Device manager structure

minal (HFT) equivalent in power to the real hardware.

ASCII terminal simulation. The simulated ASCO ter-
minal resembles a typical "glass teletype" (TTY), en-
hanced with functions to control sound, múltiple
fonts, and color. The functions are made available DEVICE MANAGER

at the VMI through a set of standard i/o svcs and

through escapes in the data stream, as allowed in COMMANDS
ANSI 3.64.

Monitored mode. ASCII terminal support is obviously

not sufficient to support graphics and image on the
local consolé displays. Therefore, an additional mode
of an HFT (high-function terminal) virtual terminal EXCEPTIONS
EXCEPTION
HANDLER
was provided. This facility, called monitored mode,
provides the support to allow an application in prob-
lem state to obtain controlled access to all hardware COMMAND CHECK
functions of the display. Also in this mode, data ENQUEUE PARAMETERS

from the input devices are placed directly in the

process address space by the HFT support in the VRM.
The necessary services to control this access are also
provided. These functions can be accessed directly
by advanced applications through HFT facilities pro-
vided by the kernel, or more appropriately via the
advanced graphics and windowing services provided
by AIX. shared system resources to ensure that the R O M P and
coprocessor opérate cooperatively.
HFT implementation. The HFT support is one ex-
ample of the type of high-function i/o that can be Building an e n h a n c e d kernel
implemented using the services provided by the VRM.
It currently consists of many device handlers, two The structure of the UNIX kernel was modified to
device-manager processes, and more lines of code allow it to opérate in a VRM execution environment. 7
than any other single VRM function. The kernel, and all of its processes, opérate within a
single virtual machine, as shown in Figure 8, and it
Serviceability. Problem determination in system- or uses the execution control facilities of the VRM to
user-added code is supported by VRM serviceability multitask within that machine. The kernel has been
facilities that include trace capabilities, dump capa- enhanced to use the VRM virtual memory services,
bilities, and an absolute debugger. and it now provides a demand-paged virtual memory
system that fully supports the 1-terabyte address
Personal Computer AT coprocessor. The VRM sup- space. The kernel uses VRM page fault information
ports the Personal Computer AT coprocessor option to control process dispatching, as well as allowing
as though it were another, albeit rather specialized, the kernel itself to be paged.
virtual machine. 6 The coprocessor runs concurrently
with the execution of programs in the R O M P , but it The kernel occupies one (256-megabyte) segment.
has access to the keyboard, locator, and display only The code, computational data, and stacks are all
when the coprocessor virtual terminal is the active contained within that segment. Each process is allo-
virtual terminal—that is, when it has control of the cated three segments: one for program text (code),
display. The inputs from the keyboard and locator one for computational data, and one for the stack,
are presented to the coprocessor as though they had as shown in Figure 9. This allocation of virtual
been produced by the corresponding Personal Com- memory allows very large programs with a very large
puter AT devices. If no display has been dedicated to data space to execute on the RT Personal Computer.
the coprocessor, the display interface emulates a PC This approach also simplifies many program and
display on the system display. The VRM manages the storage management functions. Functions such as

IBM SYSTEMS JOURNAL, VOL 26, NO 4, 1987

LOUCKS AND SAUER 333
 program sharing, computational storage allocation,
Figure 8 Operating system structure
and automatic stack growth are easier because all of
the program sections are consistent among processes
and are obviously large enough to allow simple tech-
niques to be used. Additional segments can be ob-
VIRTUAL MACHINE
tained for use with prívate or shared data, shared
code, or for mapped files.
Mapped files. A major extensión of the file system
JPROCESS
was the exploitation of the VRM map page service to
créate a single-level store environment for program
|
text (code) and data. This facility is called mapped
files. A mapped file is one that is accessed through
the virtual memory mechanism simply by loading
data from the appropriate address. A segment can
contain only one file. Figure 10 shows howfilesare
mapped into the program's address space. Executa-
ble files (programs) and static initialized data are
automatically mapped by the kernel at program
MACHINE CONTROL AREA invocation. A user data file can be mapped after it is
opened via a simple extensión to an existing system
cali. After a data file is mapped into a segment it
may be accessed using any of the traditional kernel
file i/o facilities, such as read. write, . . . , or it may
be treated as memory and accessed directly.

Figure 9 AIX virtual memory segment allocation Single-level store. Single-level store (SLS) technology
provides a number of significant performance and
space improvements over traditional methods. For
programs, the load-and-execute method of execution
requires that the operating system load the entire
program into its address space before execution may
SYSTEM 15 l/O BUS
begin. In addition, if the real memory is required for
VRM 14 DIRECT MEMORY ACCESS
(DMA) ADDRESSING
other purposes, the program must be paged out to
backing storage. Contrast that procedure with the
SLS approach. First, the program is simply mapped
SHARED MEMORY, 4-13 256 MB into the address space and given control at its entry
MEMORY-MAPPED
DISK FILES
point. Only the portions of the program that are
needed for this invocation are ever actually read into
real memory. Furthermore, if the real memory is
STACK required for other purposes, the program does not
256 MB
need to be paged out; it is simply paged in when
required again for execution. This procedure has the
CURRENT DATA benefits of quicker program start-up, reduced disk
PROCESS 256 MB
space because only a single copy of the program
exists on disk. and elimination of paging out of
PROGRAM program code. For data files, the advantages come
256 MB
from allowing the virtual memory manager to con-
trol all of the data of a process, both file data and
computational storage. Therefore, it can allocate real
memory in a more efficient manner. For example,
consider a datábase application that is accessing a
set of tables 10 megabytes in size, with that applica-
tion executing on a machine that has 16 megabytes

IBM SYSTEMS JOURNAL, VOL 26, NO 4, 1987

334 LOUCKS AND SAUER
 Figure 10 Virtual memory of an application using mapped files

SEGMENT REGISTERS

of real memory. After a few accesses, the essential file system lacked several key features necessary to
portions of the datábase tables are in real memory, support them. This resulted in datábase programs
and the accesses that in traditional architectures were that were not integrated with the system, unique sets
disk accesses are now memory accesses. The char- of utility commands to be learned, and a general
acteristic of program execution time changes from increase in the complexity of the system. We wanted
being i/olimited to processor-limited, and, since to provide an integrated environment. Therefore,
processor speeds are increasing at a more rapid rate the kernel file system services were extended to pro-
than disk access times, this change in the character- vide the necessary facilities to allow us to add data
istic of the program is very beneficial. This is similar management and relational datábase support that is
to the benefits of memory disks on personal com- built on top of the file system. 8 The enhancements
puters, except that the allocation of resources is done included the ability to perform space management
dynamically rather than statically and the process is within a file, buffer cache synchronization on a file
totally transparent to the user as well as to the basis, and file- and record-level locking.
program.
Performance and structure. We have added many
Datábase enhancements. Historically, UNix-based performance improvements to the file system. The
datábase programs have used only the low-level disk most notable are directory caching to speed up path-
i/o services of the kernel because the standard U N I X name lookup and the use of 2048-byte blocks. We

IBM SYSTEMS JOURNAL. VOL 26, NO 4, 1987

LOUCKS AND SAUER 335
 the VRM device handlers, which can be added or
Figuren File system structure replaced dynamically. To implement this, the device-
driver interfaces have been extended to allow dy-
K E R N E L A P P L I C A T I O N P R O G R A M M I N G I N T E R F A C E (API) namic binding of a kernel driver to a VRM device
handler.
Configuration. In configuring a U N I X system, the
VNODE LAYER
administrator has historically needed an understand-
ing of the internal structure and logic of the U N I X
system, to be able to edit the configuration files
/ correctly. We believed that it was unrealistic to im-
/ / / : / / pose such a requirement on our prospective users.
AIX
LOCAL
AIX
REMOTE
POTENTIAL
EXPANSION Therefore, we set out to simplify the installation and
FILE SYSTEM FILE SYSTEM configuration processes. 10 For those devices that can
be identified internally, such as displays, the system
/ / / performs an automatic configuration process. For
devices that require explicit description, such as
printers, we built a set of menu-driven Utilities that
have restructured the file system using the Sun Mi- obtain the necessary information f r o m the user and
crosystems™ vnode definition to support múltiple make the required coordinated changes to all of the
file system types in the kernel. 9 Figure 11 illustrates affected VRM and kernel system files. The interfaces
this approach. (Sun Microsystems is a trademark of to these Utilities have been documented so that users
Sun Microsystems, Inc.) or third-party programmers can add devices to be
selected and described vía the menus. These menus
Interprocess Communications (IPC). To assist in the use the facilities shown in Figure 12, which were
writing of multiprocess applications, several en- provided to allow users to add device and real-time
hancements were added to the standard system V application support.
IPC packages.
The i/o is typically configured at system start-up.
Signal enhancements. The traditional signal (asyn- The vrmconfig program. along with the helpers for
chronous event notification) package has been aug- each unique device type, reads the configuration files
mented by a new package, compatible with the and adds the current device support to the running
BSD 4.2 package, that provides more signal manage- system. Additional support may be added any time
ment services and cures a number of race conditions by simply running vrmconfig.
that were inherent in the original services. The stan-
dard signal package remains available for compati- Terminal support. The standard terminal support
bility with existing application programs. facilities of the U N I X operating system were extended
to exploit the capabilities of the VRM local consolé
Message queues/semaphores/shared memory. Mes- support. In addition, several enhancements were
sage queues were enhanced to provide an extended made to the general character support that is appli-
message structure that contains information useful cable to all Ascn-class or teletype termináis (com-
for implementing security controls in servers. An monly known as TTYS). Figure 13 describes the over-
additional option of semaphores reduces the process all AIX terminal structure.
dispatches required in typical multiple-process ap-
plications, and new system calis were added that Activity manager. We developed an activity manager
provide additional control over shared memory al- to provide the support to manage virtual termináis.
location and reclamation. It has facilities for programs and users, such as to
I/O management. The i/o management área of the créate or to terminate a virtual terminal or to start a
kernel was restructured to make effective use of the program.
i/o facilities of the VRM. Instead of a specialized Character support. The TTY generic support was ex-
device driver for each distinct device, we created a tended to provide support for screen paging. This
family of generic device drivers that are capable of
supporting a number of unique devices of a given facility is useful in controlling the output of stream-
class. Unique device characteristics are supported by oriented applications, as well as providing a mecha-

IBM SYSTEMS JOURNAL, VOL 26, NO 4, 1987

336 LOUCKS AND SAUER

 Figure 12 l/O configuration

CONFIGURATION
UTILITIES
VRMCONFIG
DEVICES PROGRAM
MINIDISKS
HELPERS

CONFIGURATION
FILES

CONFIGURATION
DEVICE DRIVER

DEVICE DRIVER INIT()

VIRTUAL RESOURCES MANAGER (VRM)

DEVICE MANAGERS

DEFINE CODE

DEFINE DEVICE

AUTOMATIC
CONFIGURATION
HARDWARE

nism to prevent unseen output from going to inactive escape codes in the data stream and a new set of i/o
virtual termináis. In addition, an input-editing controls to access features such as fonts, character
model patterned after the one provided in P C DOS sets, color, sound, and mouse input. These facilities
was provided. are accessed through the kernel high-function ter-
minal (HFT) device driver.
To allow existing applications to run unchanged and
new character-oriented applications to use the RT A package known as C U R S E S , which is a character-
Personal Computer facilities fully, we extended the oriented window management package designed for
ASCII character-oriented terminal model via prívate TTY ASCII termináis, has received performance en-

IBM SYSTEMS JOURNAL, VOL 26, NO 4, 1987

LOUCKS AND SAUER 337
 Figure 13 AIX terminal support structure

ACTIVITY
MANAGER
USER LEVEL GRAPHICS
SUPPORT
LIBRARY (GSL) VIRTUAL
TERMINAL (VT)
CONTROL

MONITORED
(EXTENDED) CURSES

TELETYPE (TTY) GENERIC SUPPORT

RIVER
/ER | < GH-FUNCTION TERMINAL (HFT .

H I G H - F U N C T I O N T E R M I N A L (HFT)
V I R T U A L R E S O U R C E M A N A G E R (VRM)

ASYNCHRONOUS
DEVICE HANDLERS

hancements and has been compatibly extended to consolé. These functions are designed to provide an
provide access to the extended font and other func- application programming interface to applications
tions of the RT Personal Computer native displays. desiring this level of interface, as well as the APA
We also added functions such as screen división and device-driver function to higher-level graphics and
layering logic to give applications a high-level, de- window services.
vice-independent interface.
APA support The monitored mode support provided Usability e x t e n s i o n s
by the VRM is managed by the kernel HFT device Single user. Because we expected RT Personal Com-
driver via a set of i/o controls and signáis. These puters to be used both as single-user workstations
facilities ensure proper behavior by applications us- and as traditional UNIX time-shared systems, we
ing this feature. If an application refuses to relinquish believed that some changes were required to support
control of a virtual terminal, the HFT driver, after the workstation user. We have made some altera-
waiting for a specified time period, terminales the tions to reduce the number of situations in which a
application. The application selects the mode in user has to exercise "superuser" authority. We added
which to use the virtual terminal. the ability to define more than one group to which
The Graphics Support Library (GSL) provides a set a user belongs at any given time. This feature, de-
of high-performance graphic, text, and ráster output rived from BSD 4.2, allowed us to define users as
primitives and a set of input functions for the local
IBM SYSTEMS JOURNAL, VOL 26. NO 4, 1987

338 LOUCKS AND SAUEB

members of the system group. System group mem- • An extensive character set including mathematics
bers can perform a number of operations that pre- symbols and multinational characters has been
viously could be performed only by a superuser; only added. For example, characters such as á, é, -k can
the most hazardous commands are still restricted to be included in an RT Personal Computer data
superuser authority. This technique gives the user of stream.
a prívate workstation a simpler environment to work • The formatting of data such as currency, date, and
in, while preserving the existing AIX authority struc- time in accordance with the requirements of a
ture for multiuser environments. For users who wish particular country has been included. For exam-
to opérate their systems in a manner similar to P C ple. in some countries dates are traditionally writ-
systems, a configuration option was added to allow ten with the year first; in other countries, dates are
automatic log-on at system start-up time. written with the month first.
• Data processing has been included that is consist-
Menú shell. The UNIX system has a dual-purpose ent with the characteristics of a particular national
command language. The commands have been de- language. For example, the operating system can
signed from the beginning to be primitives of a son in alphabetic order, according to the particular
command procedure programming language, some- conventions of each supported country.
times at the expense of ease of use when individual
commands are submitted from the terminal. This The RT Personal Computer international-character
makes the management of files and the performance support benefits more than just non-U.S. English
of common operations unnecessarily complex. users. For example, an extensive character set of over
Many UNIX installations solve this problem by build- 500 characters allows users to créate text that in-
ing sets of procedures that effectively constitute a cludes non-alphanumeric symbols (such as many
command meta-language. We chose to combine the mathematical symbols).
solution to this problem with the construction of a
full-screen interface to A I X . " The usability package Diagnosis and debug. To simplify the diagnosis of
provides Files, which is a full-screen file management problems in AIX, we added several debugging tools
utility similar to FILELIST on V M / C M S , and Tools. that include a trace mechanism, a mechanism for
which is the ability to request the most common AIX logging of errors and system messages, and a mem-
commands via a menú interface. The dialog manager ory-dump capability. The standard facilities were
that is used to implement these Utilities is general extended where necessary to deal with the unique
enough to serve application programs as well as AIX features of AIX and the RT Personal Computer hard-
commands. 12 ware.
The Files and Tools applications of the usability Expanding the application development
package can be extended to cover new types of files: environment
new actions that can be performed against those files
can be defined: and new tools—including complete To be able to support the full range of modern
full-screen applications—can be added. The dialog applications. AIX incorporated several functional ex-
manager in the usability package can also be used to tensions. The most significant enhancements have
provide new full-screen applications with an inter- been the following:
face that is consistent with the interface presented by
Files and Tools. • A broad spectrum of technical and commercial
programming languages
PC D O S compatibility. AIX also includes a new shell • An SQL datábase manager and an indexed access
that processes P C DOS commands, conversión pro- method
grams that transform data from PC to RT Personal • Industry standard graphics subsystems
Computer format, and subroutines that allow appli- • Connectivity enhancements to allow RT Personal
cations to read Dos-formatted diskettes and mini- Computers to communicate with both IBM and
disks. 13 non-iBM systems, in Local-Area Networks (LANS)
and over Wide-Area Network (WAN) telecommu-
National-language support. The UNIX system has nications links
historically been an English-only operating system. • Window support services
We have added significant national-language support • Distributed services for interconnected RT Per-
in the following form: sonal Computers to be used cooperatively and to

IBM SYSTEMS JOURNAL, VOL 26, NO 4, 1987 LOUCKS AND SAUER

 allow múltiple applications to work effectively on Figure 14 Summary of RT Personal Computer connectivity
the RT Personal Computer
Languages. The higher-level language compilers for
the RT Personal Computer were chosen on the basis
of the number and types of programs that have been
written in those languages. We selected dialects that
would facilítate propagation of programs from the NON-IBM
-S'\C
IBM Personal Computer, other IBM mainframes, and
other U N I X systems, with language extensions where
necessary to support the AIX environment. In some
cases, the compilers have two modes—one for pro-
grams from the PC, and one for programs from z .
minicomputer or mainframe environments. We de-
veloped a new subroutine linkage convention that
supports multimodule programs written in several
languages. 14 PC
/
Data management. One of the most critical require-
ments was for a datábase program supporting IBM
SQL to provide both users and application program-
mers with relational datábase facilities. We also
added a b-tree-based data management program that = =
permits either record-level or field-level access. Al-
though these subsystems are packaged separately
from the operating system, they become an integral
part of the file system when they are installed.
Graphics interfaces. AIX provides a family of differ-
ent interfaces to the consolé display. Versions of a
standard Virtual Device Interface (VDI) and a Graph-
ics Kernel System (GKS) are available from third-
party vendors. We provide graPHlGS™, an imple- =».' VIA SNA

mentation of the emerging Programmer's Hierarchi- OR TCP'IP

cal Interactive Graphics Standard (PHIGS). (graPHlGS

is a trademark of the International Business Ma-
chines Corporation.) This implementation provides
application portability from IBM mainframes and
supports all of the graphics device attachments of
the RT Personal Computer, including the IBM 5085.
Communications. Because the RT Personal Computer
is intended to be able to communicate with both IBM
and non-iBM systems, AIX must include support for
a wide variety of Communications protocols. AIX 11111 n t i n i i i i Í I I I 11 i n i

supports Asynchronous, Bisynchronous (BSC), SDLC,

CUT, DFT, Ethernet™, and Token-Ring connections. Zo = -
We have included both the industry-standard
T C P / I P and the IBM SNA protocols (LU I, 2,3, and 6.2).
The RT Personal Computer can be a bridge among
múltiple different LANS, able to support up to two
Ethernet and two Token-Ring LANS from a single RT
Personal Computer. Figure 14 summarizes the range
of connectivity available. (Ethernet is a trademark
of Xerox, Inc.)

IBM SYSTEMS JOURNAL VOL 26, NO 4, 1987

340 LOUCKS AND SAUER
IBM SYSTEMS JOURNAL, VOL 26, NO 4, 1987
LOUCKS AND SAUER 341
 Figuréis X-Windows exampie

SESSION WITH VM OR MVS

LOCAL RT PC
APPLICATION

OUTPUT OF
REMOTE RT PC
APPLICATION

Window management. Another subsystem that is Distributed S e r v i c e s

available is the X-Window System. X is a space-
shared, multiprocess window service that was devel- RT Personal Computer Distributed Services ( R T / D S )
oped under the auspices of Project Athena at the provides distributed operating system capabilities for
Massachusetts Institute of Technology. 17 One of the the AIX operating system. These include distributed
key capabilities included in X is the TCP/iP-based files with local/remote transparency. a form of sin-
network support that allows windows to contain data gle-system image and distnbuted interprocess com-
from X applications running on other computers munication. The distributed file design supports tra-
that are connected via Ethernet or Token Ring. See ditional AIX and U N I X file system semantics. This
Figure 15. allows applications, including data management/

IBM SYSTEMS JOURNAL, VOL 26, NO 4, 1987

342 LOUCKS AND SAUER
 datábase applications, such as SQL/RT, to be used in Note that caching effects can make some distrib-
the distributed environment without modification to uted operations faster than a comparable single-
existing object code. The design incorporates IBM machine operation.
architectures such as SNA and some of the architec- • Network media transparency. The system should
tures of Sun Microsystems N F S . 1 5 1 6 be able to run on different local- and wide-area
networks.
Design goals. The primary goals in our design of • Support of mixed administrative environments.
distributed services were the following: VN e believe networks are evolving toward hetero-
geneous collections of prívate machines, i.e., sin-
• Local/remote transparency in the services distrib- gle-system-image clusters of machines, and' ma-
uted. From both the user's perspective and the chines that act as servers for múltiple machine/
application programmer's perspective, local and system images. This necessarily implies múltiple
remote access appear the same. administrators with complex interrelationships.
• Adherence to AIX semantics and UNIX operating • Security and authorization. Comparable to these
system semantics. This is corollary to local/remote are those for a single multiuser machine.
transparency. The distribution of services cannot
change the semantics of the services. Existing ob- Hle system. Distributed Services uses remote
ject code should run without modification, includ- mounts to achieve local-remote transparency. A re-
ing datábase management and other code that is mote mount is much like a conventional mount in
sensitive to file-system semantics. the UNIX operating system, but the mounted file
• Remote performance and local performance. This system i s o n a different machine than that mounted
is also corollary to transparency. If remote access on directory. Once the remote mount is established,
is noticeably more expensive, transparency is lost. local and remote files appear in the same directory

Figure 16 Example shared file system

BIN
DEV
E T C
FILE-GRANULARITY SHARING - PASSWD. GROUP • • . FROM ' ETC SEi
LIB
TMP
U
(USERS' "HOME" DIRECTORES) - SHARED FROM DATA SERVER
LOUCKS
SAUER

USR

ADM
B I N
SHARED FROM "APPLICATION SERVER" MACHINE
INCLUDE

LIB SHARED FROM "APPLICATION SERVER

LPP SHARED FROM "APPLICATION SERVER

SPOOL
SVS
TMP
MOUNT POINTS

IBM SYSTEMS JOURNAL, VOL 26. NO 4, 1987

LOUCKS AND SAUER
343
 Figure 1 7 Architectural structure of Distributed Services file system

SYSTEM CALLS j
SYSTEM CALLS
I
VNODES AIX
VNODES REMOTE

POTENTIAL AIX
POTENTIAL AIX AIX LOCAL
REMOTE EXPANSION
EXPANSION LOCAL

VIRTUAL
VIRTUAL CIRCUIT
CIRCUIT INTERFACE
INTERFACE

LU 6.2

SERVER SIDE
CLIENT SIDE ETHERNET-
SDLC

hierarchy, and—with minor exceptions—file system Cited references

calis have the same effect regardless of whether files 1. R. O. Simpson and P. D. Hester. "The IBM RT PC ROMP
(directories) are local or remote. Mounts, both con- processor and memory management unit architecture." IBM
ventional and remote, are typically made as part of Systems Journal 26, Ño. 4. 346-360 (1987. this íssue).
system start-up, and thus are established before users 2. D. M. Ritchie and K. Thompson. "The UNIX time-shanng
log on. Additional remote mounts can be established system," Communications of the ACM 17, No. 7, 365-375
(Juty 1974).
during normal system operation. 3. T. G. Lang, M. S. Greenberg. and C H. Sauer, "The virtual
resource manager." RT Personal Computer Technology (pp.
Figure 16 gives an example view of a shared file 119-125), SA23-1057. IBM Corporation; available through
system seen by one machine in a single system image IBM branch offices.
4 J C O'Quin. J. T. O'Qum. M. D. Rogers, and T. A. Smith.
cluster. Figure 17 illustrates the structure of the RT "Design of the IBM RT PC Virtual Memory Manager." RT
Personal Computer Distributed Services files system Personal Computer Technology (pp. 126-133). SA23-1057,
(RT/DS). IBM Corporation: available through IBM branch offices.
5 D C. Baker. G. A. Flurry. and K. D. Nguyen. "Implementa-
tion of a virtual terminal subsystem," RT Personal Computer
Concluding remarks Technology (pp. 134-136), SA23-1057. IBM Corporation;
available through IBM branch offices.
AIX is a portable operating system. Written mostly 6. R. Krishnamurty and T. Mothersole. "Coprocessor software
support," RT Personal Computer Technology (pp.
in the c language, it is intended to be migratable to 142-148), SA23-1057, IBM Corporation: available through
new hardware platforms as they emerge. We believe IBM branch offices.
that in AIX we have combined a portable and versatile 7. L. K. Loucks, "IBM RT PC AIX kernel—modifications and
industry-standard application programming envi- extensions," ^ 7 " Personal Computer Technology (pp.
ronment with contemporary hardware and operating 96-109), SA23-1057, IBM Corporation: available through
IBM branch offices.
system architecture. The resulting operating system 8 J M Bissell, "Extended file management for AIX," RT Per-
is suitable for use with a wide range of computer sonal Computer Technology (pp. 114-125). SA23-1057. IBM
architectures and customer requirements. Corporation; available through IBM branch offices.

IBM SYSTEMS JOURNAL. VOL 26. NO 4, 1987

344 LOUCKS AND SAUER

 9. S. R. Kleinman, "Vnodes: An architecture for múltiple file anee Modeling. also co-authored with E. A. MacNair. He has
system types in Sun UNIX," USENIX Conference Proceed- received IBM Outstanding Innovation Awards for the creation
ings. Atlanta, June 1986, pp. 238-247. and basic design of the Research Queueing Package (RESQ) and
10. S. Lerom, L. Terrell. and H. Advani, "Configuration methods for the RT Personal Computer Virtual Resource Manager.
for a personal computer system," RT Personal Computer
Technology (pp. 91-95), SA23-1057. IBM Corporation; avail-
able through IBM branch offices. Reprint Order No. G321-5300.
11. P. J. Kilpatrick and C. Greene, "Restructuring the AIX user
interface," RT Personal Computer Technology (pp. 88¬
90). SA23-1057, IBM Corporation; available through IBM
branch offices.
12. T. Murphy and D. Verburg, "Extendable high-level AIX user
interface," RT Personal Computer Technology (pp. 110-113).
SA23-1057, IBM Corporation; available through IBM branch
offices.
13. L. F. Brissette, R. A. Clauson, and J. E. Olson, "PC DOS
emulation in a UNIX environment," RT Personal Computer
Technology (pp. 147-148), SA23-1057, IBM Corporation;
available through IBM branch offices.
14. J. C. O'Quin, "The IBM RT PC subroutine linkage conven-
tion," RT Personal Computer Technology (pp. 131-1331.
SA23-1057, IBM Corporation; available through IBM branch
offices.
15. C. H. Sauer, D. W. Johnson, L. Loucks, A. A. Shaheen-
Gouda, and T. A. Smith, "RT PC Distributed Services: File
system," ACM Operating Systems Review (July 1987).
16. C. H. Sauer, D. W. Johnson, L. Loucks, A. A. Shaheen-
Gouda. and T. A. Smith, "RT PC Distributed Services: Over¬
view," ACM Operating Systems Review, 18-29 (July 1987).
17. R. W. Scheiflerand J. Gettys, "The X window system," ACM
Transactions on Graphics 5, No. 2, 79-109 (April 1986).

Larry Loucks IBM Advanced Engineering Systems IBU. 11400

Burnel Road. Austin, Texas 78759. Mr. Loucks. the lead architect
of the RT system, is a member of the IBM Sénior Technical Staff.
He received a B.A. in mathematics in 1967 from Minot State
University, Minot, North Dakota. Mr. Loucks joined IBM in 1967
in the Fargo, North Dakota, b r a n c h office. In 1970, he transferred
to Raleigh. North Carolina, where he worked on SNA and other
C o m m u n i c a t i o n s produets. In 1977, he transferred to Austin.
Texas, where he worked on the IBM 5520 Admmistrative Svstem
and the RT system. He has received three IBM Inventíon Achieve-
ment Awards and has been honored with IBM Outstanding In-
novation Awards for his work on SNA, on the 5520, and on the
RT system.

Charles H. Sauer IBM Advanced Engineering Svstems IBU,

11400 Burnet Road. Austin. Texas 78759. Dr. Sauer received his
B.A. in mathematics and Ph.D. in computer sciences from the
University of Texas at Austin in 1970 and 1975, respectively. He
joined IBM at the Thomas J. Watson Research Center in 1975.
From 1977 to 1979, Dr. Sauer was an Assistant Professor of
computer sciences at the University of Texas at Austin. In 1979.
he returned to IBM Research, and in 1982 transferred to the IBM
Communication Products División Laboratory in Austin, Texas.
Currently. Dr. Sauer is a Sénior Technical Staff Member and lead
architect for AIX. Dr. Sauer has published three textbooks. Com-
puter System Performance Modeling, co-authored with K. M.
Chandy, Simulation of Computer Communication Systems, co-
authored with E. A. MacNair, and Elements of Practical Perform-

BM SYSTEMS JOURNAL, VOL 26, NO 4, 1987

LOUCKS AND SAUER 345