From:	CRDGW2::CRDGW2::MRGATE::"SMTP::DRYCAS.CLUB.CC.CMU.EDU::VMSNET-REQUEST"  5-DEC-1990 12:00:13.60
To:	MRGATE::"ARISIA::EVERHART"
CC:	
Subj:	RE: RE: typeahead buffer problems...?

Received:  by crdgw1.ge.com (5.57/GE 1.80)
	 id AA24276; Wed, 5 Dec 90 11:47:51 EST
Resent-From: vmsnet-request@DRYCAS.CLUB.CC.CMU.EDU
Resent-Message-Id:  <9012051647.AA24276@crdgw1.ge.com>
Return-Path: newsmgr <@PSUVAX1.BITNET:newsmgr@mccall.uucp>
Received: from harris.cis.ksu.edu by DRYCAS.CLUB.CC.CMU.EDU with PMDF#10017;
 Wed, 5 Dec 1990 10:48 EDT
Received: from deimos.cis.ksu.edu by harris.cis.ksu.edu (5.58/SWH-2.03); id
 AA04736; Wed, 5 Dec 90 09:48:01 CST
Received: by deimos.cis.ksu.edu (5.58a-3B15/SWH-2.03); id AA29978; Wed, 5 Dec
 90 10:49:20 EST
Resent-Date: Wed, 5 Dec 1990 10:52 EDT
Date: 4 Dec 90 14:29:57 GMT
From: ferriby@perot.com (John Ferriby)
Subject: RE: RE: typeahead buffer problems...?
To: vmsnet@DRYCAS.CLUB.CC.CMU.EDU
Errors-To: vmsnet-request@DRYCAS.CLUB.CC.CMU.EDU
Reply-To: vmsnet@DRYCAS.CLUB.CC.CMU.EDU
Message-Id: <742@perot.com>
X-Vms-To: vmsnet@DRYCAS.CLUB.CC.CMU.EDU
Organization: Perot Systems Corporation, Detroit, Michigan, USA

In article <1956.275a40ff@dcs.simpact.com>, jeh@dcs.simpact.com writes:
>> On the LAT port set the characteristic HOSTSYNC.  Hostsync, as it turns out,
>> enables a kind of flow control between terminal server and host on LAT ports.
> 
> Is this the same HOSTSYNC characteristic that, for local mux ports, enables
> the host (VMS system) to send XON/XOFF for flow control??? 

Yes, it is.  Flow control between the server and the DCE is controlled by the
terminal server port characteristics.  I think DEC saw a need for control of
this kind of functionallity and just picked HOSTSYNC as the TT_CHAR du jour.

> 
>> (This is in the LTDRIVER listing.)  Essentially it forces LAT credit waits
>> when the host buffer has not been emptied.  Since Hostsync is not on by default,
>> you will need to turn it on.  The two places that you should do this is in
>> UUCP_BIN:UUCP_LOGIN.COM and through code modifications to  Open_TTY (?this is
>> from memory?) SYSDEP.C.  
> 
> Why must it be done in both places?  Seems to me that if it's done in 
> open_tty (in sysdep.c), that should be sufficient, even for "answer mode"
> connections.  We don't need to set any other characteristics in both places;
> what's special about this one?

You're right -- I was brain dead.  ;-)

> 
>> If anyone wants copies of our source modifications please drop me a note and I 
>> will send them.
> 
> Yes, please.  Sounds like a good candidate for the next release.  
> 

Below is an outline of OPEN_TTY in SYSDEP.C This is from 1.x implementation,
the additions are noted with an asterisks in column one.  Better methods may
exist -- I'm strictly a novice with 'C', but it seems to work well for us.
(BTW, we are using a DECserver 200/MC running v3.0 software with this...)


open_tty(ttname, speed, extmask, vmssts)
	.
	.
	.
	$DESCRIPTOR(ttnamedsc, ttname);
*	$DESCRIPTOR(ttlatdsc, "lt");
	.
	.
	.
*	ttlatdsc.dsc$w_length = 2;
	.
	.
	.
	ttraw = ttold;
	ttraw.basic |= TT$M_NOECHO | TT$M_EIGHTBIT | TT$M_NOBRDCST | TT$M_PASSALL;
	ttraw.basic &= ~TT$M_WRAP & ~TT$M_HOSTSYNC & ~TT$M_TTSYNC & ~TT$M_ESCAPE
		& ~TT$M_MECHTAB;
*	if ((STR$POSITION(&ttnamedsc,&ttlatdsc)) != 0)
*		ttraw.basic |= TT$M_HOSTSYNC;



John Ferriby

Perot Systems Corporation                Telephone: 1+313-641-3660
4555 Corporate Drive                     Internet: ferriby@perot.com
Troy, MI 48098-6353                      UUCP:  {uunet,decwl,teemc} !perot!ferriby
