Processing data in blocks

From: Frank McConnell <fmc_at_reanimators.org>
Date: Wed May 27 23:38:17 1998

"Max Eskin" <maxeskin_at_hotmail.com> wrote:
> Back when I asked about the HP 3000, someone mentioned that it
> processed data in blocks. What exactly does that mean? How does it
> work?

Tim's answer got part of it. Here's some more of the picture, maybe
in gorier detail than you wanted to know.

Many HP terminals are somewhat intelligent and can be told (via escape
sequence or strap setting) to operate in "block mode", where the
terminal buffers data in its local display memory and lets the user do
local editing of it there. There can also be protected and
unprotected fields, which basically turn the display into a fill-in
form where the user can type in the unprotected fields and not in the
protected fields.

Some keys (ENTER (not RETURN) and the function keys) will still
initiate a transfer to the host computer. How that works is a
collection of fiddly little details but I'm going to try to describe
it in terms of the DC1/DC2/DC1 block-mode handshake.

Once the form has been sent to the terminal by the application (which
basically sends escape sequences and text to set up the block mode, the
form, and the unprotected fields), the application starts a read. The
terminal I/O system then sends a DC1 (control-Q) to the terminal so the
terminal knows there's a read pending.

When the user presses ENTER or a function key to tell the terminal to
send the form, the terminal sends a DC2 (control-R) to the host as an
indication that there's a block of data ready for transmission. The
host does whatever it needs to do to get ready for the block (this was
important in the days of the Series II/III which used a terminal
controller that couldn't handle all 16 ports sending 2400 bps data at
the same time) and then sends another DC1 as a go-ahead, and the
terminal sends an escape sequence for the pressed key followed by the
block of data (usually the data from the unprotected fields on the
form, separated by field-separator (FS) characters, and finishing up
with a record-separator (RS) character). The terminal won't send anything
more 'til it sees another DC1 from the host.

OK, well, that's about what you see on the wire if you stick a serial
line analyzer in between the 3000 and a terminal, and watch as an
application written using one of the more popular block-mode
application subroutine libraries (VIEW aka V/3000 aka VPLUS/3000) is
in use. Later 3000s have terminal controllers that can handle full
speed on all ports, and they can use a simplified block-mode handshake
(i.e. the 3000 sends the initial DC1, and the terminal just sends the
block when the user presses ENTER or a function key).

The goal of all this was, as Tim said, getting a rather slow HP3000 to
run a surprisingly big bunch of terminals doing transactions against
data on the 3000. The 3000 didn't have to do any work for the user
until the user had the transaction edited on the screen, in particular
it didn't have to respond to every user keystroke, and as the terminal
didn't have anything better to do it could respond to the user's
keystrokes right away.

There were also some full-screen editors that relied on the terminal
to buffer lines of text and let you do your editing in the terminal.
Those I used tended to run in line block mode (vs. VIEW which I think
used page block mode) where once the user pressed ENTER the host would
home the cursor and start sending escape sequences ("<ESC>d" I think,
followed by a DC1 once the read was pending) to get the terminal to
send the current line 'til it got to the bottom.

Feel free to ask questions about this if you want to know more.

-Frank McConnell
Received on Wed May 27 1998 - 23:38:17 BST