VM (operating system)
| Company type | Operating system |
|---|---|
| Industry | Computer software |
| Predecessor | CP/CMS |
| Founded | 1972 |
| Products | VM/CMS, VM/370, VM/SP, VM/XA, VM/ESA, z/VM |
| Parent | IBM |
VM (commonly known as VM/CMS) represents a series of IBM virtual machine operating systems designed for IBM mainframe platforms such as System/370, System/390, zSeries, and System z. It also supports compatible environments like the Hercules emulator on personal computers.
Design
At the heart of VM lies the Control Program or hypervisor (CP, VM-CP), which operates directly on physical hardware to establish the virtual machine environment. This hypervisor delivers comprehensive virtualization by administering system resources including device management, task scheduling, and virtual memory. Each user is allocated an independent virtual machine with its own isolated address space and emulated devices, capable of running any software intended for dedicated hardware. Mainframes running VM typically host hundreds to thousands of such virtual machines. The VM-CP originated from CP-370, which itself evolved from earlier IBM virtualization technologies.
Inside each virtual machine, a guest operating system executes, which can be:
- CMS (Conversational Monitor System), a streamlined single-user OS that provides interactive file management, programming tools, and device access—commonly employed within VM systems.
- GCS (Group Control System), which simulates a limited subset of MVS APIs to support VTAM and RSCS V2 without needing separate service OS instances.
- IBM’s primary operating systems like MVS, DOS/VSE, OS/VS1, TSS/370, or even another nested VM instance. The hypervisor treats these guests as privileged applications by emulating privileged instructions and restricting direct hardware manipulation. It also supports various console terminal emulations such as IBM 3270 devices.
- Nested VM instances enable multiple layers of virtualization, facilitating development and testing of new hardware and software; practical deployments have demonstrated up to five levels of virtualization.
- Mainframe editions of AIX or Linux can run either as guest OSes under VM or directly on the hardware.
- Specialized VM subsystems operate within separate virtual machines to deliver services to CMS users without enlarging the core hypervisor. Examples include:
- RSCS (Remote Spooling and Communications Subsystem) for inter-system communication
- RACF (Resource Access Control Facility) security framework
- Shared File System (SFS) enabling file sharing
- VTAM (Virtual Telecommunications Access Method) supporting Systems Network Architecture networks
- PVM (VM/Pass-Through Facility) for remote VM access
- TCP/IP-related utilities such as SMTP, FTPSERVE, PORTMAP, and VMNFS providing networking capabilities
- Db2 Server for VM offering SQL database services
- DIRMAINT handling user directory administration
- MUMPS/VM implementing the MUMPS database language (introduced in 1987 and discontinued in 1991)
- Custom or user-developed operating systems including National CSS's CSS or Boston University's VPS/VM.
This modular architecture promotes efficient resource allocation, enhanced security, and adaptability essential for IBM mainframe business computing environments.
Versions
The notable releases include:
- Virtual Machine Facility/370 (VM/370, 1972)
- A reimplementation of the earlier CP/CMS system tailored for the System/370 architecture.
- VM/370 Basic System Extensions Program Product (VM/BSE)
- Extends VM/370 with support for additional hardware such as 3370-type DASD drives, improvements to the CMS environment, and enhancements to CP stability.
- VM/370 System Extensions Program Product (VM/SE)
- Builds upon VM/BSE by incorporating further fixes and additional features.
- Virtual Machine/System Product (VM/SP)
- A significant upgrade superseding VM/370, VM/BSE, and VM/SE. Release 1 introduced editors like EXEC2 and XEDIT; Release 3 added scripting with REXX; Release 6 incorporated a shared filesystem.
- Virtual Machine/System Product High Performance Option (VM/SP HPO)
- Enhances VM/SP by adding device support and functionalities allowing certain S/370 machines to utilize up to 64 MB of real memory. Designed specifically for users running multiple S/370 guests simultaneously.
- Virtual Machine/Extended Architecture Migration Aid (VM/XA MA)
- Supports migration from MVS/370 to MVS/XA by enabling concurrent operation on the same processor complex.
- Virtual Machine/Extended Architecture System Facility (VM/XA SF)
- An improved iteration of VM/XA MA offering better performance and expanded features.
- Virtual Machine/Extended Architecture System Product (VM/XA SP)
- Successor to VM/XA SF replacing VM/SP HPO on S/370-XA hardware, featuring a CMS version capable of operating in either S/370 or S/370-XA modes.
- Virtual Machine/Enterprise Systems Architecture (VM/ESA)
- Integrates functionalities from VM/SP, VM/SP HPO, and VM/XA SP. Version 1 supports S/370, ESA/370, or ESA/390 modes but excludes S/370 XA; Version 2 operates solely in ESA/390 mode. The S/370 variants are based on the VM/SP HPO codebase while ESA/390 versions derive from VM/XA.
- z/VM
- The current mainstream full virtualization solution for mainframes. z/VM 4.4 was the final release supporting ESA/390 mode; subsequent versions run exclusively on z/Architecture.
CMS denotes the Conversational Monitor System—a single-user component providing interactive time-sharing within a virtual machine under the VM environment.
Hypervisor Interface
The term hypervisor was originally introduced by IBM in connection with the 360/65 system and was later applied to the DIAG handler within CP-67.
IBM designed the Diagnose instruction ('83'x—without a mnemonic) as a privileged instruction intended for executing built-in diagnostic tasks or other model-specific operations. IBM adapted this DIAG instruction to facilitate communication between a virtual machine and the Control Program (CP). The instruction format includes two four-bit register identifiers (Rx and Ry) used for operand addresses or return codes, alongside a two-byte code that CP interprets to identify the requested DIAG operation.
Notable DIAG functions consist of:
| Hexadecimal Code | Purpose |
|---|---|
| 0000 | Store Extended-Identification Code |
| 0004 | Inspect Real Storage |
| 0008 | Virtual Console Function—Execute a command within CP |
| 0018 | Standard DASD Input/Output |
| 0020 | General I/O—Run any valid CCW sequence on tape or disk devices |
| 003C | Update VM/370 Directory Entries |
| 0058 | 3270 Virtual Console Interface—Perform full-screen input/output on an IBM 3270 terminal |
| 0060 | Query Virtual Machine Storage Capacity |
| 0068 | Virtual Machine Communication Facility (VMCF) |
Originally, CMS operated as a standalone operating system on physical hardware but now functions solely as a guest OS under VM. This transition is because CMS depends on a hypervisor interface provided by VM-CP for file system management and other essential services. This paravirtualization interface:
- Offers a streamlined communication path to VM-CP, significantly lowering overhead compared to complete hardware simulation.
- Was introduced as a performance optimization in CP/CMS version 2.1, representing an important advancement in efficiency.
- Utilizes the non-virtualized, model-specific DIAG instruction as a signaling mechanism between CMS and CP.
Minidisks
CP supports the creation of virtual disk partitions known as minidisks, which can be sized up to the capacity of the physical device to accommodate smaller DASD requirements typical for CMS and other operating systems. For CKD formatted volumes, minidisks must be allocated in whole-cylinder increments. A minidisk inherits characteristics from its underlying disk but is generally smaller, with its starting point mapped to cylinder or block zero. Access to minidisks employs the same channel programs used for physical disks.
When formatted with a CMS file system, these partitions are referred to as CMS minidisks, although they can also be utilized by other operating systems.
Minidisks encompassing entire volumes are often assigned to guest operating systems such as z/OS, rather than dedicating complete volumes via DEDICATE commands. Moreover, "full-pack links" owned by the MAINT user ID are established for each DASD volume to support system backup operations using the DASD Dump/Restore utility, which copies entire DASD contents onto tape or another DASD device.
The Shared File System (SFS) was introduced with VM/SP Release 6 to substantially improve CMS file storage capabilities. Unlike CMS minidisks, which do not support directory structures, SFS provides hierarchical directories along with more granular security controls. While CMS minidisks only permit read-only or read-write access at the disk level, SFS enables permissions at the individual file level and enhances overall performance.
SFS functions through dedicated service virtual machines—typically three on contemporary VM installations: VMSERVR (the recovery server), VMSERVS (serving the VMSYS filepool), and VMSERVU (handling the VMSYSU user filepool). These servers administer multiple minidisks including configuration (A-disk), control, log, and data disks where user files reside.
Users configured solely for SFS have their A-disk named FILEPOOL:USERID, with directory paths structured as FILEPOOL:USERID.DIR1.DIR2, resembling UNIX directory conventions. SFS directories offer advanced access control mechanisms and prevent disk corruption issues caused by simultaneous writes that commonly affect CMS minidisks.
Additionally, these file pool servers manage the Byte File System (BFS), a UNIX-style filesystem primarily used by the VM OpenExtensions POSIX environment within CMS. Communication between CMS user virtual machines and SFS servers is facilitated through the IUCV protocol.
History
VM/370, developed as a successor to CP/CMS, debuted in 1972 alongside the announcement of IBM's System/370 Advanced Function, which introduced virtual memory hardware and operating system capabilities to the System/370 line. Initially, early VM versions were distributed as open source until 1981, after which they shifted to a licensed upgrade model with releases such as VM/SE, VM/BSE, and VM/System Product (VM/SP). IBM maintained source code updates for existing versions over several years, although most enhancements required purchasing licenses. VM achieved virtualization by intercepting privileged instructions through program interrupts within virtual machines.
Within IBM, VM played a crucial role in operating system development and time-sharing environments but was regarded internally as an "alternative operating system" for customers, who were typically encouraged to adopt the OS and DOS product families. Despite internal resource allocation challenges—partly due to VM/CMS reducing hardware demand conflicting with IBM’s hardware sales objectives—VM experienced unexpected growth. Melinda Varian observed that initial projections underestimated its adoption; yet within ten years, approximately 10% of large-scale processors operated VM, eventually exceeding MVS license counts.
IBM introduced VM/PC, enabling CMS to run on XT/370 and AT/370 personal computers, based on the VM/SP release 3 foundation. Processor expansion cards such as P/370 and P/390 allowed PCs to host full VM environments compatible with S/370 and S/390 mainframes, supporting various operating systems from the 31-bit era.
To enhance system performance, IBM launched the VM/SP High Performance Option (HPO), an add-on designed to expand capabilities such as increasing accessible memory from 16 MB up to 64 MB on models like the IBM 4381. This upgrade improved spool filesystem design by permitting more spool files per user with unique identifiers and introduced virtual storage control blocks. Additionally, user permissions for vector processing facilities were implemented.
Multiprocessing support was incorporated starting with VM/SP Release 1. System/370 versions accommodated up to two processors operating in uniprocessor (UP), multiprocessor (MP), or attached processor (AP) modes—the latter lacking I/O functionality on the secondary processor. Subsequent System/370-XA and System/390 iterations extended processor support substantially. Contemporary z/VM systems can manage up to 80 processors overall, with a maximum of 64 processors assignable per virtual machine.
The arrival of System/370 Extended Architecture on the IBM 3081 led to the creation of the VM/XA Migration Aid, which utilized the Start Interpretive Execution (SIE) instruction to efficiently execute virtual machines. This product line later evolved into VM/ESA and ultimately z/VM.
Networking capabilities for VM included RSCS and VTAM protocols, with ACF/VTAM for VM fully interoperable across MVS and VSE platforms. VTAM ran under the specialized GCS operating system; meanwhile, TCP/IP stacks were developed during the late 1980s for both VM/SP and VM/XA. These stacks supported IPv4 networking, multiple interfaces such as channel-to-channel links and IBM RT PC relays, Telnet sessions including IBM 3270 terminal emulation, FTP servers, and optional NFS server functionality—modern implementations being highly advanced.
VM also incorporated the Pass-Through Facility (PVM), allowing remote connections between VM/CMS nodes or other IBM systems through channel-to-channel or bisynchronous links. Users could establish remote sessions via login commands or CMS programs like PASSTHRU without needing to log out first. Later versions of PVM extended support for connections originating from SNA networks.
Serving as the foundation of BITNET, VM’s RSCS protocol provided a straightforward and dependable network for messaging, file transfers, and batch job submissions among interconnected nodes. When TCP/IP was integrated, RSCS worked alongside SMTP services to route email internally or across the Internet.
Over time, advances in hardware strengthened VM’s position within IBM’s ecosystem. Maintaining backward compatibility with System/360 instruction sets remained essential for IBM mainframes; however, the emergence of 64-bit zSeries architectures increased the appeal of the VM approach. VM facilitated data center migrations from DOS/VSE to MVS environments and supported running mainframe AIX and Linux platforms—areas that have grown in significance. The current z/VM platform is recognized within IBM as a leading virtualization technology; some installations operate thousands of concurrent virtual machines on a single host system. Since its release in October 2000, z/VM continues active development and widespread deployment.
Both IBM and third-party vendors have offered numerous applications compatible with VM including RAMIS, FOCUS, SPSS, NOMAD, DB2, REXX scripting language, RACF security software, and OfficeVision suite. Today’s VM environment supports a diverse array of mainframe applications such as HTTP servers, database management systems, analytics solutions, engineering software packages, and financial applications.
CP commands
Starting with release 6, the VM/370 Control Program offers a set of commands for General Users to define and manage their virtual machines. Portions of commands shown in lower case are optional.
| Command | Description |
|---|---|
| #CP | Enter a CP command from a command environment or another virtual machine after pressing the break key (default PA1) |
| ADSTOP | Establish an address stop to pause the virtual machine at a designated instruction |
| ATTN | Initiate an attention interruption to enable CP control within a command environment |
| Begin | Resume or continue virtual machine execution, optionally starting at a specified address |
| CHange | Adjust spool file properties such as output class or printer-specific parameters |
| Close | Close an active printer, punch, reader, or console file and release it back to spooling |
| COUPLE | Link virtual channel-to-channel adapters (CTCA) or simulated QDIO Ethernet adapters to a virtual switch |
| CP | Run a CP command within a CMS environment |
| DEFine | Modify the virtual machine setup by adding devices or altering storage capacity |
| DETach | Disconnect a virtual device or channel from the machine configuration |
| DIAL | Connect your terminal to simulated terminals of a logged-on multi-access virtual machine during logon |
| DISConn | Disconnect your terminal while allowing the virtual machine to keep running |
| Display | Present virtual machine storage or hardware register information |
| DUMP | Produce a snapshot dump of the current virtual machine on the spooled printer |
| ECHO | Activate echoing of typed input lines within the virtual machine |
| EXTernal | Generate an external interrupt directed at the virtual machine |
| INDicate | Show current system load and resource utilization details |
| Ipl | IPL (boot) an operating system on your designated virtual machine |
| LINK | Connect a device from another virtual machine if sharing permissions exist |
| LOADVFCB | Specify a forms control buffer (FCB) for use with a virtual printer |
| LOGoff LOGout |
End and disconnect from the active virtual machine session |
| Logon Login |
Authenticate and access the system |
| Message MSG |
Transmit a single-line message to either the system operator or another user |
| NOTReady | Make a virtual device appear as not ready for use |
| ORDer | Reorganize closed spool files by their ID or class designation |
| PURge | Remove closed spool files based on class, ID, or all devices collectively |
| Query | Display status information about your virtual machine, including message of the day and logged-in users |
| READY | Trigger a device end interruption for a specified device |
| REQuest | Create an interrupt on your virtual console interface |
| RESET | Clear all outstanding device interrupts currently pending |
| REWind | Rewind an actual (non-virtual) magnetic tape device unit |
| SET | Configure various settings such as messaging options and terminal function keys |
| SLeep | Place your virtual machine into an indefinite or timed dormant state |
| SMsg | Send specialized single-line messages to other virtual machines, commonly utilized with RSCS controls |
| SPool | Adjust settings for spooled devices including printers, readers, or punches |
| STore | Change contents within registers or storage areas of your virtual machine |
| SYStem | Reset, restart, or clear storage in your current virtual machine instance |
| TAg | Assign tags to spooled files or devices for use by VM's Remote Spooling Communications Subsystem (RSCS) |
| TERMinal | Set terminal characteristics and configurations |
| TRace | Begin or halt tracing of selected activities within the virtual machine environment |
| TRANsfer | Move spool files between different users |
| VMDUMP | Generate a dump of your virtual machine in IPCS-readable format for troubleshooting purposes |
OpenEdition extensions
IBM introduced the optional, fee-based feature OpenEdition for VM/ESA Shell and Utilities Feature starting with VM/ESA Version 2, enabling POSIX compatibility within CMS. Its primary component was a UNIX shell tailored for CMS, while the C compiler was provided by C/370 or C for VM/ESA. As neither the CMS filesystem nor the conventional VM Shared File System support UNIX-style file structures and paths, the Byte File System (BFS) was implemented instead. BFS extents reside within an SFS file pool and are mounted using commands such as OPENVM MOUNT /../VMBFS:fileservername:filepoolname /path/to/mount/point. The root filesystem is mounted through OPENVM MOUNT /../VMBFS:VMSYS:ROOT/ /, which allows launching the shell via OPENVM SHELL. Access rights to BFS filesystems are managed through POSIX permissions, utilizing commands like chmod and chown.
With the release of z/VM Version 3, IBM incorporated OpenEdition directly into z/VM and rebranded it as OpenExtensions. Both solutions deliver POSIX.2 compliance for CMS environments. Executables compiled under OpenExtensions maintain the same format as standard CMS programs. Due to constraints imposed by 3270 terminals, graphical editors such as vi are not available; instead, users depend on text editors like ed or XEDIT.
Marketing
During the early 1980s, the VM user group within SHARE sought a unifying mascot in response to IBM’s MVS users adopting a turkey symbol linked to MVS performance concerns. At SHARE 60 in 1983, the teddy bear became the unofficial mascot for VM after stickers featuring it were placed on veteran members' badges to indicate their openness to interaction. This symbol rapidly gained traction and widespread recognition within the community. Additionally, teddy bears were awarded to new members inducted into the "Order of the Knights of VM," an honor bestowed upon those who made notable contributions to the VM community.
See also
Further reading
- Primary CP/CMS sources
- R. J. Creasy, "The origin of the VM/370 time-sharing system", IBM Journal of Research & Development, Vol. 25, No. 5 (September 1981), pp. 483–90 ― insights on CP/CMS and VM history from the lead of the CP-40 project and a CTSS contributor
- E.W. Pugh, L.R. Johnson, and John H. Palmer, IBM's 360 and early 370 systems, MIT Press, Cambridge MA and London ― comprehensive (819 pages) coverage of IBM systems during this era; limited focus on CP/CMS emphasizing its specialized role
- Melinda Varian, VM and the VM community, past present, and future, SHARE 89 Sessions 9059–61, 1997 ― essential reference for CP/CMS and VM historical context
- Bitsavers, Index of /pdf/ibm/360/cp67
- Additional CP/CMS sources
- R. J. Adair et al., A Virtual Machine System for the 360/40, IBM Cambridge Scientific Center Report No. 320‐2007 (May 1966) ― foundational document describing virtual machine implementation on CSC S/360-40 and CP-40
- International Business Machines Corporation, CP-67/CMS, Program 360D-05.2.005 (June 1969) ― official IBM reference manual
- R. A. Meyer and L. H. Seawright, "A virtual machine time-sharing system," IBM Systems Journal, Vol. 9, No. 3 (September 1970) ― detailed overview of CP-67/CMS capabilities and use cases
- R. P. Parmelee et al., "Virtual storage and virtual machine concepts," IBM Systems Journal, Vol. 11, No. 2 (June 1972)
- Background CP/CMS sources
- F. J. Corbató et al., The Compatible Time-Sharing System, A Programmer’s Guide, M.I.T. Press, 1963
- F. J. Corbató et al., "An Experimental Time-sharing System," Proc. Spring Joint Computer Conference (AFIPS) 21 (1962) — description of CTSS
- F. J. Corbató and V. A. Vyssotsky, "Introduction and Overview of the MULTICS System", Proc. Fall Joint Computer Conference (AFIPS) 27 (1965)
- P. J. Denning, "Virtual Memory", Computing Surveys Vol. 2 (1970)
- J. B. Dennis, "Segmentation and the Design of Multi-Programmed Computer Systems," JACM Vol. 12 (1965) ― virtual memory requirements for Project MAC
- C. A. R. Hoare and R. H. Perrott, Eds., Operating Systems Techniques, Academic Press (1972)
- T. Kilburn et al., "One-Level Storage System", IRE Trans. Electron. Computers EC-11 (1962) ― Manchester/Ferranti Atlas
- R.A Nelson, "Mapping Devices and the M44 Data Processing System," IBM Research Report RC 1303 (1964) ― about the IBM M44/44X
- R.P Parmelee et al., "Virtual Storage and Virtual Machine Concepts", IBM Systems Journal, Vol. 11 (1972)
- Additional on-line CP/CMS resources
- febcm.club.fr — Information Technology Timeline Archived October 7, 2006, at the Wayback Machine, covering years 1964–74
- www.multicians.org — Tom Van Vleck's essay The IBM 360/67 and CP/CMS
- www.cap-lore.com — Norman Hardy's Short history of IBM's virtual machines
- www.cap-lore.com — Norman Hardy's brief overview of the "Blaauw Box"
External links
- Bob DuCharme, Operating Systems Handbook, Part 5: VM/CMS: comprehensive user manual for VM/CMS
- E. C. Hendricks and T. C. Hartmann, "Development of a Virtual Machine Subsystem", IBM Systems Journal Vol. 18, pp. 111–142 (1979): design and creation of RSCS
- IBM Corporation, IBM Virtual Machine Facility/370 Introduction, GC20-1800 (1972): original documentation
- IBM Redbooks Publication – z/VM guide
- IBM: z/VM official portal
- IBM: z/VM documentation
- VM/PC manuals available on bitsavers