Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!cbosgd!ihnp4!ucbvax!cit-vax.arpa!engvax!KVC
From: KVC@engvax.UUCP
Newsgroups: fa.info-vax
Subject: Re: Broadcasting vs PASSALL
Message-ID: <8509111651.AA00463@cit-vax.ARPA>
Date: Wed, 11-Sep-85 12:51:10 EDT
Article-I.D.: cit-vax.8509111651.AA00463
Posted: Wed Sep 11 12:51:10 1985
Date-Received: Thu, 12-Sep-85 12:46:54 EDT
Sender: daemon@ucbvax.ARPA
Reply-To: info-vax@ucb-vax.arpa
Organization: The ARPA Internet
Lines: 24

> Yes, using the new PASTHRU setting does solve much of the problem, although
> sometimes i'd rather have *all* input available instead of losing ^S, ^Q to
> flow control.

I believe that you can toggle the interception of ^S/^Q in PASTHRU mode with
the /TTSYNC setting.  Disabling TTSYNC should let the characters through the
driver and into your buffer.  I haven't tried this, but I was given to
understand that PASTHRU is part of an effort to break control of the terminal
driver's interpretation of data out to several parameters, allowing users to
mix and match to get just the right amount of driver-level interpretation for
their application.  This is as opposed to a single parameter (like PASSALL)
which allows an all-or-nothing choice.

I have one concern in all this.  PASSALL mode let characters drop right through
the driver very very quickly, and was ideal for situations where the latency
time of the character through the driver had to be minimal.  Checking a
combination of characteristics (PASTHRU | NOTTSYNC etc.) may not be as fast.
Can anyone out there offer an informed opinion of whether PASSALL mode is
significantly faster than the equivalent PASTHRU, etc. modes?  If not, is
PASSALL mode going to remain for the few (if any) situations where this is
required?

	/Kevin Carosso              engax!kvc @ CIT-VAX.ARPA
	 Hughes Aircraft Co.