Editing Conversational Monitor System (section)

===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 &ndash; 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 (or the entire page) at once when the ENTER key or a [[function key|program function key]] (PFK) 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 [[communication protocol]]. (These mainframe-oriented communication technologies provided some of the capabilities taken for granted in modern communication networks, such as device addressing, routing, error correction, and support for a variety of configurations such as [[Videoconferencing#Multipoint videoconferencing|multipoint]] and [[multidrop]] topologies.)

The 3270 approach differed from lower-cost [[dumb terminal]]s of the period, which were [[Network topology#Point-to-point|point-to-point]] and [[asynchronous transmission|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 (telecommunications)|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]] (see [[IBM 3705]]) or Memorex 1270. These [[asynchronous transmission|asynchronous]] [[terminal controller]]s 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. (Most data centers did not include this equipment, except as needed for dial-up access. The 3270 approach was preferred.)

Block-oriented terminals like the 3270 made it practical to implement [[text editor|screen-oriented editors]] on mainframes &ndash; as opposed to [[line editor|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 (especially via [[CICS]]), 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 [[Block-oriented terminal|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 &ndash; 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, [[state (computer science)|stateful]], interactive environment, rather than adopting the CICS approach of a [[stateless server|stateless]] [[transaction processing|transaction-oriented]] interface. Yet CMS responds to page- or line-at-a-time interaction, instead of character interrupts.