IBM VM/370: Turning One Mainframe into Many Virtual Machines

IBM’s VM/370 made a mainframe behave as if each user had a separate computer. Its Control Program (CP) provided virtual machines, while the Conversational Monitor System (CMS) gave an interactive environment for editing, compiling, and running programs. The product grew out of CP/CMS research in the 1960s and was officially announced as VM/370 in August 1972. The architecture is a landmark in virtualization, but its history is more nuanced than “IBM invented the virtual machine”: earlier experimental systems explored related ideas, and the CP/CMS project was a practical response to sharing an expensive computer while supporting different workloads.

The distinction between virtual memory and virtual machines is essential. Virtual memory lets an operating system present each process with an address space that is mapped onto physical memory. A virtual machine presents software with an abstracted computer, including processor behavior and devices, so a guest operating system can run as though it owned a machine. A system can provide one without the other; VM/370 coordinated both in a mainframe environment.

Cambridge Scientific Center and CP/CMS

The lineage began at IBM’s Cambridge Scientific Center, where researchers developed CP/CMS as a time-sharing research project for System/360. IBM’s retrospective timeline dates the experimental CP-40 work to 1964. CP-67 later supported customers using the System/360 Model 67, whose hardware provided facilities needed for virtual memory. The project had research aims as well as practical pressure: users wanted interactive access, while IBM’s large computers were costly resources that could not be dedicated to every user.

“Control Program” described CP’s role. It managed the actual processor and resources, then presented each guest with a virtual view. “CMS” supplied a conversational environment inside a virtual machine. A user could log in, edit source, compile, run, and store files without commandeering a separate physical mainframe. Several operating-system environments could be active at once, subject to the available resources and the control program’s scheduling.

The system did not create infinite capacity. Every guest shared finite memory, processor time, I/O channels, and storage. A workload that consumed too much CPU could affect response time for other users. Virtualization made resource sharing and isolation more flexible; it did not erase contention or maintenance needs.

What a virtual machine meant in the 1960s

The virtual-machine abstraction attempted to reproduce the important behavior of the underlying hardware for each guest. The guest operating system could believe it controlled a computer, while CP mediated privileged operations and multiplexed the physical processor. When the guest attempted an operation that could not safely execute directly, control returned to CP, which simulated or managed the effect.

This is not the same as running an application inside a modern process container. A guest operating system can manage its own processes and files, and different guests can run different systems. That independence was valuable for software development, experimentation, and compatibility. A programmer could test an operating-system change in a virtual machine rather than reserve a dedicated physical System/360 installation.

The abstraction had limits. Not every device behaved as a simple virtual copy, and I/O pathways required careful mediation. Performance depended on how often a guest operation trapped to CP and how much emulation was necessary. Hardware changes could make virtualization more efficient, but the software model still had to account for privileged instructions and resource sharing.

CP-67 and CMS: a practical interactive environment

CP-67/CMS combined multi-access time-sharing with the idea of a dedicated virtual computer. IBM’s 1972 VM/370 program announcement described concurrent virtual machines and the ability to run different operating systems at once. That expressed the product’s key promise: users could have interactive control without the organization buying one physical mainframe per person.

CMS was important because a virtual machine alone was not an end-user environment. A guest needed utilities and a working software environment. CMS provided a conversational monitor, files, editors, and language tools. Users developed programs in CMS and could run them in the virtual machine’s processor context. This helped create a community of mainframe developers working interactively rather than submitting every task as a batch job.

The separation of CP and CMS also made the system extensible. CP could manage machine resources while a guest OS supplied services to one user’s session. Users could experiment with their virtual system with less risk to other sessions than if all users shared one global operating system. Isolation was relative, not absolute security: researchers continued to analyze the integrity of the system and its privileged interfaces.

VM/370 becomes an official product

IBM announced VM/370 on August 2, 1972, in conjunction with System/370 virtual-storage systems. IBM’s own history explicitly treats VM/370 as the official product release and traces its components to CP-40 and CP-67. That productization connected a research lineage to IBM’s commercial mainframe strategy.

The product included source code for customers, who could adapt it to local needs and share changes with other VM users. This helped create a collaborative technical culture around the system. It should not be retroactively equated with today’s open-source licensing model: code availability, redistribution terms, governance, and community ownership were different. The practice did, however, give customers unusual visibility into a core operating environment and support peer exchange.

VM/370 became one option among several System/370 environments. IBM also offered operating systems that used virtual storage directly rather than virtualizing multiple complete machines. Those approaches addressed different goals. A production transaction system might prefer a direct operating-system model; a software lab or time-sharing environment might value multiple independent guests. VM did not replace every IBM OS, and its users often relied on it precisely because they needed to run other systems within it.

Why virtualization mattered to developers and operators

The virtual machine changed how mainframe resources could be allocated. Users could have private system state and test code without requiring a dedicated physical configuration. Operators could consolidate workloads, and researchers could explore system behavior. A machine could support heterogeneous environments as long as its virtual interface and resource limits met their needs.

For software developers, the advantage was repeatability and control. A test guest could be rebooted or reset without taking down the host control program. A programmer could run an operating system that differed from the one managing the physical installation. This reduced the organizational friction of experimentation, though administrators still needed policies for storage, performance, and system integrity.

The design also surfaces a central tradeoff in virtualization: abstraction costs something. A virtual device or privileged operation may require extra translation. The closer the guest-visible machine matches hardware behavior, the more compatibility it offers; the more it is optimized for a particular workload, the more assumptions it may expose. VM/370 made this tradeoff explicit decades before commodity x86 hypervisors and cloud virtual machines made it familiar to a wider audience.

What VM/370 did not do

VM/370 was not a modern cloud platform. It did not automatically provision elastic servers across global regions, offer pay-per-use billing, or manage container images. It was a mainframe time-sharing and virtualization system operating within a particular IBM hardware family. Comparisons with cloud infrastructure are useful when they identify the shared abstraction, but misleading when they imply the same control plane, economics, or operational model.

Nor was VM’s lineage a single invention by one person or team. The IBM record describes multiple stages and contributors, from experimental CP-40 through customer-facing CP-67 to VM/370. Earlier time-sharing and experimental systems influenced the environment in which the project developed. The historically defensible claim is that CP/CMS and VM/370 became influential, commercially important examples of virtual machines on IBM mainframes.

A durable systems idea

VM/370 showed that a large computer could be partitioned into independently useful software-defined machines. Its significance came from combining processor mediation, resource scheduling, guest operating systems, interactive tools, and customer practice. Virtualization was not only a hardware trick; it was a system contract and an operational model.

The path from Cambridge experiments to VM/370 also illustrates how research systems can become products without losing all of their experimental character. Customers adapted the source, users exchanged modifications, and the product continued through later IBM VM generations. Modern virtualization uses different hardware and management layers, but the old question remains: what machine does the guest believe it has, who controls the real resources, and what happens when the abstraction is imperfect?

Related:

Sources: