The Genesis of the Tenet 210: An Early Time-Sharing System

By: Chuck Runge, co-founder and VP  Software Development                                                     Editor: David Walden

In 1966, I was busy working on interesting compiler and operating systems projects at the Atomic Energy Commission at Iowa State University. In June of that year, I had an opportunity to join Fairchild R&D Labs in Palo Alto, California, and I did so, with the dual objectives of learning more about hardware design and building commercial products.

Based on the promise of “exploring the boundary between hardware and software,” I became the first systems programmer to work on the design of Fairchild’s large time-sharing system code-named Symbol IIR. Almost immediately, however, several department management decisions came to light that would kill any chance of Symbol IIR’s becoming a commercial product. The outcomes of those decisions meant: no ability to develop shared code/libraries; 100 percent translation of industry-standard languages to Symbol’s PL/1–like native language could not be done; no software or firmware could be used to implement the system; and a pure hardware implementation could not respond effectively to the inevitable bug fixes and required technology advances.

These drawbacks set me to thinking—after all, a key reason I had joined Fairchild was to work on commercial products. A colleague, Dave Masters, and I frequently discussed the Symbol IIR, in particular its long development cycle and its inability to satisfy commercial requirements. We discovered we had similar objectives and decided to work together to pursue them. This began a 16-year working relationship during which we collaborated on a number of industry-leading ventures, most notably the Tenet 210 general-purpose time-sharing system. This article is my best recollection of events that occurred almost 40 years ago concerning that project.

Time-sharing on the horizon

Business time-sharing was becoming viable in the late 1960s. Typical systems were inefficient because subsystem components were not designed for the application. Low-end systems were generally interpretive, single language, and built on small platforms. High-end systems were built on larger platforms and were accessed through service bureaus whose storage and connect-time charges made budget control almost impossible; and data/software security was minimal at best.

Dave and I thought we could design a system to meet the requirements of general-purpose time-sharing, provide mainframe power at a superminicomputer price point, and target sales of time-sharing systems to companies for in-house use. We envisioned connecting systems to create a larger, scalable networked multiprocessor system, which we called the Tenet 210. 

Accordingly, Dave and I left Fairchild in 1968 to found TENET Inc. We devoted several months to the business plan. Tom Bay, former general manager of Fairchild and an early investor in Data General, introduced us to another investor, Fred Adler, who was a trial attorney. Adler conducted an “in your face” inquisition about our understanding of what we were undertaking and our confidence in delivering on our claims. We survived his test and obtained more than $2 million, for which we committed to build two prototypes in 24 months. We thought this level of funding would let us retain more of the company and that we could easily acquire funding for production when we had working machines, a decision we later regretted. Regardless, in early 1969 we set off to find facilities—an old Lockheed building in the industrial section of Sunnyvale, California—and begin staffing.

Dave and I also started work on the system design. Dave characterized the computer’s underlying structure as follows:

· A “data exchange” based architecture connecting system components of memory modules, CPUs, and I/O processors (IOPs) via four simultaneous memory channels with DMA

· Scalability by connecting additional system components to the data exchange

· Interleaved dual 32-bit memory buses providing 20 Mbyte/sec bandwidth

· CPU equipped with eight general registers and eight control registers

· I/O system of 20 bidirectional DMA channels with access priority

I began the software specification and design, primarily the operating system (OS). We intended to design the Tenet 210 from the top down, first by considering the user experience, then the OS, tools, and languages to support that experience, and finally the architecture as seen by the systems programmers. This included the CPU register layout and addressing; instruction set; systems for memory management, traps, and interrupts; and I/O subsystems to support the software.

Progress was steady while we raised money and accelerated rapidly when we hired our first staff. Jack Morris, who worked on the Fairchild Sentry tester with us, was hired to design the CPU and memory management unit (MMU) logic. Jack understood software and its importance to the system’s success and worked on Tenet’s underlying physical architecture. Larry Krummel, fresh from obtaining his Stanford master’s, was hired for the Tenet Basic subsystem. This was a great team—they were knowledgeable, creative, and worked well together.

As the design of the OS and the hardware logical/physical architecture proceeded, we produced a 180-page specification and a preliminary design of the OS and the services it provided to applications.

The specification and the core team provided a level of efficiency and productivity that produced the OS, Exec, meta-assembler, Fortran IV, Tenet Basic, Editor, and tools with a staff equivalent of eight full-time employees. Our hardware team was comparably sized and productive. Few believed us when we said we would, with such a small budget and staffing level, produce the Tenet 210 within 24 months.

In January 1971, any doubts of our missing the 24-month timetable were dispelled when we hosted a “musical happening” that accompanied the Tenet 210’s introduction. The event was attended by the press, musicians, academics, businesspeople (including one of our directors, Intel’s Bob Noyce), and students. The San Mateo East West Music Ensemble and a San Francisco Symphony solo pianist demonstrated nonscientific applications of the Tenet 210 with a primitive music synthesizer we developed specifically for the occasion.

Developing the Tenet 210

Program swapping was a major factor in determining how many users the system could support, and reducing it was a significant OS design challenge. Commonly, time-sharing systems of that era used a RAD, a head-per-track disk, for swapping. My pencil-and-paper modeling convinced me we could do program swapping less expensively on the same moving-head disks used for file and program storage. But to do that, we had to address numerous hardware and software issues, such as:

· Developing a rich instruction set for compact systems and application code

· Identifying, by the MMU, modified read/write virtual pages

· Assigning real pages to read/write virtual data pages only when referenced to reduce demands on real memory

· Load-leveling by swapping to the least busy device

· Maximizing disk throughput by moving programs and data occupying multiple discontinuous blocks of real memory to disk in a single write, and reversing the process with a single read operation

· Minimizing rotational delays

· Sorting read/write lists to minimize disk latency

· Reducing demands on real memory with executable programs (e.g., compilers) to which applications could dynamically link, and which applications could share

· Forcing dynamically linked executables, on initial loading, to be swapped out, which moved them from discontinuous file space to sequential swap space

· Balancing CPU usage against response time by biasing the swapper/scheduler algorithms toward providing uniform (rather than fastest possible) response times, which also reduced the swapping imposed by compute-intensive tasks

· Moving command line editing functions from the application to the serial I/O drivers, thereby saving many context switches and program swaps 

The production language processors integrated the compiler, editor, linker, and debugger in a single subsystem. Language statements could either be saved as part of a larger program or executed separately and immediately; immediate execution was great for debugging and allowed the debugging capability’s syntax and semantics to be consistent with the language being debugged. The compilers generated space and time-optimized native code by using local code optimization techniques, such as common subexpression elimination and multiple branch elimination and provided iterative debugging. Our Tenet Basic extensions included explicit data declarations; rich data types—integer, real, double, character, complex, double complex; built-in character manipulation functions; mixed-mode arithmetic; N-dimensional arrays; identifiers up to 16 characters long; and multiline subroutines and functions.

We optimized the 210’s instruction set for the systems programmers. We were concerned about both space and time efficiencies; the result was a code set that produced compact code, good execution times, and which contributed to minimizing demands on real memory and reducing the swapping load. Features of the Tenet 210’s instruction set included these:

· Programmed Instructions, one-argument function/subroutine calls in four bytes, provided custom, compact instructions for implementing system tools

· Packing and unpacking variable-length fields in words

· Testing, locating, setting, and resetting bits for managing allocation maps of systems resources

· Immediate instructions, using the address field as data, instead of the data’s address

· Gathering/scattering blocks of memory

· Memory searches

· Converting addresses from virtual to real

· Rich condition codes and conditional branching

· Pre- and postindexing for managing data structures

· General registers for arithmetic, logical, and bit operations as well as indexing

· Floating-point object code to run unchanged on machines with or without the floating-point hardware option

Market entry

We responded to an RFP from the State of California for a system to support 800-plus civil engineers around the state designing roads and bridges. We were competing with IBM, General Electric, Digital Equipment, Hewlett-Packard, and others. The RFP required us, at an unspecified time, to demonstrate the state’s benchmark tests on the Tenet 210—this meant having 32 simultaneous users running production civil engineering programs and providing the required response times. The state gave little warning and called us the day before they wanted to run the benchmarks.

While this was a welcomed call, it also initiated an interesting 36 hour fire drill. Up until that time, we had only run about 8 simultaneous users and didn’t have the 32 terminals needed. We spent the day borrowing the remaining terminals from friends and logging them on, which went well until we logged the 25^th user on and the system crashed. We couldn’t figure out why, and left late that evening with a story of why we could only demonstrate 24 users and with the hope that we would get another chance if needed.

Although I hadn’t written any of the code, I was very knowledgeable about the instruction set, had done a detailed design of the OS and knew the OS tables and logic intimately. Around 3 a.m. I surmised that a boundary problem with the allocation of real memory to virtual memory was likely causing the crash. I immediately went to the office, found the defective code, patched it, and successfully logged on more than 25 users. We successfully ran all RFP tests and received encouraging comments from the evaluation team that led us to believe we had done quite well. Ultimately, we made the sale based on features and cost performance, which was so compelling that the State of California bought a small configuration to support 48 simultaneous users even though, by that time, TENET was actually in Chapter 11 bankruptcy proceedings. Even with the sale, we were unable to secure financing to sustain the company. TENET closed its doors with a couple of the staff remaining, sustained solely by a hardware/software maintenance contract with the State.

In retrospect: Comments

The Tenet 210 remained in operation for 10+ years in Sacramento with the second prototype used for spare parts. Eventually, California became concerned about their dependency on the 210. I met Woody Hobbs (now CEO of Phoenix Technologies) in the final days of Tenet and among the things we worked on together over the years was a proposal to the State that would run the State’s Tenet Basic programs on an IBM mainframe. While this provided freedom from the Tenet 210, it was still a single vendor solution and they opted to migrate all of the Tenet Basic to an industry-standard language supported by multiple vendors.

A side note: Steve Wozniak, Apple cofounder, worked for me at Tenet for a time as a diagnostic programmer. In his book iWOZ, he wrote the following of the Tenet 210:

My first non-student job was for Tenet Inc. in Sunnyvale.

During my second year of college I went looking for a place that might have had a Data General Nova minicomputer that I could look at. This is the computer I’d told my dad I was going to buy someday. My friend, Allen Baum, and I walked into the wrong door and saw a larger computer being constructed and in a display room. We were impressed and asked for applications and we were both hired as programmers.

I stayed on working for most of a year. I got to see some incredible computer hardware and software but economic times were bad and the company folded. I’d taken a year off of college and now had enough money to go to Berkeleythe following year.

Manuals for the Tenet 210 time-sharing system can be found at http://bitsavers.org/pdf/tenet/. They may seem primitive by today’s standards but were fairly progressive for that era.

Most software people we interviewed from major computer manufacturers loved the 210’s hardware and OS. Early in the OS design, investor Adler brought in the brain trust of Xerox Data Systems Universal Time-sharing System (UTS) to conduct due diligence on the OS. We got high marks and a few good ideas from them, but Xerox also got many good ideas from us for its system. Further confirmation of the Tenet 210’s technical validity came when others submitted it to critical technical review. Tom O’Roark and senior Tymshare staff considered the 210 as a replacement for their aging SDS 940s, and senior HP management considered it as an alternative to the early failings of the HP3000, but deteriorating business conditions made these decisions too risky.

The Tenet 210 was a technical success, but the company failed for various reasons: we ran out of money as a recession set in; the timing was premature for the in-house time-sharing market (although this should not have been fatal); some of TENET’s managers did not understand our technology and market well enough; and some of the 210 team’s strong personalities proved disruptive. Then, too, on the strength of our first salesman’s claim that our facility—the old Lockheed building—was a sales stumbling block, we moved to a new building, an expense that contributed to our downfall. (An article in Business Week about Fred Adler and his Data General experience contained references indicating the move was probably a major factor in losing his support.)

Around the same time TENET was started, four other companies were formed to build and sell time-sharing systems. One of these, Berkeley Computer Corporation, was started by the brain trust of Project Genie, a time-sharing system built at the University of California, Berkeley, based on the SDS 940 (an SDS 930 with memory-mapping hardware added). Another outfit was started, I recall, by Tymshare alumni who had commercialized Project Genie to build a successful time-sharing service bureau with SDS 940s.

Of the four, TENET was the only company that succeeded in building and selling a mid-to-large-scale, general-purpose time-sharing product. TENET was more about advancing the business of time-sharing than about computer science, computer architecture, and invention. It combined practical ideas of others with many of its own to produce a system that was cost-effective, user friendly, and easy to install, operate, maintain, and support. The Tenet 210 was intended to be an in-house system that did not require an army of systems engineers to support it and its users. The 210 met that objective, and under different circumstances, this “whatever happened to …” article would have been unnecessary.