In my previous article I discussed the history and rise of computer terminals. To dig a little deeper, let’s look at the way they communicated with mainframe systems.

There were essentially two philosophies (or perhaps ‘religions’ might be a better description depending on who you’re talking to) that determined how a Terminal communicated with a host system. These were the block mode or ‘smart’ devices and character modeor ‘dumb’ devices and, just to confuse things, there was also a terminal class that can operate in any mode and easily switch between them.

So what were the differences between these two ideas? Essentially, when using a terminal in block mode once the host system configured the terminal screen display, the operator could enter data into the ‘Fields’ on the screen without interacting with the host. When the operator finished, the terminal collected all the input and sent it back to the host as a “block” of data. On the other hand, a character-mode terminal had to constantly send and receive each and every keystroke and data to and from the host system during normal operation.

The character mode terminal used the host system to do all the validation of the data entered by the operator. Each time a key was pressed, the character code for that key was sent to the host system. Whatever the host processor was doing was interrupted so that it could process the character and the application, then decide what action to take, and finally perform that action. This could simply be to return the character to the terminal or to act on one of the control characters that may have been sent.

Applications using character mode terminals required laborious configuration of the screens in a way that would allow the operator to understand them. This involved moving the cursor around the screen, turning character attributes on and off, and printing text on the screen. On these terminals, everything happened at the current location of the cursor screen.

As a simple example, consider the case where we want the operator to enter a customer number, validate this, and display a customer’s name and address. Assuming we are using a VT100 terminal, the host system would initially send the following data (note that data prefixed with Esc is a escape sequencea special command used by terminals):

1. ESC[2J[2J[2J[2J:- clear the whole screen by
2. Esc[H[H[H[H:- Place the cursor on the top left of the screen
3. ESC[1m[1m[1m[1m:- Turn on Bold to make the message stand out
4. No customer.:- Write the message for the operator to enter the data
5. esc[0m[0m[0m[0m:- Disable Bold
6. ESC[0;9[0;9[0;9[0;9:- Move the cursor to the place where we want to see the customer number

Once all this is done, the operator can type the customer number, as each character is typed, the host sends the character before it is displayed, and will return it to the terminal to display it on the screen. Special characters, such as backspace, are used to allow easy editing. Finally the Enter key indicates that the customer number is complete. At this point, the host has what it needs to see if the client exists and display the details of that client by moving the cursor as above and printing the formatted information.

Obviously, in a real world scenario, the amount of display setup involved was considerably more. It should be clear that a lot of work needed to be done on the host end for any useful application, and that a lot of developer time was required to create host applications that would work with useful screens.

Block mode terminals had limited local intelligence and treated the screen as a window on a form. The form did not need to fit on the screen in one piece, as the operator could move the parts off-screen into view so they could be accessed as needed. Block mode terminals could have multiple pages on which data could be entered or on which data could be displayed. The operator could move to different parts of the form and to different pages by issuing commands to the Terminal that were executed locally. There was little or no involvement of the host during the data entry phase.

Take the case of a block-mode terminal, such as the IBM 3279, used on older IBM mainframes, such as System 360. When interacting with this terminal, the host would first send a block of data to the terminal representing the form to be filled out. , including a list of characters that are legal within each of the fields.

Once the form was displayed on the screen, the operator could fill in the fields and move through the form to any field that was legally accessible. This happened locally with no interaction required from the host. Upon completion of data entry, the operator pressed the ‘Send’ key. Only then was the data sent to the host as a block. The host then extracted the fields it is interested in, in our case the customer number, fetched the customer details and sent them to the terminal so they can be displayed on the form in the appropriate location.

From the above, it is clear that there was a lot more work for the host system when combined with character-based terminals compared to its block-mode equivalent. The advantage of character terminals is that they were much less expensive than the block-mode equivalent, and as long as the total number of connected terminals was not too large, it was a cost-effective solution.

On the other hand, block mode terminals have the advantage that the load on the host was greatly reduced and although the monetary cost of these terminals was higher, they used the expensive host processor much more sparingly. Block mode terminals were the most cost-effective solution in situations where many terminals were connected to a host system.

There were advantages and disadvantages to both types of terminals and the situation in which the device was to be used dictated which was the best solution. Today, this argument is largely irrelevant, as the advent of PC-based terminal emulation software has led to the demise of physical terminals, and thus to any cost-benefit argument. Terminal emulation software is now the application that will determine whether or not to use a block or character mode terminal.