Peter writes:

> In article <[log in to unmask]>, [log in to unmask]
>  says...
>
>  > It's UNIX that doesn't transmit the DC1, not telnet. They simply aren't
>  > of UNIX's heritage. The presence of the go-ahead signals that DC1's
>  > are an MPE-ism not shared by another operating system that I know of.
>
>  Perhaps I am misunderstanding it then.
>
>  I'm not sure why we are talking about terminals.  This could apply to
>  any serial device.  I've seen these DC1's in the terminal output for
>  block mode but I'm not sure if that's related.
>
>  With UNIX, if a serial device sends too much data then the UNIX device
>  driver will send a XOFF or DC1  (ASCII char 17) to tell the device to
>  stop sending (as it's buffer is full).  When UNIX is ready to recieve
>  again it will send an XON - DC3 (ASCII char 19).
>
>  (Thinking about my next paragraph - I may have got those values above
>  the wrong way round! Same principle though)
>
>  It also works the other way around - from the device.  So if you typed
>  "cat filename" on a terminal (to send it to the screen) and wanted to
>  stop the output (because the file was very big), you could hit Ctrl-S to
>  stop the output and then hit Ctrl-Q to re-start it.  This kind of flow
>  control would apply to any serial device.  (you can still do it with
>  telnet and TCP/IP but the output is usually too fast these days)
>
>  Anyway - that manual page for FDEVICECONTROL sounded a bit like this
>  kind of flow control process - I realise from the responses that I might
>  be dead wrong.

Although, as you suspected, you have the XON/XOFF representations backwards,
your main point is correct: UNIX does use the DC1/DC3 characters as a serial
flow control mechanism, just as virtually every other serial device does.

But MPE uses DC1's in a double-duty capacity. In MPE, DC1's are also an
unsuppressable character that is also used as a "go-ahead" signal, not unlike
saying "over" when on a radio, indicating that the HP3000 is ready to receive new
input. When a line of input is terminated with a CR, the HP3000 absorbs the
line and processes it. During that processing period, MPE has traditionally put
itself into a refractory period such that any other characters inputted during
this period are ignored. Only after the line is fully processed and the HP3000
is ready to receive new input is the DC1 issued, essentially telling the
remote device to "go ahead" and give me whatever you've got to send me, if
anything.

UNIX, Linux and PCs are not designed this way. The input stream can be
continuous. The input buffer is constantly being searched for CR's, the line
terminating characters. If a CR is found, the input buffer up to the CR is chopped
off and handed to the processor, with whatever is left over remaining in the
buffer. While that line of input is being processed, incoming characters are
being constantly appended to the end of the current input buffer. If the CPU is
quite busy, it's possible to have many lines of input stacked up in the input
buffer.

The addition of typeahead to MPE allowed the HP3000 to act basically in the
same manner. Input could be continuous and the remote device no longer had to
wait for a "permission to transmit" that the DC1's implied, making MPE more
like UNIX.

There is however no universal, unsuppressable prompting character in UNIX or
Windows similiar to MPE's DC1. If you need to maintain a synchronous
conversation with a host in these systems, you have to either program the client
terminal process to look for some reliable character (or string of characters),
perhaps a "$", a common UNIX prompting character, or write your host-based
application code so it itself transmits a reliable go-ahead character, such as a DC1.

Wirt Atmar

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *