This article has an unclear citation style.(May 2012)
|OS family||VM family|
|Source model||1972-1986 Open source, 1977-present Closed source|
|Latest release||IBM z/VM V7.2 / September 16, 2020|
|Marketing target||IBM mainframe computers|
|Platforms||System/370, System/390, zSeries, IBM zEnterprise System|
|License||1972-1981 Public domain, 1976-present Proprietary|
VM (often: VM/CMS) is a family of IBM virtual machine operating systems used on IBM mainframes System/370, System/390, zSeries, System z and compatible systems, including the Hercules emulator for personal computers.
The first version, released in 1972, was VM/370, or officially Virtual Machine Facility/370. This was a System/370 reimplementation of earlier CP/CMS operating system. Milestone versions included VM/SP. The current version, z/VM, is still widely used as one of the main full virtualization solutions for the mainframe market.
The CMS usually coupled with VM in the name refers to the Conversational Monitor System, a single-user operating system developed to provide conversational time-sharing under VM.
The heart of the VM architecture is the Control Program or hypervisor abbreviated CP, VM-CP and sometimes, ambiguously, VM. It runs on the physical hardware, and creates the virtual machine environment. VM-CP provides full virtualization of the physical machine - including all I/O and other privileged operations. It performs the system's resource-sharing, including device management, dispatching, virtual storage management, and other traditional operating system tasks. Each VM user is provided with a separate virtual machine having its own address space, virtual devices, etc., and which is capable of running any software that could be run on a stand-alone machine. A given VM mainframe typically runs hundreds or thousands of virtual machine instances. VM-CP began life as CP-370, a reimplementation of CP-67, itself a reimplementation of CP-40.
Running within each virtual machine is another operating system, a guest operating system. This might be:
The Diagnose instruction ('83'x--no mnemonic) is a privileged instruction originally intended by IBM to perform "built-in diagnostic functions, or other model-dependent functions." IBM repurposed DIAG for "communication between a virtual machine and CP." The instruction contains two four-bit register numbers, called Rx and Ry, which can "contain operand storage addresses or return codes passed to the DIAGNOSE interface," and a two-byte code "that CP uses to determine what DIAGNOSE function to perform." A few of the available diagnose functions are listed below.
|0000||Store Extended-Identification Code|
|0004||Examine Real Storage|
|0008||Virtual Console Function--Execute a CP command|
|0018||Standard DASD I/O|
|0020||General I/O--Execute any valid CCW chain on a tape or disk device|
|003C||Update the VM/370 directory|
|0058||3270 Virtual Console Interface--perform full-screen I/O on an IBM 3270 terminal|
|0060||Determine Virtual Machine Storage Size|
|0068||Virtual Machine Communication Facility (VMCF)|
At one time, CMS was capable of running on a bare machine, as a true operating system (though such a configuration would be unusual). It now runs only as a guest OS under VM. This is because CMS relies on a hypervisor interface to VM-CP, to perform file system operations and request other VM services. This paravirtualization interface:
CMS and other operating systems often have DASD requirements much smaller than the sizes of actual volumes. For this reason CP allows an installation to define virtual disks of any size up to the capacity of the device. For CKD volumes, a minidisk must be defined in full cylinders. A minidisk has the same attributes as the underlying real disk, except that it is usually smaller and the beginning of each minidisk is mapped to cylinder or block 0. The minidisk may be[a] accessed using the same channel programs as the real disk.
A minidisk that has been initialized with a CMS file system is referred to as a CMS minidisk, although CMS is not the only system that can use them..
It is common practice to define full volume minidisks for use by such guest operating systems as z/OS instead of using
DEDICATE to assign the volume to a specific virtual machine.
The early history of VM is described in the articles CP/CMS and History of CP/CMS. VM/370 is a reimplementation of CP/CMS, and was made available in 1972 as part of IBM's System/370 Advanced Function announcement (which added virtual memory hardware and operating systems to the System/370 series). Early releases of VM through VM/370 Release 6 continued in open source through 1981, and today are considered to be in the public domain. This policy ended in 1977 with the chargeable VM/SE and VM/BSE upgrades and in 1980 with VM/System Product (VM/SP). However, IBM continued providing updates in source form for existing code for many years, although the upgrades to all but the free base required a license. As with CP-67, privileged instructions in a virtual machine cause a program interrupt, and CP simulated the behavior of the privileged instruction.
VM remained an important platform within IBM, used for operating system development and time-sharing use; but for customers it remained IBM's "other operating system". The OS and DOS families remained IBM's strategic products, and customers were not encouraged to run VM. Those that did formed close working relationships, continuing the community-support model of early CP/CMS users. In the meantime, the system struggled with political infighting within IBM over what resources should be available to the project, as compared with other IBM efforts. A basic problem with the system was seen at IBM's field sales level: VM/CMS demonstrably reduced the amount of hardware needed to support a given number of time-sharing users. IBM was, after all, in the business of selling computer systems.
Melinda Varian provides this fascinating quote, illustrating VM's unexpected success:
The marketing forecasts for VM/370 predicted that no more than one 168 would ever run VM during the entire life of the product. In fact, the first 168 delivered to a customer ran only CP and CMS. Ten years later, ten percent of the large processors being shipped from Poughkeepsie would be destined to run VM, as would a very substantial portion of the mid-range machines that were built in Endicott. Before fifteen years had passed, there would be more VM licenses than MVS licenses.
When IBM introduced System/370 Extended Architecture on the 3081, customers were faced with the need to run a production MVS/370 system while testing MVS/XA on the same machine. IBM's solution was VM/XA Migration Aid, which used the new Start Interpretive Execution (SIE) instruction to run the virtual machine. SIE automatically handled some privileged instructions and returned to CP for cases that it couldn't handle. The Processor Resource/System Manager (PR/SM) of the later 3090 also used SIE. There were several VM/XA products before it was eventually supplanted by VM/ESA and z/VM.
VM's role changed within IBM when hardware evolution led to significant changes in processor architecture. Backward compatibility remained a cornerstone of the IBM mainframe family, which still uses the basic instruction set introduced with the original System/360; but the need for efficient use of the 64-bit zSeries made the VM approach much more attractive. VM was also utilized in data centers converting from DOS/VSE to MVS and is useful when running mainframe AIX and Linux, platforms that were to become increasingly important. The current z/VM platform has finally achieved the recognition within IBM that VM users long felt it deserved. Some z/VM sites run thousands of simultaneous virtual machine users on a single system. z/VM was first released in October 2000 and remains in active use and development.
IBM and third parties have offered many applications and tools that run under VM. Examples include RAMIS, FOCUS, SPSS, NOMAD, DB2, REXX, RACF, and OfficeVision. Current VM offerings run the gamut of mainframe applications, including HTTP servers, database managers, analysis tools, engineering packages, and financial systems.
As of release 6, the VM/370 Control Program has a number of commands for General Users, concerned with defining and controlling the user's virtual machine. Lower-case portions of the command are optional
|#CP||Allows the user to issue a CP command from a command environment|
|ADSTOP||Sets an address stop to halt the virtual machine at a specific instruction|
|ATTN||Causes an attention interruption allowing CP to take control in a command environment|
|Begin||Continue or resume execution of the user's virtual machine, optionally at a specified address|
|CHange||Alter attributes of a spool file or files. For example, the output class or the name of the file can be changed, or printer-specific attributes set|
|Close||Closes an open printer, punch, reader, or console file and releases it to the spooling system|
|COUPLE||Connect a virtual channel-to-channel adapter (CTCA) to another|
|CP||Execute a CP command in a CMS environment|
|DEFine||Alter the current virtual machine configuration. Add virtual devices or change available storage size|
|DETach||Remove a virtual device or channel from the current configuration|
|DIAL||Connect your terminal to a logged-on multi-access virtual machine|
|DISConn||Disconnect your terminal while allowing your virtual machine to continue running|
|Display||Display virtual machine storage or (virtual) hardware registers|
|DUMP||Print a snapshot dump of the current virtual machine on the virtual spooled printer|
|ECHO||Set the virtual machine to echo typed lines|
|EXTernal||Cause an external interrupt to the virtual machine|
|INDicate||Display current system load or your resource usage|
|Ipl||IPL (boot) an operating system on your virtual machine|
|LINK||Attach a device from another virtual machine, if that machine's definition allows sharing|
|LOADVFCB||Specify a forms control buffer (FCB) for a virtual printer|
|Terminate execution of the current virtual machine and disconnect from the system|
|Sign on to the system|
|Send a one-line message to the system operator or another user|
|NOTReady||Cause a virtual device to appear not ready|
|ORDer||Reorder closed spool files by ID or class|
|PURge||Delete closed spool files for a device by class,m ID, or ALL|
|Query||Display status information for your virtual machine, or the "message of the day", or number or names of logged-in users|
|READY||Cause a device end interruption for a device|
|REQuest||Cause an interrupt on your virtual console|
|RESET||Clear all pending interrupts for a device|
|REWind||Rewind a real (non virtual) magnetic tape unit|
|SET||Set various attributes for your virtual machine, including messaging or terminal function keys|
|SLeep||Place your virtual machine in a "dormant state" indefinitely or for a specified period of time|
|SMsg||Send a one-line "special message" to another user|
|SPool||Set options for a spooled virtual device|
|STore||Alter the contents of registers or storage of your virtual machine|
|SYStem||Reset or restart your virtual machine or clear storage|
|TAg||Set a tag associated with a spooled device or file. The tag is usually used by VM's Remote Spooling Communications Subystem (RSCS) to identify the destination of a file|
|TERMinal||Set characteristics of your terminal|
|TRace||Start or stop tracing of specified virtual machine activities|
|TRANsfer||Transfer a spool file to or from another user|
|VMDUMP||Dump your virtual machine in a format readable by the Interactive Problem Control System (IPCS) program product|
In the early 1980s, the VM group within SHARE (the IBM user group) sought a mascot or logo for the community to adopt. This was in part a response to IBM's MVS users selecting the turkey as a mascot (chosen, according to legend, by the MVS Performance Group in the early days of MVS, when its performance was a sore topic). In 1983, the teddy bear became VM's de facto mascot at SHARE 60, when teddy bear stickers were attached to the nametags of "cuddlier oldtimers" to flag them for newcomers as "friendly if approached". The bears were a hit and soon appeared widely. Bears were awarded to inductees of the "Order of the Knights of VM", individuals who made "useful contributions" to the community.
In a real processor, the DIAGNOSE instruction performs processor-dependent diagnostic functions. In a virtual machine, you use the DIAGNOSE interface to request that CP perform services for your virtual machine. When your virtual machine attempts to execute a DIAGNOSE instruction, control is returned to CP. CP uses information provided in the code portion of the instruction to determine what service it should perform. Once this service is provided, control returns to the virtual machine.
|CP/CMS family relationships|
|-> derivation >> strong influence > some influence/precedence|
|> IBM M44/44X|
|>> CP-40/CMS -> CP[-67]/CMS||-> VM/370 -> VM/SE versions -> VM/SP versions -> VM/XA versions -> VM/ESA -> z/VM|
|> TSO for MVT -> for OS/VS2 -> for MVS -> ... -> for z/OS|
|>> MULTICS and most other time-sharing platforms|