IBM 3270 - Principles

Principles

The 3270 series was designed to connect with mainframe computers, often at a remote location, using the technology then available in the early 1970s. Two of the major design goals of 3270's are related to this: minimizing the amount of data transmitted, and minimizing the frequency of interrupts to the mainframe.

In a data stream, both text and control (or formatting functions) are interspersed allowing an entire screen to be "painted" as a single output operation. The concept of "formatting" in these devices allows the screen to be divided into clusters of contiguous character cells for which numerous "attributes" (colour, highlighting, character set, protection from modification) can be set. An attribute occupied a physical location on the screen that also determined the beginning and end of a "field" (separately addressable sub section of the screen).

Further, using a technique known as "read modified," a single transmission back to the mainframe can contain the changes from any number of formatted fields that have been modified, but without sending any unmodified fields or static data. This technique enhances the terminal throughput of the CPU, and minimizes the data transmitted. Some users familiar with character interrupt-driven terminal interfaces (such as UNIX) find this technique unusual. There was also a "read buffer" capability that transferred the entire content of the 3270-screen buffer including field attributes. This was mainly used for debugging purposes to preserve the application program screen contents while replacing it, temporarily, with debugging information.

Early 3270s offered three types of keyboards. The typewriter keyboard came in both a 66 key version, with no programmed function (PF) keys, and a 78 key version with twelve. Both versions had two program attention (PA) keys. The data entry keyboard had five PF keys and two PA keys. The operator console keyboard twelve PF keys and two PA keys. Later 3270s had twenty-four PF keys and three PA keys. When one of these keys is pressed, it will cause its control unit, historically, an 3174 or IBM 3274 but later the mainframe integrated communications adapter, to generate an I/O interrupt and present a special code identifying which key was pressed. Application program functions such as termination, page-up, page-down, or help can be invoked by a single key press, thereby reducing the load on very busy processors.

In this way, the CPU is not interrupted at every keystroke, a scheme that allowed an early 3033 mainframe with only 16 MB to support up to 17,500 3270 terminals under CICS. On the other hand, vi-like behaviour was not possible. (But end-user responsiveness was arguably more predictable with 3270, something users appreciated.) For the same reason, a porting of Lotus 1-2-3 to mainframes with 3279 screens did not meet success because its programmers were not able to properly adapt the spreadsheet's user interface to a "screen at a time" rather than "character at a time" device.

In contrast, IBM's OfficeVision office productivity software enjoyed great success with 3270 interaction because of its design understanding. And for many years the PROFS calendar was the most commonly displayed screen on office terminals around the world.

In contrast also, ICI Mond Division's Works Records System, the first known shared public spreadsheet used the 3270 successfully for what was, in effect, a high powered version of today's spreadsheets with additional functions. It remained in continual use for 27 years up until 2001 and, despite its lack of a GUI, cells could be defined anywhere on the screen (not necessarily in rows or columns) and could be instantly re-configured for length, content and formulas as required. It is interesting to note that ICI's online, fully interactive system pre-dated PC spreadsheets by quite a few years and allowed multiple users to use the spreadsheets at the same time, similar to today's Web based shared spreadsheets.

As mentioned above, the Web (and HTTP) is similar to 3270 interaction because the terminal (browser) is given more responsibility for managing presentation and user input, minimizing host interaction while still facilitating server-based information retrieval and processing.

Applications development has in many ways returned to the 3270 approach. In the 3270 era, all application functionality was provided centrally. With the advent of the PC, the idea was to invoke central systems only when absolutely unavoidable, and to do all application processing with local software on the personal computer. Now in the Web era (and with wikis in particular), the application again is strongly centrally controlled, with only technical functionality distributed to the PC.

In the early 1990s a popular solution to link PCs with the mainframes was the Irma board. It was a piece of hardware that plugged into a PC and connected to a coaxial cable towards the mainframe. IRMA also allowed file transfers between the PC and the mainframe.

Although CICS was the most common use of the 3270, you could also program the 3270 terminal with BTAM (Basic Telecommunications Access Method) via BAL (Basic Assembler Language) written as transients (somewhat similar to DLL's today). You could even drive the 3270 from a DOS partition running under VM, which was the normal CICS/3270 driver mechanism. The block mode modified field tag was particularly suited to converting formatted, structured punched card input onto the 3270 display device. With the appropriate programming any batch program that used formatted,structured card input could be layered onto a 3270 terminal. Highly complex engineering batch programs could be provided an online interface using BTAM and the 3270 terminal. (Badger Ltd. ~1976 BELTS Badger Engineering onLine Terminal System).