CP/CMS was distributed in
source code form, and many CP/CMS users were actively involved in studying and modifying that source code. Such direct user involvement with a vendor-supplied operating system was unusual. In the CP/CMS era, many vendors distributed operating systems in machine-readable source code. IBM provided optional source code for, e.g.,
OS/360,
DOS/360, and several later mainstream IBM operating systems. With all these systems, some awareness of system source code was also involved in the
SYSGEN process, comparable to a
kernel build in modern systems also in installing a
Starter Set. (Forty years later, the
Hercules emulator can be used to run fossilized versions of these systems, based on source code that is now treated as part of the
public domain.) The importance of operating system source code has changed over time. Before
IBM unbundled software from hardware in 1969, the OS (and most other software) was included in the cost of the hardware. Each vendor had complete responsibility for the entire system, hardware and software. This made the distribution medium relatively unimportant. After IBM's unbundling, OS software was delivered as
IBM System Control Program software IBM System Control Program (SCP) software, eventually in object code only (OCO) form. For complicated reasons, CP/CMS was not released in the normal way. It was not supported by IBM, but was made part of the unsupported
IBM Type-III Library, a collection of software contributions from IBM staff members (similarly software contributed by customers formed the Type-IV Library). IBM distributed this library to its customers for use 'as is'. The lack of direct IBM support for such products forced active users to support themselves and encouraged modifications and mutual support. CP/CMS and other Type-III products were early forms of
free software. Source code distribution of other IBM operating systems may have continued for some time (e.g.
OS/360,
DOS/360,
DOS/VSE,
MVS, and even
TSS/370, which all today are generally considered to be in the
public domain) since they were arguably published without a copyright notice before 1978. However, the unsupported status of CP/CMS placed different pressures on its user community and created the need for source code distribution. CP/CMS was contributed to the Type-III Library by MIT's
Lincoln Laboratory and
not by IBM, despite the fact that the system was built by IBM's
Cambridge Scientific Center. This decision has been described as a form of collusion to outmaneuver the IBM political forces opposed to time-sharing. It is thought that it may also reflect the amount of formal and informal input from MIT and
Union Carbide that contributed to the design and implementation of CP-40, the S/360-67, CP-67, and CMS. See
History of CP/CMS (historical notes) for further insights and references on this topic. Many CP/CMS users made extensive modifications to their own copies of the source code. Much of this work was shared among sites, and important changes found their way back into the core system. Other users, such as
National CSS and some academic sites, continued independent development of CP/CMS, rather than switching to VM/370 when it became available. These efforts diverged from the community, in what today would be termed a
software fork. After IBM released VM/370, source code distribution of VM continued for several releases. (The VM project did not adopt the use of
PL/S, an internal systems programming language mandated for use within IBM on many comparable projects. The use of PL/S would have made source code distribution impossible. IBM attempted to turn away from assembly language to higher level languages as early as 1965, and was making substantial use of
PL/S by 1969, e.g. in MVS. PL/S was considered a trade secret at the time and was not available to customers. IBM apparently made exceptions to this policy much later.) The VM user community continued to make important contributions to the software, as it had during the CP/CMS Type-III period. Few OS or DOS sites exhibited active user involvement in deep operating system internals, but this was found at many VM sites. This reverse support helped CP/CMS concepts survive and evolve, despite VM's second class citizen status at IBM. ==Architecture== The CP/CMS architecture was revolutionary for its time. The system consisted of a
virtualizing control program (CP) which created multiple independent
virtual machines (VMs).
Platform virtualization was possible because of two elements of the IBM System/360-67: • Segregation of privileged "supervisor state" instructions from normal "problem state" instructions • Address translation hardware When a program was running in "problem state," using a privileged instruction or an invalid memory address would cause the hardware to raise an exception condition. By trapping these conditions, CP could simulate the appropriate behavior, e.g. performing I/O or paging operations. A guest operating system, which would run in "supervisor state" on a bare machine, was run in "problem state" under CP. The result was a fully virtualized environment. Each virtual machine had its own set of virtual devices, mapped from the system's real hardware environment. Thus a given dial-up teletype was presented to its VM instance as its
virtual console. 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. Any S/360 operating system could in fact be run under CP, but normal users ran Cambridge Monitor System (CMS), a simple, single-user operating system. CMS allowed users to run programs and manage their virtual devices. CP-67 versions 1 and 2 did not support virtual memory inside a virtual machine. This was added in version 3. At that point, testing and development of CP itself could be done by running a full copy of CP/CMS inside a single virtual machine. Some CP/CMS operating system work, such as CP-370 development and MVS testing, ran four- or five-level deep stacks of hardware and OS simulations. The CP/CMS design is different from IBM's previous
monolithic operating systems, it separates complex "big system" (dispatching, hardware management, mass storage) from "little system" (application program execution, file I/O, console input/output). The re-categorization of both systems into their own entities prevents a bug in one users' system from affecting both. This is a model feature in
microkernel operating systems. IBM's decision to implement
virtualization and
virtual memory features in the subsequent S/370 design (although missing from the initial S/370 series) reflects, at least in part, the success of the CP/CMS approach. In turn the survival and success of IBM's VM operating system family, and of virtualization technology in general, owe much to the S/360-67. In many respects, IBM's CP-67 and CP/CMS products anticipated (and heavily influenced) contemporary
virtualization software, such as
VMware Workstation,
Xen, and
Microsoft Virtual PC. ==Related terminology==