IBM System/360-67
From Wikipedia, the free encyclopedia
- See also: System/360, History of CP/CMS, and History of IBM
The IBM System/360 Model 67 (S/360-67) was an important IBM mainframe model in the late 60s. 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).[1]
Contents |
[edit] 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:[2]
- "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"
[edit] Software
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 reduced to practice 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.
[edit] 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)[3] 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.
[edit] Virtualization
- See also: virtualization and full 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.
[edit] 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. 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.
[edit] 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 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 www.princeton.edu/~melinda
Additional papers involving the S/360-67 can be found in the references to History of CP/CMS.
Citations
- ^ Pugh, op. cit., p. 364 – MTS on dual processor S/360-67 in 1968
- ^ Varian, op. cit., p. 17 (Note 54) – S/360-67 announcement
- ^ Varian, op. cit., p. 28 – S/360-67 page size of 4K
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