From: Jean-Pierre Radley <jpr@jpradley.jpr.com>
Subject: Re: the RTS/CTS story, Re: UUCP woes on 3.2.0 to 3.2.4 upgrade (fwd)
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Content-Type: text
Reply-To: jpr@jpr.com
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Wed, 6 Jan 1993 16:31:05 GMT
Content-Length: 2928      
Precedence: bulk

Greg Andrews writes:
> >
> >Prior to 3.2v4.0, SCO's serial driver (sio) only did one kind of
> >hardware handshake, "unidirectional", in which the external device can
> >tell the computer to shut up, but not vice-versa.  This is useless for
> >modem communications, and in fact it severely confuses some modems such
> >as Telebits.
> >
> 
> No one's confused but the customers.  The modem simply obeys the rules
> described by it's configuration, just as the tty driver does.
> 
> >A mystery remains.  The sio driver explicitly declines to do hardware
> >flow control on a local connection, defined by the setting of the CLOCAL
> >bit.  That doesn't jive with the setting of CLOCAL here.
> >
> >... so I check the source.  cu & uucico call a routine "fixline" (you
> >can see it in the -x9 output) which, among other things, turns CLOCAL
> >off if the system you're connecting to is not "Direct"; and turns it
> >*on* if it is.  So the next surprise waiting is that flow control
> >*still* won't work between direct systems.  hmmm.
> >
> 
> Bela, you have GOT to be kidding!  The same version that added uucp "e"
> and "f" support won't do hardware flow control over direct cable links?
> 
> Is there a way I can request that CRTSFL be changed so it's not
> dependent on CLOCAL?  Could I talk with someone about becoming a
> beta tester, at least with respect to the modem-intensive parts of
> the OS?
> 

I wonder if this ties into the discussion I had both in this place and
privately with Don Draper last spring. We didn't really resolve anything.

This was not a problem with Xenix, as I recall.
But cu from Unix 3.2v2 or 3.2v4 croaks as follows:
Using an enabled Specialix port, "cu dir" will not talk to a modem.
After a "Connected" message, any keypress immediately causes "Lost Carrier".
I have no problem if I first disable the port, in which case cu can address
either the lower-case or upper-case alias of the port.
I have no problem if I use "cu dir" on an enabled tty1A.
Several different modems brands make no difference.

This doesn't affect uucp or xc or Taylor-uucp, all of which readily use
enabled ports for dial-out.

I'm beginning to get the feeling that since cu was written, back in the
days of Teletypes, it has hardly been changed to live with today's
high-speed modems, let alone for a direct connection at 57600...

On a related note, there's what I refer to as the "AT3Z" scenario: the
business of having a getty for an enabled port call the dialer with a -h
option after a call is completed.
The -h results in an "ATZ" instruction to the modem.
But this doesn't take into account the &D3 setting of today's modems,
which lets a drop in DTR effectively accomplish an ATZ (1).  Then
'dialer -h' reopens the modem and does it (2), and then the modem
again reloads from NVRAM when 'dialer -h' exits and drops DTR (3).

-- 
Jean-Pierre Radley   Unix in NYC   jpr@jpr.com   jpradley!jpr   CIS: 72160.1341
Newsgroups: biz.sco.general