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 part
> of UNIX's heritage. The presence of the go-ahead signals that DC1's represent
> 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.

Thanks.

Peter
--
http://www.beluga.freeserve.co.uk

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