IBM CP-40

CP-40
Company type	Research system
Industry	Computer software, Operating systems
Founded	January 1967
Headquarters	Cambridge, Massachusetts, United States
Products	Virtual machine operating system

CP-40 served as a pioneering research system leading to CP-67, which became a component of IBM's groundbreaking CP[-67]/CMS—a virtual machine and virtual memory time-sharing operating system designed for the IBM System/360 Model 67 and the cornerstone of IBM's VM family. This system managed multiple client operating system instances, most notably CMS, known as the Cambridge Monitor System, developed simultaneously. Both CP-40 and the earliest CMS iteration were products of collaboration between IBM's Cambridge Scientific Center (CSC) and researchers from MIT’s Project MAC and Lincoln Laboratory. CP-40/CMS began operational use in January 1967, running on a uniquely adapted IBM System/360 Model 40.

Project goals

As a unique experimental platform, CP-40 aimed to:

Contribute research insights to the System/360 Model 67 development team in Poughkeepsie by exploring the then-novel concept of virtual memory.
Fulfill CSC’s requirements for time-sharing within Cambridge.

An informal objective was to demonstrate IBM’s support for time-sharing users such as MIT. Both CP-40 and its successor realized these aims from technical and cultural perspectives—confirming virtual machine feasibility, nurturing a time-sharing ecosystem, and initiating remote computing services. Nevertheless, the initiative became embroiled in IBM’s internal conflict between time-sharing and batch processing priorities and failed to gain broad acceptance within academia, which gravitated toward systems like Multics, UNIX, TENEX, and platforms from DEC. Despite this, CP-40’s virtualization principles had a lasting impact and continue to influence current technology.

Features

CP-40 was the inaugural operating system to deliver complete virtualization, creating a virtual machine environment that fully emulated its underlying hardware platform (a S/360-40). It enabled multiple S/360 operating systems to be installed, tested, and executed as though each were running on independent physical machines. Supporting fourteen concurrent virtual machines, CP-40 operated all in "problem state," where privileged instructions caused exceptions intercepted by the control program. Likewise, virtual memory accesses resulting in page faults were managed by the control program rather than being passed directly to guest systems. The design and user experience pioneered by CP-40 were carried forward into CP-67/CMS, which ultimately evolved into IBM’s contemporary VM product suite.

Hardware platform

Lacking access to an S/360 Model 67, CSC engineered a bespoke virtual memory unit employing associative memory—the "CAT box"—which was integrated into a specially modified System/360 Model 40. These hardware modifications and microcode enhancements enabled comprehensive virtualization of S/360 hardware and influenced the subsequent Model 67 architecture intended for time-sharing clients such as MIT’s Project MAC and Bell Laboratories, although both implementations did not achieve commercial success for IBM.

During this era, IBM developed three distinct virtual memory mechanisms:

The "Blaauw Box," incorporated in the original S/360-67 design
The "CAT Box" (Cambridge Address Translator), added to CSC’s modified S/360-40 for CP-40
The "DAT Box" (Dynamic Address Translation), introduced with the S/370 series in 1972

While differing in specifics, these systems shared foundational design concepts. The CAT box represented a significant advancement; it utilized a parallel-search register array to speed dynamic address translation. Funded by Cambridge, IBM engineers constructed a unique 64-register associative memory unit embedded within a 360/40, delivered early in 1966.

Although explicit virtualization support was present only in CSC’s customized Model 40 initially, it was not originally planned for the standard Model 67. The eventual adoption of virtualization features in the -67—and their role in enabling the success of CP-67/CMS—highlight the determination of the CSC development team.

CMS operating under CP-40

In 1964, at CSC, CMS was created as a "client" operating system running on CP-40, with John Harmon leading the effort. Although any S/360 operating system could execute within a CP-40 virtual machine, the team opted for a new, straightforward, single-user interactive OS to efficiently serve time-sharing users, thereby avoiding the complexities inherent in multi-user systems such as CTSS. Unlike IBM's OS/MVT-TSO and its successors—which operated time-sharing as a single task within a batch OS—CMS offered each user an independent virtual machine.

By September 1965, several fundamental CMS design principles were established:

Commands designed for ease of use with optional parameters to minimize job control complexity
Basic file system commands and macros; filenames composed simply of filename, filetype, and filemode (a logical disk identifier or minidisk)
Fixed-length record blocks accessible via relative record numbers
Files were created implicitly by writing data, without requiring explicit creation steps
Default filemodes allowed disks to be searched in a predetermined sequence

These features marked a significant departure from IBM’s intricate file naming conventions and job control language (JCL). Some elements paralleled objectives pursued by vendors like Control Data Corporation and DEC.

CMS utilized an intentionally simple flat directory structure. Creasy remarked: "The choice of multiple disks each having a single directory was based on simplicity and practical utility," deliberately avoiding the then-popular multi-level linked directories to keep implementation straightforward.

Applications operated within the same address space inside the CMS virtual machine and accessed system services through a clear programming interface to the CMS nucleus located in low memory. A range of system calls familiar to current CMS developers was made available. Although applications could potentially compromise their own virtual machine by misusing privileged instructions or corrupting memory, such errors could not impact other virtual machines or the underlying control program. As a result, application faults rarely caused CP to crash.

Historical context

The following points, mainly drawn from Pugh, Varian, and Creasy, provide insight into CP-40’s development environment. Direct quotations are preserved to maintain original perspectives. Additional background can be found in History of CP/CMS.

Origins of the CP-40 initiative:
- Rasmussen at CSC, doubtful about TSS/360, redirected idle CSC resources toward building a "credible time-sharing system for the S/360," which became CP-40. Robert Creasy, formerly involved with CTSS, headed this project.
- CP-40’s mission encompassed systems and software research (including associative memory) while meeting CSC’s time-sharing demands. Varian comments: "The true aim was to develop a time-sharing system," although other goals helped disguise its somewhat "counter-strategic" nature. Creasy described CP/CMS as "a second-generation time-sharing system for IBM System/360 ... supporting all activities at the Cambridge center," including operating system research and application development. External funding also supported it to assess operating system performance.
- CSC’s research held great significance for IBM because virtual memory systems were not yet well understood. Varian quotes L.W. Comeau: "[IBM's] commitment to virtual memory came without successful prior experience... nobody understood why [Ferranti] Atlas failed." Comeau later attributed Atlas’s failure to thrashing—a phenomenon also observed on IBM M44/44X and CP-40.

CP-40 architectural design:

According to Pugh and colleagues, in 1964 IBM Research recommended adopting virtual-machine concepts for time-sharing, which Cambridge embraced to build a platform for testing operating systems. Creasy and Comeau chose to base CP-40 on virtual machines (originally termed pseudo-machines), an approach developed independently but similar to IBM M44/44X. Creasy explained CP’s virtualization strategy: programs execute entirely in problem state while privileged instructions are intercepted and emulated by CP within virtual machines. This interception relied on hardware support, leaving dynamic program relocation as the main technical challenge.

Virtual machines in CP-40:
- Earlier systems like IBM M44/44X did not produce exact virtual replicas; Creasy emphasized that "close enough" was insufficient.
- CP-40 implemented complete virtualization with fourteen virtual S/360 environments, each equipped with 256K of virtual memory, disk partition mapping, and spooled device access. Comeau noted this arrangement enabled concurrent development of CP and CMS, performance evaluation of non-virtualized systems, and improved security.
- The M44/44X project demonstrated that virtual machines could achieve efficiency comparable to conventional methods—a fundamental assumption validated by CP-40’s design.
- Under terminal control, CP-40 supported up to fourteen virtual machines; its successor CP-67 doubled this capacity through enhanced address translation techniques and increased processing speed.

CMS operation within CP-40:

Creasy observed that CTSS’s tightly integrated design limited flexibility; separating resource management (CP) from user interaction services (CMS) allowed modular development. This division was crucial to CP/CMS’s success.
Early CMS offered single-user functionality free from sharing complications and protection overhead. Initial CMS versions booted under BPS, an early S/360 environment, before transitioning to booting inside virtual machines managed by CP.

Family tree