Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site decvax.UUCP
Path: utzoo!linus!decvax!minow
From: minow@decvax.UUCP (Martin Minow)
Newsgroups: net.dcom
Subject: Re: XON/XOFF as flow control?
Message-ID: <266@decvax.UUCP>
Date: Mon, 7-Nov-83 18:22:17 EST
Article-I.D.: decvax.266
Posted: Mon Nov  7 18:22:17 1983
Date-Received: Wed, 9-Nov-83 02:49:36 EST
Organization: DEC UNIX Engineering Group
Lines: 34

Newsgroups: net.dcom
Subject: Re: XON/XOFF as flow control?
References: <3636@umcp-cs.UUCP>

Chris Torek makes several valid points regarding XOFF/XON as
flow control characters:

1. On a network, the terminal input buffer may be too small
   to allow the XOFF stop to take effect.  The only solution
   to this is to design a fairly large communications line
   buffer.  The device I'm working on can absorb about 250
   characters AFTER it sends XOFF before it loses data.

2. Some applications programs assume that the control characters
   may be used for program-specific tasks.  The major offender
   is EMACS.  The principal EMACS designer claims that EMACS
   is correct and the terminals are desinged incorrectly.
   (This is a summary of a long-running and acrinomious
   discussion that has been going on for many years and
   which I hope does not start again.)

The Ansi standard, as interpreted by terminal manufacturers,
reserves the C0 control characters (Hex 00 through 1F and 7F)
for device control.  Their use by an applications program is
at the pleasure and convenience of the manufacturer.  The
next generation of terminals, such as the DEC VT200 series
and the DEC Professional, also use the C1 control characters
(Hex 80 through 9F and FF) and the GR graphics set (Hex
A0 through FE).  You would thus be well advised to be careful
when using "bit 8" as a text position marker.

Martin Minow
decvax!minow