Xref: utzoo comp.dcom.modems:7486 comp.unix.xenix.sco:876
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!emory!kd4nc!n4hgf!wht
From: wht@n4hgf.Mt-Park.GA.US (Warren Tucker)
Newsgroups: comp.dcom.modems,comp.unix.xenix.sco
Subject: Re: SCO 3.2.2 & RTSFLOW CTSFLOW
Message-ID: <245@n4hgf.Mt-Park.GA.US>
Date: 27 Nov 90 18:20:00 GMT
References: <1838@utodaycom>
Reply-To: wht@n4hgf.Mt-Park.GA.US (Warren Tucker)
Followup-To: comp.dcom.modems
Organization: Amateur Radio Station N4HGF
Lines: 18

In article <1838@utodaycom> sean@utoday.UUCP (Sean Fulton) writes:
>... trouble with outgoing calls on my TB T2500 [with SCO 3.2.2 ...  RTS/CTS]

I think the problem is with the cu code. It just about has to be.
RTSFLOW and CTSFLOW are SCO extensions.  The problem arises when
standard System V code (cu) manipulates the termio state; not knowing
about the two extsion bits, it is probably jamming certain values into
c_iflag rather than ANDing out unwanted bits and ORing in wanted bits.

May I suggest you try ECU, an -er- optimized comm program for SCO, which
does one or two things cu doesn't and, specifically, lets you diddle
with rts/cts to your hearts content.  I almost have rev 3 ready to release,
but comp.sources.misc has 2.80, which with patches 1-4 applied, does
fairly well.
 
--------------------------------------------------------------------
Warren Tucker, TuckerWare emory!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US
ANSI C should have been named D, or Son of C