There seems to be some confusion what a 'Dumb' terminal is as visible in answers and comments to this question about portable dumb terminals. So:

  • What is a Dumb Terminal?

Points that would help to distinguish might be:

  • What features or missing thereof make it dumb or not?
  • What is a non-dumb/intelligent terminal?
  • Where does the term originate?
  • When was this term coined?
  • Examples for dumb/non-dumb terminals

Please note: This question is about terminals. Terminals are by definition devices that work only connected to and operated by a host. Anything able to work on its own is not a terminal, but something different (usually a computer) acting as a terminal. Further it's about the (historical) use of dumb or non-dumb in this context, not application for other areas (like programs or computers) or in a more general definition of what's dumb.

  • 5
    Another wonderful canonical question that will eventually get mostly lost in the clutter but which I think is valuable (even if I disagree on the answer!) for the next generation to learn. Jan 11 at 2:01
  • 3
    There was never any such thing as a "dumb" terminal until somebody made a "smart" terminal. So, the question should be, what makes a "smart" terminal smart? Unfortunately, the answer will depend on the time and the place and the application that you are asking about. Jan 11 at 15:43
  • 2
    @Criggie Personally, I think so. Terminals (dumb, smart and in between) are a core part of computing history. (Well not as core as memory...) But the problem is that a Canonical tag really doesn't make things discoverable for the people who really need to know. It is a fundamental StackExchange design issue. One we're working on at Codidact (shameless plug) but there is no retrocomputing over there. Jan 11 at 21:07
  • 2
    @Criggie What's wrong with TWM? AFAIK it's still active maintained. Way more than just the usual security blanket :)) And no, it's off topic because of being still active mainteines.
    – Raffzahn
    Jan 11 at 21:55
  • 3
    What is a Dumb Terminal? That's easy. Any terminal at which I sit. ;) Jan 12 at 23:17

6 Answers 6


Like any non-hard term, the label 'dumb' terminal is not only open to interpretation, but also used in different ways over time. Even more so for making others look bad (dumb) or one's own products better (non-dumb) was always part of marketing spin.


Dumb terminals as best described what abilities they do not offer:

  • use of complex encodings to reduce output data,
  • enabling generation of rich content,
  • offloading low level operations, like editing.


  • Dumb Terminals are essentially Glass TTY. They only display what is sent without any processing. Only minimal commands are interpreted; the host has little to no ability to modify displayed content.

  • Smart Terminals offer a wide variety of control over the way content is displayed (fonts, colour, size) and allow the host to manipulate content already displayed at the terminal with subsequent output. This enables dynamic content and complex screen designs like (text-)windows. Top models provide local edit features, offloading many low-level functions from the host to the terminal. This greatly reduces CPU load while at the same time speeding up user feedback.

Of course all of this is a continuum with the (Glass-) TTY at the Dumb end and everything past that becoming more and more Smart, all the way to stations like the IBM 3270 or Hazeltine 1500.

In the beginning ...

... terminal and printing terminal were redundant terms; it wasn't until the late 1960s that CRT-based terminals became a thing at all. They were essentially 1:1 replacements for existing printing terminals, in the most simple case the classic Type 33 Teletype. Such terminals only supported a very basic set of control functions, barely modified from TTY usage. Hence the name 'Glass TTY'.

  • CR and/or LF to move the cursor to the next line
  • BS to erase the previous character
  • BEL to give some sound
  • FF to clear the screen/reposition the cursor to home

Some terminals did split up Home and Clear Screen into two functions - which already started the development of 'less-dumb' terminals. Additions like basic cursor functions (CTRL-H/J/K/L) followed soon. A real arms race started; each manufacturer with its own, usually incompatible(*1), extensions. A look at mid-1980s termcap with collections of hundreds of differing terminals sheds some light.

In the late 1960s and early 1970s 'smarter' terminals began to appear, eventually cumulating in 1971 with block mode terminals like the IBM 3270 and independent operating stations like the Cogar 4 or Datapoint 2200. While the 3270 offered a great way to offload low-level interactivity (aka editing) without leaving the basic terminal paradigm, later development stopped them being terminals but rather stations with local programming and local data processing. Essentially the point when the modern PC was born.

<Insert> In some way this can be compared to the development of the web:

  • A dumb terminal is like displaying a text file in a browser.
  • A smart one uses HTML instead to format and beautify the output.
  • A block mode terminal (like 3270) is like having cgi-forms.
  • A RJE station (like a Datapoint 2200) is like Web 2.0 with all its local execution of JS, i.e. a computer. </Insert>

Getting Smarter

The way terminals developed at DEC gives a compact example for the gradual 'smartification'.

(The same can be seen when looking at a timeline of many more models from various manufacturers. Narrowing this to a single manufacturer and simplifying the points made should show the overall development)

Their 1970 VT05 already improved over a basic dumb terminal with

  • cursor home
  • directional cursor movement
  • cursor positioning
  • erase to end of line
  • erase to end of screen
  • horizontal tab stops

These additions already allowed improving the output stream by not having to blank out every character at the end of a line or at the end of the output when redrawing a screen. This may sound primitive to today's eyes, but it resulted in much higher output speed - especially considering the slow line speeds of that time.

While the VT05 and its variants were still using ASCII control characters like CTRL-H/J/K/L to handle the extended functionality, it was the VT50/52 of 1974 that broke off from ASCII use and moved all control functions into ESCape sequences. This followed the same line as standardisation efforts of ECMA for smart terminals, but was only partly compatible.

vt52 ad

Function-wise, the VT50/52 added more codes to manipulate existing screen content, such as insert/delete line/char. Together with a hold mode, that prevented scrolling, host-controlled update could be made in many ways without redrawing the whole screen. The VT52 enjoyed widespread use, with several competing manufacturers adding compatible modes to their terminals.

By 1978 DEC introduced the VT100. This time fully compatible to ECMA-48, or as we call them now ANSI sequences (*2). But the VT100 also added private sequences to improve content manipulation - like requesting cursor position from the host. Quite handy when multiple applications share a screen.

By 1983 the VT220 further extended abilities for a host to control content, including now being able to configure character sets on the fly. Options allowed the addition of graphic output. The VT220 had much impact(*3), and more than a million were sold.

In 1987 the VT320 marks essentially the last update DEC did to classic terminals (*4). It added even more character and graphics abilities and functions for local editing - much like IBM or Hazeltine decades before. Perhaps most remarkably, a way to handle multiple sessions over a single line was added.

Each of these generations got 'smarter' than the one before and as usual advertisement was made by noting how much better it was than any competing 'dumb' model.

Enter 'Dumb' Again

Like so often when a derogatory term is repeated often enough, people go ahead and redefine it in a positive way. That's what Lear-Siegler did in 1975 when marketing their new ADM-3 explicitly as a dumb terminal.

adm3 ad

With that move, the terms Dumb Terminal and Glass TTY finally became indistinguishable.

The ADM-3 went on to become quite successful, becoming a main replacement for printing terminals (like the Teletype Model 33) and an icon for terminals in general, not least due to the low price making it pop up an many places with mini computers and even more micros. Albeit usually with the lower caps add on :))

It wasn't until a year later that Lear-Siegler introduced the ADM-3A with improvements like default lower char display, many display attributes, basic cursor movement and cursor positioning. With these additions the ADM-3A was put on par with the DEC VT-05 and stayed firmly on the simple side compared to a DEC VT52 with all its edit commands.

A good contrast of the same time might be the 1977 Hazeltine 1500 'smart terminal'. It featured not only quite comprehensive edit functions for dynamic content, but also a block mode, much like the IBM 3270, but still keeping compatibility with 'standard' terminals, all the way back to Teletype-like devices. Applications could send out format definitions (think of them like a HTML Form) and let all intermediate editing be done locally with zero interaction needed from the host. All entered data is sent back at the end as one large transmission.

The same way the ADM-3(A) captured large part of the dumb(er) end, the Hazeltine 1500 became extremely successful in the business world. Usage of a 1500 resulted, despite its high price, in notable savings by enabling to serve more terminals without bigger computers - the same way IBM mainframes kept an advantage.

Bottom Line

  • Dumb Terminals are terminals without much control over content format, attributes or handling. Usually barely more than Glass-TTY.

  • Smart Terminals allow the host wide control over content display and direct manipulation of existing content.

  • Devices that can download programs and execute them are no longer terminals, but computers.

*1 - Incompatible in every way - not even the use of ESCape was considered settled, as the 1977(!) Hazeltine 1500 used '~' as escape character for control sequences.

*2 - Much loved from DOS times they are :))

*3 - It's said the IBM-AT keyboard is shaped after the VT220 keyboard

*4 - The 1990 VT420 is barely more than a cost improved variant of the VT320.

  • 1
    I wholeheartedly disagree with your definition of smart terminal. Block mode terminals (like but certainly not limited to the 3270) are smart terminals. Character addressable terminals are still classified “dumb”. (I programmed DOS/VSE on a 3270, and OpenVMS on a range on VTxxx terminals, and stand by my comment.)
    – RonJohn
    Jan 11 at 2:05
  • 3
    @RonJohn Your comment puzzles me a bit. Didn't I use 3270 type block mode terminals as the ultimate definition of smart? Then again, even a 3270 is character addressable. I worked for decades with them, regarding their way above all character based tinkering. Still, existing content can be character addressed and modified, deleted or inserted with subsequent output. Sure, most form handling software does not offer templates to do so, but the terminals can handle such requests quite well. I loved to write low level handler doing so.
    – Raffzahn
    Jan 11 at 3:09
  • 2
    @grovkin Why on earth? CTRL-C (like XON/XOFF) has never been processed on the terminal side. It's a key-press like any other, simply sent toward the host when done. Any interpretation has always be done by sol (mor or less) low level handler at the host OS.
    – Raffzahn
    Jan 11 at 23:05
  • 2
    @grovkin = All that was necessary was for input and output to be full-duplex, so the terminal could send a character while processing output. After that, it was up to the OS. Actually, even in half-duplex you could use the 'break' capability of the terminal (go open-circuit) to get the attention of the computer-side connection, which is why some multi-access systems used break as an interrupt signal. Jan 11 at 23:09
  • 1
    @grovkin - Raffzahn can update his answer with info from comments, if he's so inclined. I'm reluctant to change someone else's words. Jan 11 at 23:17

I suggest a somewhat different definition of dumb terminal. While clearly some terminals were smarter than others, I don't think things such as programmable selection of fonts and colors, direct cursor addressing, or even limited block mode operation really makes a terminal "smart". But there are a few key things that do make a terminal smart:

  • Local storage beyond the bare minimum needed for configuration. A terminal with a few bytes to store settings instead of dip switches isn't "smart". But a terminal with a local floppy drive, hard drive or magnetic tape for storage is "smart". Punched paper tape or other storage that is used simply as direct load & store to the remote location with no local processing (beyond parity checking or similar) doesn't count.
  • Ability to run local programs. It doesn't matter whether the programs are loaded locally by typing in on the keyboard or loading via punched paper tape, or loaded remotely (like Javascript downloaded in a browser), but if a terminal can run real programs locally, that is "smart". Could be BASIC, assembler, direct binary load (but programs, not loading an alternate character set), APL, whatever.

This clearly puts machines like the Datapoint 2200 into the smart category. It also keeps machines like the range of DEC VT terminals, Wyse terminals, etc. in the dumb category. Heath/Zenith H-19/Z-19 dumb, Heath/Zenith H-89/Z-89 smart.

As a simple example of why I think features such as fonts/attributes should not be something that makes a terminal "smart", consider boldface and u̲n̲d̲e̲r̲l̲i̲n̲e̲: (and ironically had to cheat here to get underline because Markdown as used by SE doesn't support user-designated underline...)

  • Teletype - Boldface: print text, CR without LF, print spaces to position, print text; Underline: print, CR without LF, print spaces to position, print _
  • First dumb terminals - no bold or underline!
  • Later dumb terminals - send attribute (control or escape code) for bold or underline, display text, send attribute to turn off bold or underline
  • HTML - Bold - <b>text</b>; Underline <u>text</u>

In all of the above cases, the host computer is sending a stream of characters that are interpreted by the terminal in some manner. No real "smart" capabilities needed. It is only later with:

  • HTML with CSS - style sheet sent at the beginning or as a separately loaded file, followed by user's choice of tags surrounding the text.

and of course Javascript really making things "smart" that the terminal needs to do anything more than an incrementally more advanced "process the incoming character stream in a well-defined manner".

This keeps a number of color and/or graphics terminals in the "dumb" category as well. For example, the Tektronix 4010 and later emulations such as the Wyse 99GT included high resolution graphics but no permanent storage and no local processing beyond processing the simple drawing commands in the input stream.

Where I do see some fuzziness is with block/batch mode terminals. IBM 3270 is the classic, but there were plenty of other terminals with similar (at least conceptually) capabilities. Even just protected space/unprotected fields is a certain level of "smart", and if there is any validation included (e.g., send a code to indicate a field must be numeric) then that does seem to cross over to "smart". On the other hand, is the ability to mark fields and enforce some validation enough of a "program" to merit "smart"?

Once microcomputers became more common, particularly with advent of affordable PC networks, the distinction became, in my opinion, a little clearer again. In the mid-1980s and beyond, anything with no local storage and no ability to run "real" programs was "dumb". PC that used a ROM to boot over the network with no local floppy or hard drive? Smart because it could run local programs, even if they had to be loaded over the network. Terminal with block mode but no ability to run user programs and no storage? Dumb.

While conceptually similar to dumb terminals in terms of power/capability relative to a remote system, any device capable of running a modern web browser is, by my definition, a smart terminal. If nothing else, if a device can run downloaded Javascript, it qualifies as smart.

  • 3
    "Dumb" in this sense is (outside of computing) colloquially a pejorative, and is the converse of "intelligent". This, I think, requires some general computational ability on the part of the terminal, i.e., you can load and run programs -- as you say. Jan 11 at 2:07
  • 4
    @Raffzahn I am basing my answer on the way I referred to such devices back in the 1980s. I considered a typical cursor-addressable/etc. terminal to be a "dumb" terminal when compared to PCs (and Apple ][ etc.) of the era. And I agree "A PC running some terminal program does not become a terminal". I posit that a JS-capable browser "dedicated device" (i.e., unable to "load Apps") is a modern-day smart terminal (i.e., client-only device) - it certainly isn't "dumb", the question is whether it morphs from "very smart terminal" to "full computer". Jan 11 at 3:38
  • 5
    That is exactly the definition of dumb/smart that I also learned in the 80s/90s. I worked for a company that built terminal emulation cards (BS-2000) and also personal time recording systems for industrial applications (Siemens ES-100/ES-200/ES-300) and everyone made the distinction between dumb and smart terminals following this definition. Local processing and storage capacity=smart, only connected operation=dumb. Jan 11 at 14:24
  • 4
    What I suppose is happening here is a generational shift of definition due to the progress in technology. The distinction between glass TTY/auto-formatting terminals might have made sense in the '60s early '70s, but in the '80s not anymore as even the most primitive microcontrollers (8048, 6511, etc) had enough oompf to make Apple 1 display a laughing stock. The old definition of dumb/smart did not make any sense anymore and was repurposed to something that made sense in the then current technology. Jan 11 at 14:36
  • 2
    @SolomonSlow - a VT52 was never smart (and I say this as a VT52 fan; the VT100 was a compromise as far as I was concerned). I'd maybe consider the VT62 (block-mode terminal a la 3277, with DDCMP protocol support) to be 'smart', or at least to have a couple of O-levels. Jan 11 at 23:14

As a practical matter, a "dumb" terminal is a terminal that has little more than the capabilities specified in the Unix terminfo database for TERM=dumb. Those are:

dumb|80-column dumb tty,
    bel=^G, cr=\r, cud1=\n, ind=\n,

or, in English: it displays 80 columns of fixed-width ASCII text; it can move the cursor position back to the beginning of the current line, and to the beginning of the next line, and it can ring a bell. And that's it. You don't even get backspace. (I am not sure what the binary "am" capability means -- "automatic right margin" is the only explanation the manual gives.) This is essentially what a classical teleprinter like the Teletype Model 33 could do.

I would personally set the dividing line between "dumb" and "not dumb" a little bit higher, with the "glasstty" capability set still qualifying as "dumb":

glasstty|classic glass tty interpreting ASCII control characters,
    am, OTbs,
    bel=^G, cr=\r, clear=^L, cud1=\n, cub1=^H, kcud1=\n, kcub1=^H,
    nel=\r\n, ht=^I,

Here we have backspace (and thus the ability to edit the current line) and screen clear, but we don't have an addressable cursor, fonts, colors, graphics, or non-ASCII characters. Anything with an addressable cursor is definitely "not dumb". A tty with font and charset control but no cursor addressing could still count as "dumb"; there were teleprinters that had those, after all.

"Smart" is another matter. Personally, the features that other answers say are required for a terminal to be "smart" — local persistent storage, programmability, etc — to me they sound like features that make the device not a terminal anymore, but rather a full-fledged computer. Even X terminals didn't have those. Maybe that means to me there's no such thing as a "smart terminal."

  • 5
    AM or Automatic Margin simply means that when the output position gets moved past the line length (e.g. 80) it gets automatically moved to the first position of the next line - like an implied CR/LF. This is important as TTYs usually did not insert an automatic CR/LF. Without AM an application has to end a lien always with a CR to advance, with CR, this could be saved if the maximum (cols) has been outputted. Yes, even such most basic issues were anything but given.
    – Raffzahn
    Jan 12 at 3:28
  • @Raffzahn Oh, I see, like a purely mechanical typewriter. I'm not old enough for any of those TTYs (although I am old enough to have learned to type on a mechanical typewriter). I was imagining something like "you have to pad all lines on the right to 80 columns with spaces" which didn't make much sense, even if punched cards were involved.
    – zwol
    Jan 12 at 3:33
  • End-of-line behavior isn't a given even today. The CFA634 20×4 display, for example, has configurable behavior for both end-of-line and bottom-line newline. Writing past the end of a line can either wrap to the next line (an implicit CR/LF) or have subsequent characters be ignored. A newline on the last line can either move the cursor to the top line (keeping existing text unchanged) or scroll all lines one line up on the display (blanking the last line IIRC); both keep the cursor in the same column. Jan 12 at 13:49

"Dumb" terminals had a simple enough basic feature set (add character, scroll up, backspace, etc.) that their logic could be completely implemented without a CPU or microprocessor, some using just TTL SSI and MSI logic devices, plus memory (RAM or shift registers). There were even cookbooks published with logic schematics so you could build one from simple IC parts (and no CPU).

Smart terminals often had a rich enough interface protocol that a processor and software or microcode was required to decode the command sequences, and perhaps control a display with more features (fonts, status bars, colors, etc.)

Dumb terminals could exist and were manufactured years before single chip microprocessors were available. Later, after more advanced ICs were available, a vendor could segment their market with a microprocessor based terminal that only included mostly features possible in earlier non-microprocessor based terminals. Thus called "Dumb" for marketing reasons.

  • 2
    One little problem: The Datapoint 2200, arguably one of the first really smart terminals, as it had full computer capability (programmable, local storage, etc.), was the prototype for the Intel 8008 but actually was implemented using TTL logic chips. So if a "smart" terminal needs a single-chip CPU does a terminal that doesn't have chip CPU automatically define "dumb"? I don't think so. Capabilities determine the dumb/smart (no matter where you draw the actual line between them), not the technology used to implement them. Jan 11 at 22:45
  • 4
    The earliest Datapoint 2200 was implemented with a discrete logic 1-bit serial CPU that reportedly ran its microcode faster than an 8008. So still a processor and software driven smart terminal. Just not with the CPU on 1 chip.
    – hotpaw2
    Jan 12 at 3:21
  • 2
    I'm upvoting this because it answers the question (correctly IMO) without writing a massive essay.
    – JeremyP
    Jan 12 at 8:52

Firstly let me say that in the UK, using the term "dumb" to mean "unintelligent" is considered offensive by those with speech disorders. It appears to be perfectly acceptable in the US.

My recollection (I'm not going to try and research it) is that the term "dumb terminal" has a rather confused history. I first encountered it in the context of mainframes (specifically ICL mainframes) where a significant amount of input/output processing was offloaded from the central computer, but the usual configuration was to do this processing in a "cluster controller" that supported perhaps 16 or 32 terminals. These terminals had very little logic beyond being able to display a particular character at a particular location. The cluster controller did everything, from reflecting keystrokes onto the screen (if you got the wiring wrong, your keystrokes would appear on someone else's screen) to some quite complex functionality such as checking that particular input fields were required to be numeric. The intelligence was all in the controller, not in the terminal. But sometimes you needed a single terminal in a location where there was no cluster, and then you could use an expensive terminal that contained all the logic built in. So you had the choice between using a dumb terminal as part of a cluster controlled by an intelligent controller, or using an intelligent terminal.

The functionality of the mainframe terminal was not unlike that of a simple HTML form. You could send a message out from a transaction processing application with control sequences to mark which parts of the screen were editable and which were fixed, to control the tab order between fields, and to do basic validation. When the user hit SEND, only the input fields were sent back (perhaps only those that had actually been edited). This all served to reduce the IO and processing load on the mainframe, allowing it to support hundreds of terminals despite having remarkably little CPU power.

Later, in the 1980s, when UNIX came along, this all changed. By this time mainframe terminal functionality had moved into the terminal and out of the controller, so in the old sense of the word, all terminals were intelligent. At the same time UNIX and VAX minicomputers had enough CPU power to do all the low-level keystroke processing in the main processor; they had none of the offloaded processing that mainframes had, so in this sense their terminals were "dumb".

However, because the application on a UNIX or VAX machine was notified of every keystroke on the terminal, they were able to deliver a much more interactive and responsive user experience. This led to an inversion of the terminology: the mainframe terminals were referred to as "dumb terminals" not because they lacked internal processing logic, but because they lacked the interactivity to deliver the same kind of user interface.

  • It might be more correct to state that the minicomputers had enough CPU power to spare to do all the low-level keystroke processing in the main processor. They were not actually more powerful CPUs than mainframes of the time; it was more the willingness of the users and owners to spend their CPU power on that. (Individual machines generally had far fewer users and much less overall load, even sitting idle from time to time, so spending cycles on this was much less likely to significantly delay another user's application.)
    – cjs
    Jan 14 at 0:51
  • Indeed. Perhaps the minicomputer operating systems were also better at doing the interrupt handling necessary to process individual keystrokes. Jan 14 at 9:24
  • @MichaelKay Sometimes yes - smaller system can afford to interrupt "everything/everyone". Sometimes no - mainframe more likely to have a true separate I/O processor. Jan 14 at 13:29

The other answers provide lots of details while missing the point.

On business computer systems the terminals were used to fill in forms that were then submitted to a computer program that then returned the next form to be displayed and/or filled in. As well as forms a computer program may present a multiple level menu and be reactivated when the user had chosen an option. (Think IBM mainframe)

On technical computer systems terminals were used to edit files (with vi for example) and to display auto-updated data like readings from sensors on an industrial process. (Think PDP 11)

We will only consider the form filling for business computers from now on.

Clearly form filling needs logic to move between fields and edit the text in a field. There are a few locations this logic was implemented in:

  • Within the application as was common on Unix, this was the most flexible option but limited how many users could be supported on a single machine. It also resulted in very slow movement between fields if the data link was slow or the program had been paged out. (Often the application had to respond to each key press as it was pressed.)

  • In a separate IO processor (common with VMS) this permitted the main computer to support many more users but still has the issue with slow response over poor data links.

  • In a smart terminal when the application sent a description of the form to the terminal, and the terminal returned the value of the fields to application when the user submitted the form. Often these would be multiple page forms with restrictions on the format of data that could be entered into a field for example a date field. (Hidden fields were often used to track application state, so a form could still be processed if application has been restarted.) Very common with IBM 360 system using IBM smart terminals.

A 'Dumb' terminal was a terminal without the ability to locally edit forms. The form functions in HTML logically (before Javascript was used) behaved much like a mainframe smart terminal.

  • I wonder why it wasn't common for systems to have some permanently-loaded code that would handle certain kinds of application input processing on a per-keystroke basis without having to swap in the entire application until either a key was hit that could not be handled with the common inputs handler?
    – supercat
    Jan 13 at 18:21
  • 1
    @supercat Programming can get a lot more complicated that way. Varied a lot by system, but if you had a system with 100 terminals and virtual memory and 98% of the time any given terminal was not in use, your system might be able to handle 100 users with only 10x the application memory requirement (plus OS memory requirement). The first time you send a keystroke after being swapped out you get a couple of seconds delay and after that full speed ahead. The problem is when all of a sudden 50 users are going at once. Typical example might be a large-scale airline reservation system - thousands Jan 13 at 18:53
  • of terminals but at any given time only a few people are entering transactions. Banking, many other industries as well. But loading up that same machine with enough memory for everyone would have been cost-prohibitive until relatively recently. Jan 13 at 18:54
  • 1
    @supercat That's true, provided the buffering process knows which characters matter. That can be done (and I am sure has been done) in large specialized systems. But a more general level it is not so simple. Unless you use a programmable front-end I/O processor customized to handle all of that. Kind of like at U of MD in the 1980s where they used Series/1 as a front-end to translate character mode ASCII "dumb" terminals to block-mode 3270 "smart" terminals. (using the character vs block definition of dumb/smart). But those Series/1 were not trivial or cheap. Jan 13 at 21:44
  • 1
    @supercat DEC would have tended to put a mini computer in each office to handle the much cheaper terminals and form editing etc, sending the complete form over the network to the database cluster. IBM also had terminal controllers that converted a few nearby terminals into smart terminals. The difference with IBM is that the customer could not put programs on the processor in brench offices (and terminals) as they just run the IBM form editing system. Jan 13 at 23:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.