IBM System/360 Model 67

The IBM System/360 Model 67 (S/360-67) was an important IBM mainframe model in the late 1960s. It first shipped in July 1966. Unlike the rest of the S/360 series, it included features to facilitate time-sharing applications, notably virtual memory hardware and 32-bit addressing. The S/360-67 was otherwise compatible with the rest of the S/360 series.

The S/360-67 was intended to satisfy the needs of key time-sharing customers, notably MIT, where Project MAC had become a notorious IBM sales failure. The S/360-67 was essentially a general-purpose version of the customized system that IBM bid in its Project MAC proposal.

Multiprocessor configurations of the S/360-67 were available; for example, in 1968, the University of Michigan installed the dual-processor version of the S/360-67 for its ageless MTS system (which had been moved in 1967, from a S/360-50, to a uniprocessor S/360-67 with paging and a high-speed drum). [Pugh, "op. cit., p." 364 – MTS on dual processor S/360-67 in 1968]

Announcement

IBM announced the S/360-67 in its August 16, 1965 "blue letters" (a standard mechanism used by IBM to make product announcements). IBM stated that: [Varian, "op. cit., p." 17 (Note 54) – S/360-67 announcement]
* "Special bid restrictions have been removed from the System/360 Model 67" (i.e., it was now generally available)
* It included "multiprocessor configurations, with a high degree of system availability", with up to four processing units
* It had "its own powerful operating system... [the] Time Sharing System monitor (TSS)" offering "virtually instantaneous access to and response from the computer" to "take advantage of the unique capabilities of a multiprocessor system"
* It offered "dynamic relocation of problem programs using the dynamic address translation facilities of the 2067 Processing Unit, permitting response, within seconds, to many simultaneous users"

oftware

When the S/360-67 was announced in August 1965, IBM also announced TSS/360, an ill-fated time-sharing operating system project that was canceled in 1971 (having also being canceled in 1969, but reprieved).

Far more successful on the S/360-67 was CP/CMS. This was the first fully-virtualized virtual machine operating system, and evolved from the ground-breaking research system CP-40. CP/CMS proved quite important:
* It delivered high-performance time-sharing.
* It validated the S/360-67 architecture.
* It introduced and employed many virtual machine and virtual memory concepts, still evolving in contemporary research systems such as the IBM M44/44X, Manchester/Ferranti Atlas, and the emerging GE 645 (which was being built for the Multics project)
* It ultimately spawned both a time-sharing service industry and IBM's VM/CMS operating system.

At the time of the S/360-67, software was "bundled" into computer hardware purchases; see "IBM's unbundling of software and services". In particular, IBM operating systems were available without additional charge to IBM customers. CP/CMS was unusual in that it was delivered as unsupported Type-III software in source code form – meaning that most S/360-67 users ran an "unsupported" operating system. The need for self-support and community support helped lead to the creation of a strong S/360-67 user community, a precursor to the open source movement.

Virtual memory

The S/360-67 design included a radical new component for implementing virtual memory, referred to as the "Blaauw Box" after its designer Gerry Blaauw. This device was originally designed during the main S/360 project, but had been excluded from the S/360 design; it was revived for IBM's failed proposal to Project MAC, for a customized S/360, and finally came to fruition in the S/360-67. The "Blaauw Box" used a somewhat different approach from that implemented later in the S/370 series in the "DAT box". The S/360-67 provided a 24- or 32-bit address space – unlike the strictly 24-bit address space of other S/360 and early S/370 systems, and the 31-bit address space of S/370-XA available on later S/370s. The S/360-67 virtual address space was divided into "pages" (of 4KB) [Varian, "op. cit., p." 28 – S/360-67 page size of 4K] grouped into "segments" (of 1MB); pages were dynamically mapped onto the processor's real memory. Referencing a page that was not in memory caused a page fault, which in turn could be intercepted and processed by an operating system interrupt handler.

The S/360-67's virtual memory system was capable of meeting three distinct goals:

* Large address space. It mapped physical memory onto a larger pool of virtual memory, which could be dynamically swapped in and out of real memory as needed from random-access storage (typically: disk or drum storage).
* Isolated OS components. It made it possible to remove most of the operating system's memory footprint from the user's environment, thereby increasing the memory available for application use, and reducing the risk of applications intruding into or corrupting operating system data and programs.
* Multiple address spaces. By implementing multiple virtual address spaces, each for a different user, each user could potentially have a private virtual machine.

The first goal removed (for decades, at least) a crushing limitation of earlier machines: running out of physical storage. The second enabled substantial improvements in security and reliability. The third, in conjunction with other virtualization capabilities discussed below, enabled the implementation of true virtual machines, rather than simply sharing a single machine among many users (via the multiplexing techniques previously employed). The virtual machine capability ultimately had the broadest impact.

Virtualization

The S/360-67 included various hardware and microcode features that enabled full virtualization of the raw S/360 hardware. The full-virtualization concept was pioneered with CP-40 on custom hardware; its implementation on the S/360-67 made CP-67 possible.

Full virtualization requires that every salient feature of the hardware be reflected into one of several virtual machines – including the full instruction set, input/output operations, interrupts, memory access, and whatever other elements are used by the software that runs on the bare machine, and that is intended to run in a virtual machine. The obvious test of virtualization is whether an operating system intended for stand-alone use can successfully run inside a virtual machine.

(Note that, in CP-67, certain model-dependent and diagnostic instructions were not virtualized, notably the DIAG instruction. Ultimately, in later development at IBM and elsewhere, DIAG instructions were used to create a non-virtualized interface, to what became called a hypervisor. Client operating systems could use this mechanism to communicate directly with the control program; this offered dramatic performance improvements.)

It is important to note that full hardware virtualization was "not" an original design goal for the S/360-67 (contemporary documents and observers make this clear, despite revisionist claims to the contrary). Active input from IBM customers and IBM researchers – notably from personnel at IBM's Cambridge Scientific Center (CSC), and especially the CP-40 team – helped change project priorities. Without this "underground" effort, CP/CMS could not have been successful.

In many respects, it can be stated without hyperbole that IBM's CP-67 and CP/CMS products anticipated (and heavily influenced) contemporary virtualization software, such as VMware Workstation, Xen, and Microsoft Virtual PC.

Legacy

The S/360-67 had an important legacy. After the failure of TSS/360, IBM was pleasantly surprised by the blossoming of a CP/CMS time-sharing community on the S/360-67 platform. A large number of commercial, academic, and service bureau sites installed the system. By taking advantage of IBM's lukewarm support for time-sharing, and by sharing information and resources (including source code modifications), they built and supported a generation of time-sharing centers.

The unique features of the S/360-67 were initially "not" carried into IBM's next product series, the System/370, although at least one model, the 370/145, had the Refer and Change storage bits implemented from the start. This was largely fallout from a bitter and highly-visible political battle over the merits of time-sharing versus batch processing. Time-sharing lost.

However, IBM faced increasing customer demand for time-sharing and virtual memory capabilities. IBM also could not ignore the large number of S/360-67 time-sharing installations – including the new industry of time-sharing vendors, such as National CSS and IDC, that were quickly achieving commercial success.

Eventually, in 1972, IBM added virtual memory options to the S/370 series, a move seen by many as a vindication of work done on the S/360-67 project. The survival and success of IBM's VM family, and of virtualization technology in general, also owe much to the S/360-67.

References

* A. Padegs, "System/360 and Beyond", "IBM Journal of Research & Development, vol. 25 no. 5, pp." 377-390, September 1981 [available on-line at [http://www.research.ibm.com/journal/rd/255/ibmrd2505D.pdf www.research.ibm.com]

* E.W. Pugh, L.R. Johnson, and John H. Palmer, "IBM's 360 and early 370 systems," MIT Press, Cambridge MA and London, ISBN 0-262-16123-0 [Extensive (819 "pp.") treatment of IBM's offerings during this period.]

* Melinda Varian, "VM and the VM community, past present, and future," SHARE 89 Sessions 9059-9061, 1977; available online at [http://www.princeton.edu/~melinda/25paper.pdf www.princeton.edu/~melinda]

Additional papers involving the S/360-67 can be found in the references to History of CP/CMS.

Citations

External Links
* http://www.cs.newcastle.ac.uk/events/anniversaries/40th/images/ibm360_672/index.html – Pictures of an IBM S/360-67 at Newcastle (UK) University
* http://www.multicians.org/thvv/360-67.html – Tom Van Vleck's notes about the S/360-67
* http://cap-lore.com/Software/CP.html – Norm Hardy's notes about virtual machines and the S/360-67