Blaauw box vs. DAT box on the S/360-67
Footnote 33 from VM AND THE VM COMMUNITY: Past, Present, and Future by Melinda Varian, April 1991, page 26
33 “Lincoln had a role in the design of the time-sharing machine. I have a copy of IBM’s
response to Lincoln’s Request for Quotation, which specified a Model 66. This machine was
later to become the 360/67, but I don’t know why the model number changed. A group of six
sites (Lincoln Lab, University of Michigan, Carnegie University, Bell Labs, General Motors,
and Union Carbide, I believe) had a non-disclosure agreement for the development of the
360/66. This group was called the ‘Inner Six’. At one meeting in Yorktown Heights, we met
with IBM people to discuss relocation hardware. We discussed whether an address should be
31 or 32 bits. We eventually voted and recommended 31 bits. We also discussed the design
of the relocation register and had some heated discussions with the IBM team. The Inner Six
met with IBM representatives behind closed doors at a SHARE meeting. We six sites
discussed various features of TSS and made recommendations to IBM. This was the
beginning of the SHARE TSS Project.” (J.M. Winett, private communication, 1990.)
Pages 61-66 from http://dl.acm.org/ft_gateway.cfm?id=1141883&type=pdf :
AKERA: . . . But returning again back to time-sharing, and particularly virtual memory, which is what we were just beginning to speak about, can you tell us a little bit more about the development of virtual memory? Both separate from and integrated with the time-sharing effort.
GALLER: Some of the early ideas came from the Atlas computer in England. They actually switched among users, but they didn’t have a two-level scheme, and it was not very efficient. But they had the idea of swapping and so on. Burroughs, also on the B5000, had a kind of a segmentation thing. Again, it was only, sort of, half the problem.
AKERA: I imagine most of these are simply software solutions, so that in terms of efficiency, the dynamic relocation hardware was not available in any of these systems until the earliest…
GALLER: I think that’s right, although the Atlas had a very sophisticated user-switching mechanism in hardware, saving the state of this user and bringing back the state of the machine.
AKERA: This is all meant to make those transitions as efficient as possible, as quick as possible?
GALLER: Right, but that was not really virtual storage, in a sense. So people had ideas and pieces of it. There were the MIT people who sort of envisioned the whole thing--
AKERA: Or at least wrote about it first.
GALLER: Or talked to us about it. As much as they were willing to talk, and then there was a whole controversy of whether we took their ideas and didn’t give them credit and so on. We thought we gave credit to Jack Dennis in that article because we felt that what we took from them was what he had told us.
AKERA: This is also an aside, but as a historian of technology, we tend very much to downplay priority disputes because most ideas happen because of the circumstances surrounding them. Similar ideas are floating around and things come together at different places. You know, simultaneous invention is something we talk about, and it’s a very frequent phenomenon. Nonetheless, there are intellectual lineages, and of course, to the participants, these are very important issues because this is about their academic reputations, and contributions.
GALLER: That’s right. So we worked with IBM, and as I said, with Gerrit Blaauw in particular. They proposed some things that we shot down, and then we proposed some things they shot down. It really was a good collaboration. We had some very good people on this—not only Westervelt, but Mike Alexander, who is still with us and so on.
AKERA: He first worked on LTS (Lincoln Terminal System), putting LTS on Michigan’s computer, and then transforming it into MTS eventually (Michigan Terminal System). [when talking about LTS here, Akera and Galler are actually talking about the Lincoln Laboratory Multi-Programming Supervisor (LLMPS); LLMPS was the supervisor upon which what eventually became the University of Michigan Multi-Programming Supervisor (UMMPS) was based; the Lincoln Terminal System was the initial name that was used briefly for what became the Michigan Terminal System (MTS); LTS / MTS was developed entirely at the University of Michigan; MIT's Lincoln Laboratory did develop something called Lincoln Terminal System (LTS), but that was a computer aided instructional system and had nothing to do with LLMPS, UMMPS, or LTS / MTS at Michigan. -Jeff Ogden, September 2014.]
GALLER: That’s right. Yes. LTS was a very nice, multitasking thing.
AKERA: The Lincoln Terminal System developed by Lincoln Laboratories.
GALLER: Not terminal system, but Lincoln Multiprocessing System, Multi-programming System—LMS, something like that.
AKERA: Hmm… but in any event, it was MIT’s Lincoln Laboratories, which was separate from Project MAC.
GALLER: That’s right. In fact, when IBM finally formed this group of the inner six important customers, Lincoln Labs was one of them. And GM and Princeton.
AKERA: In fact, I should probably ask you to spell out that history a little bit. But before going there, I think it is worth noting for the historical record (and you may not be familiar with this), but IBM did have very extensive conversations with MIT about the design of computer time-sharing systems, of which virtual memory and dynamic relocation hardware were very much part of the conversations. So one of the possibilities is that some of the knowledge that became embedded in the Michigan system, in the IBM hardware, may have come not through your group at Michigan, but through the history of conversations between MIT and IBM.
GALLER: Yes. We know that they had a falling out at some point, which is why they [MIT] went to GE. I guess we were never really aware of that other avenue of communication. We certainly didn’t take credit for everything. We just worked with IBM, and they came with ideas and we came with ideas.
AKERA: As much as the initial group at IBM evaluated the suggestions that Robert Fano, at MIT, advanced to them, IBM had quite a bit of internal discussion about what MIT was asking for. As a consequence, I think they did understand what the technical changes were that MIT asked for. That information was very broadly disseminated within the organization. I don’t know the specific history and all of the connections, but I believe Gerrit Blaauw may have been one of the participants in that conversation.
GALLER: He probably was. But as I recall, he was a hardware architect type person; we were software people. As I recall, when we began to talk to them, we realized that they had not thought through the software implications of all of this. That’s why we published our article, saying, “If you’re going to do this kind of thing, there are some interesting software issues.”
AKERA: Indeed, there was a lot of confusion within IBM, and they [probably] did not see the software side. [In speaking with MIT, there were definitely those within IBM who] couldn’t understand initially why you needed the dynamic allocation hardware because they didn’t know enough about operating system software to spell out [the implications]-- I think that’s absolutely correct.
AKERA: Perhaps more for the historical record, could you fill us in on the history, starting with the falling out at Project MAC with IBM, and then how Michigan came into the picture? How did that sequence of events happen?
GALLER: I’m not sure who contacted whom, now that I think of it. Well, we had been talking to various vendors, and--
AKERA: Even before Project MAC’s falling out. Is that right?
GALLER: I think so. We wanted to get involved.
AKERA: MIT received funding from ARPA IPTO under J. C. R. Licklider, and they held a series of meetings, particularly a summer study, in which IBM, General Electric, and other manufacturers were invited. At that point, Robert Fano proposed certain hardware changes, and General Electric turned out to be more responsive than IBM. IBM thought that their solution was adequate, and then was, in a sense, surprised [by MIT’s decision. Actually,] by the time the decision was made they knew how the decision was going to go, but they were very frustrated that MIT chose to work with General Electric rather than IBM, with whom they had a long-term relationship. Now, Michigan also had an established relationship with IBM going back to the very deep educational discount that IBM provided on Michigan’s leased 704 and 709 and 7090 computers. So there was already a precedent for working between Michigan and IBM, not so much at a detailed technical level, but at least in terms of the education discounts on the machines.
GALLER: Well, more than that though, because I was already doing operating system [development] on the 701 and 704 through GM, and interacting with IBM people at SHARE. For example, I pointed you to what we published as an anecdote just in the last year in the annals about relocation bits. If you look at that, what I’m discussing there is an IBM proposal for a whole new structure of relocation bits. So I was interacting with IBM people all the time, really. When they had a falling out with MIT, they probably came to us and said, “Would you like to work with us?” They wanted our contract. Whatever we were going to do, they wanted it on an IBM machine.
AKERA: My sense from the actual historical, IBM documents of this period…
GALLER: …Which I have not seen. I hope to see it someday.
AKERA: Exactly. Well, actually you saw some of them originally… You wrote some of them! Well, not the ones on the IBM side. But these are actually some of your own papers. I found some of these documents in the records of the University of Michigan Computing Center. But in any case, my understanding is that Michigan itself carried out a major long-range computing needs study, sort of modeled after [the one carried out at MIT], in which it became obvious that computer time-sharing was also the way for Michigan to go.
GALLER: Yes, there was a specific study.
AKERA: In fact, it was carried, I believe, by Donald Katz, who we mentioned yesterday in the context of the Ford Foundation Project.
GALLER: Right. That [study] was deliberately made bigger than the computing center. We wanted, and of course our friends wanted the campus to be aware and educated that this was a good way to go.
AKERA: I think it was in that context that you had independently decided to approach IBM, partly knowing that IBM had had this falling out with MIT. So there was a window of opportunity to really do unique computer time-sharing research. Of course, this [was apparently] when you were also in conversation with, and had been invited to join the MIT group, or collaborate with them.
GALLER: When we decided not to, then we said, “Okay, let’s work with IBM.”
AKERA: I don’t have definite knowledge of this, but I think that was the first contact, the letter that you and Bruce Arden sent to IBM…
GALLER: Right. But I think at that time it was when we were talking to all the other vendors and finding they didn’t have any idea.
AKERA: Yes, and please elaborate. I’m sort of just setting up the question…
GALLER: As I said, we talked to MIT, but I know we invited other people in. It must have been right about that time.
AKERA: I think that’s right. In other words, you promised to the campus community that you’d go into time-sharing research, and then you were actually beginning to do the early phases of that research. I believe it was actually funded by the General Funds of the University.
GALLER: I think so.
AKERA: As a consequence, you did some technical work, but in the process you had to approach various manufacturers to see if anybody was willing to do the hardware changes that were required. IBM was one of the obvious people to approach. I think you might have had some extra hope that that would [work with you]…
GALLER: Right, especially knowing that they had broken up with MIT. They were ripe for someone-- Of course, we were able to offer our expertise in operating systems. We’ll take advantage of whatever we can get you to do. Let’s put some of this in the hardware to make the software easier to do.
AKERA: That’s good. Now, can you tell us how that history unfolded then? You had mentioned a core group of six, and but you [were the ones that] originally approached IBM. What happened next?
GALLER: Yes, that was a little later. We talked about the inner six business first, but that came later. That was only after Michigan-- we had already ordered a machine with virtual storage capability. So the question of the development of that, we worked with Blaauw and his team to define the hardware. Meanwhile, we were writing to the software requirements to know how to take advantage of the hardware. That was useful because they had mentioned a “W” register. I remember we were able to shoot that down because it didn’t help our--
AKERA: …had negative consequences?
GALLER: Yes, negative consequences and whatever. So we did finally agree on the hardware.
AKERA: Do you remember the actual dates during which this work took place?
GALLER: I was on sabbatical in ‘65–’66. I think it was before I left. Of course, we didn’t know about the 360 until they announced it.
AKERA: They sort of pre-announced it to a certain select group of people. They didn’t let you know too much before the official announcement was made…
GALLER: Yes, but I’m not sure we were in that group. I don’t really recall exactly when.
AKERA: Actually, Michigan was among those that were told about the system 360 before its official announcement, but they couldn’t release that knowledge until fairly close to the…
AKERA: So it’s possible that the initial conversations took place a little more in the abstract as opposed to in the context of the 360 series. But eventually you knew that it would be, in fact, the 360 model, 66M.
GALLER: Yes, that’s right. We never really knew whether “M” was “Modified” or “Michigan.” [chuckles] We did work on the software at the time, and as I said, we can get a better idea of the date from the ACM Journal article. I can look that up. Then they said they would do the 67, and I we said, “Okay, and we’ll do the operating system.”
AKERA: And IBM was comfortable with that decision at that point. They felt that you had the software operating system expertise.
GALLER: That’s right. And it was a machine for Michigan, so if the software didn’t work, it was our problem. But once they began to tell people about it, there were two developments. One is a lot of universities suddenly said, “We want that.” Then some industrial firms said—GM in particular, and I, again, was telling GM what we were going to get—and they said, “We want it, except we want the operating system to do this or that.” They weren’t asking for different hardware, but they wanted the operating system. So IBM finally said, “Well, we’d better do an operating system TSS, which will have things that other people want.” GM, Lincoln Labs--
AKERA: …that was different from what Michigan was doing?
GALLER: Right. So that began to grow, and we said, “Fine, we’ll use TSS if and when it’s good. Meanwhile we’ll do MTS, because one: we think we can do it faster, and two: it’ll be more tailored to our work.”
AKERA: I imagine there were local pressures to get a time-sharing system up and running fairly quickly.
GALLER: Not that much. It was more our own interest.
AKERA: Oh okay, you just wanted to get it running quickly as part of your research.
19 This was from the Lincoln Laboratories. I believe Lincoln Laboratories was one of the sites that adopted MAD, at least for experimental purposes, and hence they remained in touch with Michigan, even after Galler and Arden chose to go their own way and worked independently of MIT’s Robert Fano, Fernando Corbato, and Project MAC.
20 In fact, IBM helped broker the arrangement with GM, giving GM a discount for Michigan’s use of the machine to develop its systems programs.
21 There were also other papers referred to in documents at the IBM Archives, made available to the interviewer courtesy of IBM.
. . .
Melinda Varian, in her outstanding memoir VM and the VM Community, tells how IBM didn't respond to the MIT Project MAC request for a next-generation timesharing machine in 1964. She tells how, too late, Gerry Blauuw of IBM made a proposal to Project MAC for a machine with some virtual memory features; and how the IBM Cambridge Scientific Center, located in Tech Square on the third floor, created the 44MPS and CP/CMS in the mid-60s.
When MIT and then Bell Labs chose GE machines for their next generation time-sharing systems, and the University of Michigan showed interest in Multics, corporate IBM woke up to the need for time-sharing and responded with the 360/67. IBM's concern over the "snowball effect" led them to announce plans to build a large-scale timesharing system, TSS/360, as described in an article by Judy O'Neill in the 1995 Annals of the History of Computing. So the 360/67 was the machine of choice for IBM's CP/CMS and TSS, as well as for the Michigan Terminal System, MTS, which was begun about the same time. The 360/67 was announced in August 1965, and 360/67 serial #2 was delivered to the University of Michigan in January 1967.
. . .
CP-67 didn't use the segmentation features of the 360/67; In fact, segmentation was not a feature of the original Blaauw proposal, but was derived from a 1966 JACM paper by Arden, Galler, O'Brien, and Westervelt of Michigan. Both TSS and MTS did use segmentation, but not as pervasively as Multics did on the GE 645. The 645's descriptors contained the access permission bits, whereas access in the System/360 was controlled by a per-page storage key. The privileged instruction SSK (Set Storage Key), not available on all models, could set the key. User jobs each had their own key and could only write pages with their own key; the 360/67 added fetch protection. This was simpler than the 645 segmentation mechanism but precluded sharing of memory between jobs.
. . .
From: Bruce Arden
Date: June 23, 2010 12:34:54 PM EDT
To: Mike Alexander
Cc: Scott Gerstenberger, Jeff Ogden
Subject: IBM Model 67 etc.
The following is a part of my memoirs regarding the Model 67. I don't remember any external Consortium but there were several universities and corporations (e.g. GM) interested in dynamic multiprogramming on a mainframe however. A high level UM committee (I don't remember the members) did authorize the exploration of possibilities.
Regarding the Blaauw Box, I don't have the details here in Maine and probably not in Ann Arbor either. Bentley may have them in Bernie's contribution to their collection. However, I think you are right, Mike. The B-Box was a scheme for the operating system to monitor the setting of base registers with programs assigned to contiguous blocks of virtual memory. This would have some similarities to VMS with the same kind of program transition overhead.
In 1964 The University of Michigan formed a widely representative ad hoc committee to propose means to satisfy the exploding demand for computational service in science and engineering. They recommended that strategies to exploit the multiprogramming use of large mainframe computers, the only way to provide high speed computing at that time, be explored as soon as possible. The introduction of phone-connected terminals as input/output devices, in conjunction with a large multiprogramming capability, would make interactive check-out, or debugging, of new programs possible. University teaching and research activities mean that a large number of new programs are always under development. The interest in facilitating interactive computing existed in many universities at that time.
Michigan had a small head start in developing the related, complex operating systems for academic use. Also in 1964, a mid-size System 360 (model 50) was acquired by the Computing Center [the S/360-50 was delivered to the University of Michigan in 1966], and, by the subsequent enhancement of a primitive operating system from Lincoln Laboratory, a limited, interactive multiprogramming capability was created. A small, talented group of programmers, led by Michael Alexander, were the architects of this system. This was the beginning of a long sequence of improvements ultimately designated UMMPS (UM MultiProgramming System). The dominant component, to manage interactive programs, developed under the title MTS (Michigan Terminal System).
About the same time a few Computing Center staff members prepared requests for proposals from three mainframe manufacturers - IBM, GE, and Burroughs. These requests, sent in December 1964, described how these companies could retrofit their machines to include another level of address indirection. GE, then responding to a similar request from MIT, was interested, but the other two were hesitant about such an undertaking. They were unconvinced about the market for such a complex augmentation. IBM’s initial disinterest was discouraging because the System 360 base registers could easily be increased from 24 bits to a full word of 32 bits, and they had experience in the implementation of indirect addressing by base registers. Increasing the address size would greatly expand the virtual address space. (232 = 4,294,967,296)
GE responded to our proposal in March 1965 with a high level description of what had been planned in their collaboration with MIT and Bell Labs. Shortly after our proposal was sent to GE, Michigan was invited to join that collaboration. Our response to the invitation was not enthusiastic. MIT and Bell Labs had written the specifications for the modifications of the GE model 635, an older design with eighteen bit absolute addresses much like the IBM 709. Michigan would be a latecomer to the collaboration without much input to the already existing specifications. Besides, we still believed that the newer IBM System 360 was more amenable to modification. Nonetheless, we were willing to consider joining the GE consortium if there were no other alternative. It was not surprising that IBM was concerned by the loss of MIT and Bell Labs as influential customers, and the prospect of also losing Michigan persuaded them to reconsider our proposal.
The three principle designers of the System 360, Amdahl, Brooks and Blaauw, initially thought that additional indirect addressing was unnecessary clutter on their relatively new design. They generated a counterproposal, nicknamed the Blaauw box, which localized the additional circuitry required but greatly restricted the desired dynamic relocation capability. This proposal was rejected and shortly thereafter IBM agreed in principle to the System 360 augmentation we had suggested. There was still a lack of corporate enthusiasm, however. Apparently IBM believed that the size of the market for such a specialized machine was about one. The augmentation of the System 360 model 65 for Michigan was to be called 65M or alternatively 66. IBM would do no system programming for this unique model, which would not be generally available on the market. But almost immediately requests for this machine began to arrive at IBM from other universities without the system programming experience of Michigan. IBM decided to support the Model 65M for a wider market and it was renamed the Model 67.
The Computing Center began immediately to adapt the prototypical multiprogramming system MTS to the forthcoming Model 67 with its large virtual memory and system-controlled address indirection. IBM simultaneously embarked on a major programming effort to produce TSS (Time Sharing System) in about a year. If this could be done Michigan need not duplicate the effort, and so we collaborated with IBM on TSS design and implementation. There followed almost two years of trips, conferences and study papers. We began to have some reservations about the possibility of completing this huge, complex software project in a timely manner. The specter of having the model 67 delivered without working system programs convinced us to continue some back-up efforts. The UMMPS implementers at Michigan continued with their efforts to incorporate the dynamic relocation capability of the forthcoming Model 67 in their multiprogramming system.
As it turned out, TSS was an enormous undertaking that was not close to completion in its scheduled time, even though IBM assigned hundreds of programmers to the task. It seems that there is an inherent sequentiality in the creation of any complex structure having many interacting parts. The old truism, “Nine pregnant women cannot produce a baby in one month.” seemed to apply.
In January 1967 a single processor Model 67 was delivered. UMMPS and the embedded MTS were rapidly adapted for this larger computer. But the difficult incorporation of the virtual memory features (dynamic address translation via indirect addressing) was implemented on a testbed basis only until November 1967, when the Model 67 and its controlling programs became fully operational. The productivity improvement was dramatic. Before the new hardware, about five interactive programs could be simultaneously executed. Afterwards fifty could be accommodated with one or more batch programs at the same time. The mix was controlled to keep the processor and the input/output channels as busy as possible. About nine months later a dual Processor Model 67 was installed, more than doubling the throughput. At that point the controlling programs managed both multiprogramming and multiprocessing, too much for one acronym. Participating in such unbridled innovation was a heady experience, though exhausting. There was still room for individual creativity, unlike building large, complex physical systems such as jet engines.
From: Mike Alexander
Date: June 22, 2010 1:31:13 AM EDT
To: Jeff Ogden, Scott Gerstenberger
Cc: Bruce Arden
Subject: Re: Blaauw Box and the 360/67
This [the description of the Blaauw Box in Wikipedia, see note #1 below] is almost completely wrong. Bruce clearly knows a lot more about this than I do, since he was a major player in it and this all happened just as I joined the Computing Center in 1965, and I've CCed him so he can correct my mistakes. However here's what I think happened.
There were several universities and research centers (UM, MIT, GM Research, NASA Lewis (?), and others?) who were interested in getting a machine for time sharing. They proposed an address translation system along the lines described in the paper "Program and Addressing Structure in a Time-Sharing Environment" by Arden, Galler, O'Brien, and Westervelt. This described a two level address translation architecture much like what is still used today. IBM didn't go for this idea and instead proposed the Blaauw Box which implemented a single level address translation. They totally missed the idea of using the two level translation to control sharing of memory among processes.
IBM went back and forth with the consortium and things were getting nowhere. On the other hand GE was happy to implement something like what the consortium wanted. Eventually MIT gave up and ordered a GE machine (which is why Multics was written for GE architecture instead of IBM). UM was very close to following their lead. At that time the university/research market was still important to IBM and they were so worried about losing it all to GE that they agreed to implement the architecture the consortium wanted. The result was the 360/66M (or maybe /65M), a special order machine for the remaining members of the consortium. After IBM discovered that there was wider demand for this machine, they renumbered it as the 360/67 and made it part of the product line.
The DAT box on the 360/67 did not implement the Blaauw box. It implemented the architecture described in the paper mentioned above.
Someone should fix the Wikipedia article, .... [I did that, -Jeff] I imagine there are documents in the Bentley that cover this period in the Computing Center history.
If you search for "Blaauw 360-67" you'll get several hits similar to the following from Wikipedia:
[Gerritt Blaauw] designed a revolutionary address translation system, the "Blaauw Box", which was removed from the original S/360 design, but was later used in IBM's proposal to Project MAC, and incorporated in the important IBM System/360-67.
From some things I'd been told by Mike Alexander and Scott Gerstenberger the very last bit above about the "Blaauw box" being incorporated in the IBM S/360-67 didn't seem quite right.