Conversational Monitor System
The Conversational Monitor System is a simple interactive single-user operating system. CMS was originally developed as part of IBM's CP/CMS operating system, which went into production use in 1967. CMS is part of IBM's VM family, which runs on IBM mainframe computers. VM was first announced in 1972, and is still in use today as z/VM.
CMS runs as a "guest" operating system in a private virtual machine created by the VM control program. The control program plus CMS together create a multi-user time-sharing operating system.
History
CMS was originally developed as part of IBM's CP/CMS operating system. At the time, the acronym meant "Cambridge Monitor System".- CMS first ran under CP-40, a one-off research system using custom hardware at IBM's Cambridge Scientific Center. Production use at CSC began in January 1967. The CMS user interface drew heavily on experience with the influential first-generation time-sharing system CTSS, some of whose developers worked on CP/CMS.
- Later in 1967, CP/CMS became generally available on the IBM System/360 Model 67, where, although the new control program CP-67 was a substantial re-implementation of CP-40, CMS remained essentially the same. IBM provided CP/CMS "as is" - without any support, in source code form, as part of the IBM Type-III Library. CP/CMS was thus an open source system. Despite this lack of support from IBM, CP/CMS achieved great success as a time-sharing platform; by 1972, there were some 44 CP/CMS systems in use, including commercial sites that resold access to CP/CMS.
Through all its distinct versions and releases, the CMS platform remained still quite recognizable as a close descendant of the original CMS version running under CP-40. Many key user interface decisions familiar to today's users had already been made in 1965, as part of the CP-40 effort. See CMS under CP-40 for examples.
Both VM and CP/CMS had checkered histories at IBM. VM was not one of IBM's "strategic" operating systems, which were primarily the OS and DOS families, and it suffered from IBM political infighting over time-sharing versus batch processing goals. This conflict is why CP/CMS was originally released as an unsupported system, and why VM often had limited development and support resources within IBM. An exceptionally strong user community, first established in the self-support days of CP/CMS but remaining active after the launch of VM, made substantial contributions to the operating system, and mitigated the difficulties of running IBM's "other operating system".
Architecture
CMS is an intrinsic part of the VM/CMS architecture, established with CP/CMS. Each CMS user has control over a private virtual machine - a simulated copy of the underlying physical computer - in which CMS runs as a stand-alone operating system. This approach has remained consistent through the years, and is based on:- Full virtualization, used to create multiple independent virtual machines that each completely simulate the underlying hardware
- Paravirtualization, used to provide a hypervisor interface that CMS uses to access VM services; this is implemented by the non-virtualized DIAG instruction
CMS was originally built as a stand-alone operating system, capable of running on a bare machine. However, CMS can no longer run outside the VM environment, which provides the hypervisor interface needed for various critical functions.
Features
CMS provides users an environment for running applications or batch jobs, managing data files, creating and debugging applications, doing cross-platform development, and communicating with other systems or users.CMS is still in development and wide use today.
Basic environment
Users log into VM, providing a userid and password, and then boot their own virtual machine. This can be done by issuing the command "IPL CMS" ; though this is normally done automatically for the user. Personal customization is done by a standard shell script file named "PROFILE EXEC", which sets up user-specified environmental defaults, such as which disks and libraries are accessed.Terminal support
CMS started in the era of teletype-style paper terminals, and the later "glass teletype" dumb terminals. By the late 1970s, however, most VM users were connecting via full-screen terminals - particularly the IBM 3270, the ubiquitous transaction processing terminal on IBM mainframes. The 3270 played a strategic role in IBM's product line, making its selection a natural choice for large data centers of the day. Many other manufacturers eventually offered bisync terminals that emulated the 3270 protocol.3270s had local buffer storage, some processing capabilities, and generally dealt with an entire screen of data at a time. They handled editing tasks locally, and then transmitted a set of fields at once when the ENTER key or a program function key was pressed.
The 3270 family incorporated "smart" control units, concentrators, and other network processing elements, communicating with the mainframe over dedicated circuits at relatively high speeds, via a bisync synchronous data transmission protocol.
The 3270 approach differed from lower-cost dumb terminals of the period, which were point-to-point and asynchronous. Commercial time-sharing users, an important segment of early CP/CMS and VM sites, relied on such devices because they could connect via 300- or 1200 bit/s modems over normal voice-grade telephone circuits. Installing a dedicated circuit for a 3270 was often not practical, economical, or timely.
The 3270's block-oriented approach was more consistent with IBM's batch- and punched card-oriented view of computing, and was particularly important for IBM mainframes of the day. Unlike contemporary minicomputers, most IBM mainframes were not equipped for character-at-a-time interrupts. Dumb terminal support relied on terminal control units such as the IBM 270x or Memorex 1270. These asynchronous terminal controllers assembled a line of characters, up to a fixed maximum length, until the RETURN key was pressed. Typing too many characters would result in an error, a familiar situation to users of the day.
Block-oriented terminals like the 3270 made it practical to implement screen-oriented editors on mainframes - as opposed to line-oriented editors, the previous norm. This had been an important advantage of contemporary minicomputers and other character-oriented systems, and its availability via the 3270 was warmly welcomed.
A gulf developed between the 3270 world, focused on page-oriented mainframe transaction processing, and the asynch terminal world, focused on character-oriented minicomputers and dial-up timesharing. Asynchronous terminal vendors gradually improved their products with a range of smart terminal features, usually accessed via escape sequences. However, these devices rarely competed for 3270 users; IBM maintained its dominance over mainframe data center hardware purchase decisions.
Viewed in retrospect, there was a major philosophical divergence between block-oriented and character-oriented computing. Asynchronous terminal controllers and 3270s both provided the mainframe with block-oriented interactions - essentially, they made the terminal input look like a card reader. This approach, preferred by IBM, led to the development of entirely different user interface paradigms and programming strategies. Character-oriented systems evolved differently. The difference is apparent when comparing the atomic transaction approach of dominant CICS with the interactive, stream-oriented style of UNIX. VM/CMS evolved somewhere between these extremes. CMS has a command-driven, stateful, interactive environment, rather than adopting the CICS approach of a stateless transaction-oriented interface. Yet CMS responds to page- or line-at-a-time interaction, instead of character interrupts.
Performance
CMS earned a very good reputation for being efficient, and for having good human factors for ease of use, relative to the standards of the time. It was not uncommon to have hundreds of concurrent CMS interactive users on the same VM mainframe, with sub-second response times for common, 'trivial' functions. VM/CMS consistently outperformed MVS and other IBM operating systems in terms of support for simultaneous interactive users.Programming and major applications
Many CMS users programmed in such languages as COBOL, FORTRAN, PL/I, C/370, APL, and the scripting language REXX. VM/CMS was often used as a development platform for production systems that ran under IBM's other operating systems, such as MVS.Other CMS users worked with commercial software packages such as FOCUS, NOMAD, SPSS, and SAS.
At one time, CMS was also a major environment for e-mail and office productivity; an important product was IBM's PROFS.
Two commonly used CMS tools are the editor XEDIT and the REXX programming language. Both of these products have been ported to other platforms, and are now widely used outside the mainframe environment.