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.

Bruce

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.