“A very good place to start” – Oscar Hammerstein II
Late last year I became aware of “The Unix Heritage Society”, a fascinating archive and mailing list on UNIX history (and often, tangential topics). Even Ken Thompson occasionally contributes.
There have been various TUHS discussions of AIX in the 1980s, the RT/PC, etc. Often I want to say, “no, that’s not how it was, or, at least, not how it seemed to me when I was in the middle of things”, but I’ve avoided joining those discussions.
Since I don’t know of a good history of AIX, nor the associated hardware projects prior to the RS/6000, this is my attempt to say what I can to clarify and fill in the lesser known history. (Peter Salus’ A Quarter Century of Unix is a comprehensive reference, but barely mentions AIX. The RT book is a snapshot at the time of the first release and only incidentally covers history. AIX Turns 20 reflects on the first two decades.)
I have asked some IBM Austin colleagues and someone formerly with Locus Computing Corporation (LCC) to review this, and have reacted to their comments, but I’ll assume responsibility for whatever is right or wrong here. [Sadly, Phil Hester (primary hardware person), Larry Loucks (primary software person), and Jerry Popek (LCC co-founder) have passed away. I’ve lost touch with Bruce Walker, my primary LCC contact.] I’ll mostly avoid crediting the many individuals involved.
I’ve tried to make this brief and self-contained, but realize that some combination of prior knowledge or reading the cited references will be needed for many readers.
I first became aware of UNIX when the July ’74 CACM paper was published. I was too busy finishing graduate school to do more than read the paper, but the paper intrigued me.
In March ’75 I joined IBM’s Watson Research Center (Building 801) in Yorktown Heights (aka YKT). I inquired about getting UNIX access and was strongly discouraged by those I spoke to. That seems ironic today for many reasons, the first UNIX paper having been presented in that building in 1973.
Like other researchers there, I used VM/370. (I occasionally submitted long running simulation jobs to MVS systems.)
[Another anecdote about the then insular IBM environment: I inquired about ARPANET access and was rebuffed. A colleague, a student of Kleinrock’s, had worked with him on ARPANET but didn’t have access in Yorktown.]
I left Yorktown for UT-Austin C.S. department in 1977. I inquired about UNIX access and was again discouraged, but was told that The Daily Texan (large scale student newspaper) used UNIX for typesetting. (CDC and TOPS systems prevailed, IIRC.)
I went back to Yorktown 1979-82. One of my colleagues was granted permission to have a UNIX system on premises, restricted so that only he had access.
Summer 1981 a friend (preceded me at UT CS, in 1981 a Purdue prof, now neighbor down the street) came to Yorktown and gave a talk about UNIX. It was dismaying that my YKT colleagues seemed unimpressed. At lunch, one implored me to convince my friend that the YKT enhancemnts to the CMS EXEC stack paradigm were preferable to pipes.
801, ROMP, PL.8 and CP.R
The 801 minicomputer project started about the time I joined IBM Research, but I was not involved with the 801, just generally aware of what was being done. Besides the hardware architecture and prototype, 801 depended on an aggressive optimizing compiler, a new language, PL.8, that began as an almost-compatible subset of PL/I, and a “control program”, CP.R.
The ROMP/PL.8 project was initiated by the IBM Office Products Division (OPD) in 1977 in Austin, starting with the 801 architecture and PL.8 language and compiler. This effort became known as the Research – OPD – MicroProcessor and was given the acronym ROMP.
The companion virtual memory management chip “Rosetta” implemented a “single level store” address translation architecture partitioning 32-bit addresses into 4 bits for segment identifiers, selecting a 12 bit segment register, and 28 bits for offset within the segment, yielding a 40-bit (1 terabyte) virtual address for translation. CP.R was designed to take advantage of this addressing architecture.
AFWS, VRM and UNIX
In 1982, I transferred to IBM’s development lab in Austin to work for Glenn Henry on the fledgling “Advanced Function Workstation” (AFWS) project. Glenn had been the leader and manager of the IBM System/38, an innovative minicomputer. There had been a reorganization at IBM Austin that allowed Glenn to lead an “ad tech” organization. Primary development at IBM Austin focused on successors to Displaywriter and the 5520 Administrative System (a robust networked office system). The ROMP and PL.8 groups were included in Glenn’s organization, and prototype hardware was developed.
Initially, we intended to provide a hypervisor of our own design, the Virtual Resource Manager (VRM), supporting several user level system environments and taking advantage of the 40 bit addressing architecture. After initial design reviews and recognition of the infeasibility of the overly ambitious development efforts we had been contemplating, we scaled back the VRM “virtual machine interface” (VMI) and settled on starting with UNIX. By the end of ’82 we had contracted with Interactive Systems Corporation (ISC) to provide System III on the VRM, enabling virtual memory not present in System III.
ROMP-based hardware was precious and scarce. I still didn’t have hands on access to UNIX until I got PC/IX on an XT. That was displaced by a PC/AT running Xenix until I got my own RT running AIX (and later the 4.xBSD ports for the RT).
IBM (Austin) Reorganizations and Product Redefinitions
The former LCC person has mentioned that IBM then seemed like N competing companies. Actually, it was more like Mn competing factions within N competing companies.
In 1983 the IBM Austin plan for Displaywriter successor was scrapped, a site-wide reorganization took place, and the AFWS project was redefined to be a primary site effort. What had started as a relatively speculative project became a formally planned product, with ambitious plans for inclusion of traditional IBM technologies, e.g., System Network Architecture, and formal IBM review and “system assurance” infrastructure. The development organization grew in size by an order of magnitude.
The ISC agreement was enlarged in scope, with System V instead of System III.
However, most of IBM was not excited about this. The traditional product organizations, e.g., those associated with the 370 and the System 3x, saw little need for UNIX or a new hardware architecture. The renegade but surprisingly successful PC organizations looked askance for their own reasons. Even the Yorktown partners were partly detrimental because of disdain for UNIX.
Reorganizations and product redefinitions caused course changes from emphasis on a technical workstation, to office focus, to multiuser alternatives to the System/3x, to an enhanced PC, etc. The collection of these definitions led to inclusion of a kitchen sink of software features, and hardware options. Implicit or explicit in many of the reorganizations was executive desire to terminate the project. The original hopes for a 1984 product release turned into the RT/PC and AIX 1.0 release in 1986, with many of the intended features and options not ready for release at that time.
(lack of) Optimizing Compilers
The product delays resulted in a much less competitive product than had been anticipated. If the product had shipped a year or two earlier it would have been more competitive. However, the vanilla port of pcc severely limited performance — ROMP (and 801) fundamentally assumed use of a sophisticated optimizing compiler, such as the PL.8 compiler.
There were two remedies to the need for an optimizing compiler. The tactical remedy was to get HCR Corporation to add their pcc optimizer phases to the AIX pcc. The strategic remedy was to get the PL.8 compiler to handle C as well as PL.8. At first cross-compiling was necessary but eventually the PL.8 optimizing technology became a C compiler as part of the product offerings.
AIX 2 and Yorktown Influx
In spite of the problems, the initial product was enough to galvanize support for 801 inspired processors and UNIX-based software. While the existing IBM Austin organization persevered in AIX 2 and faster hardware, an influx of nominally Research people from Yorktown moved to Austin to help build AIX 3 and the hardware that became the RS/6000. ISC involvement was limited.
AIX 2, with the HCR optimizer and most of the originally planned features, was released in 1987. See Advanced Interactive Executive (AIX) Operating System Overview, for Larry’s summary of AIX 2.
My understanding is that IBM eventually licensed SVR3, but as far as I know, little if any AT&T kernel code after SVR1 was incorporated in AIX. It is plausible that more recent AT&T user level code was included.
Distributed Services and LOCUS
Distributed file systems were a hot topic for research and development in the 1980s. Sandberg’s NFS paper says “Why, you may ask, do we need NFS when we already have Locus, Newcastle Connection, RFS, IBIS and EFS. In most cases the answer is simple: NFS is designed to handle non-homogeneous machines and operating systems, it is fast, and you can get it today. Other than the Locus system, which provides file replication and crash recovery, the other remote filesystems are very similar to each other.”
We were probably most aware of Locus, NFS and RFS, but leery of scalability of Locus and leery of NFS’ stateless semantics. We chose to provide yet another, RT/PC Distributed Services.
Locus implementation on System 370 was popular in some IBM factions, so there were ongoing challenges as to why we didn’t adopt what Locus had pioneered. Besides our technical concerns about distributed system issues, the implicit question seemed an all or nothing proposition of continuing AIX vs. IBM depending on LCC for UNIX.
With the infusion of help from Research, and the anticipation of the new processors and hardware that would become the RS/6000, we both wanted to fix the limitations of AIX 2 and prove what could be done better than competitors’ implementations in AIX 3.
Much of the code, the VRM, the (PL.8) compiler and other auxillary programs still existed in PL.8. In general, the PL.8 code was rewritten in C. With help from an ISC colleague, I had created a PL.8 to C translator using Icon, that was used to facilitate some of the rewriting.
The Virtual Machine Interface was abandoned. The integrated kernel would be preemptive. A journaled file system, a logical volume manager, reimplemented distributed services, sockets, NFS, … would be added. I left IBM before AIX 3 was released, and am unsure about what code actually shipped, but my impression is that it closely matched the ambitious planning.
In addition to AIX, there had been 4.2BSD and 4.3 ports to the RT. With the momentum behind the new hardware and AIX, IBM did not want to perpetuate BSD ports. A team of AIX people, IBM people working on BSD, and Bruce Walker of LCC spent months defining a convergence of AIX & 4.3BSD to be implemented in AIX 3 and the anticipated LCC “AIX” products.
Though we in Austin were focused on the hardware that would become the RS/6000, there were others in IBM who saw the need for UNIX on System 370 and 386-based PS/2 machines. The Locus distributed system technology seemed especially apropos to one or more 370s accessed with PS/2s, somewhat of a modern analog to 3270s accessing VM/370 and MVS/TSO. LCC took development responsibility for what would become AIX/370 and AIX PS/2.
LCC’s distributed system technology was named TCF (transparent computing facility) and included in the 370 and PS/2 products. Much of the AIX code developed for the RT and RS/6000 would not be included in the 370 and PS/2 products. The Austin & LCC kernels were dramatically different — the LCC kernel likely much more recognizably like prior AT&T & BSD sources.
In July 1988, IBM published the IBM AIX Family Definition Overview to define “AIX” across the various platforms.