Speed codes in SCO gettydefs (was: FAS and Open Desktop)

[Greg Andrews]

In article <339 at n4hgf.Mt-Park.GA.US> wht at n4hgf.Mt-Park.GA.US 
(Warren Tucker) writes:
>
>> [original complaint about uugetty dropping DTR when a caller
>>  connects deleted]
>
>Your actual point is puzzling (I cannot recreate it).  DTR is
>only dropped when the line has been closed by all processes or
>*any* process issues a TCSETA ioctl with the CBAUD part of a
>termio c_flag to zero (B0).  It sounds like your getty is going
>away on DCD or setting B0 (gettydefs problem?).
>
> [Warren's sample gettydefs entries deleted]
>
>Improper coding of the 2nd stty line could cause you trouble.
>Note  'B19200' is not recognized by the standard ATT getty code.
>Using it in lieu of EXTA will result in B0, causing DTR to go away.
>

I don't know about the AT&T code, but I've seen this in SCO Unix 
v3.2.0 when uugetty encounters a speed code of B19200 in gettydefs.
Just as you said, uugetty sets B0, which drops DTR on the caller.  
Uugetty isn't going away, it's just dropping DTR (confirmed by 
telling the modem to ignore DTR and monitoring the uugetty's PID).
/etc/getty has no trouble with B19200 and sends out a login prompt 
without complaint.  When I changed the speed code to EXTA both 
/etc/getty and uugetty were happy.

I haven't been able to check this with any later versions of the
operating system, but a couple of folks I've talked with said their
uugetty had no trouble with B19200.

-- 
.-------------------------------------------.
| Greg Andrews      |   gandrews at netcom.COM |
`-------------------------------------------'