🚀 go-pugleaf

In article <5821@fortune.UUCP> mats@fortune.UUCP (PUT YOUR NAME HERE) writes:
>
>Oh, boy, this is fun. Now I get to flame at cheap modems again.
...
>Well. modems have the characteristic of only supplying a ready
>signal to the outside world when a connection is established.
...
>Well, the modem makers tie the signal permanently high so they
>can guarantee the terminal can always talk to the modem's
>ROM and make it dial.
>
>Of course, once you have done this, you have broken the modem
>as far as auto-answer...

The problem is not primarily with the modem manufacturer's use
of the Carrier Detect lead (pin 8), but with stupid comm port
hardware/software that uses only Carrier Detect to determine the
status of a call.  Most UNIX systems are guilty of this.  An incomming
call should be detected with the Ring Indicate lead (pin 22) and
answered by asserting Data Terminal Ready (pin 20).  Calls should be
terminated or aborted by dropping the DTR.  None of this has anything
to do with whether or not you can send to/receive from the modem's
dialer.  Permission to send is controlled by Clear to Send (pin 5) and
presence of valid receive data is gated by Carrier Detect or (in some
cases) Data Set Ready (pin 6).

Some of the modem people have tried to help these brain-damaged
systems by providing non-standard operation (usually switch
selectable).  For example, the UDS 212A/D has a switch that determines
the state of the CD lead when the terminal/system is talking to the
dialer as opposed to a remote system.  The simple case is forcing
some leads high as mats@fortune.UUCP (PUT YOUR NAME HERE) mentioned.

A better solution would be to fix the communications software to make
use of the information it has available to it.  (No extra charge
super-flame follows)  While they are at it they can fix UNIX's so no
crummy kludges are necessary to get getty et. al. out of the way on
ports you would like to use for both originating and recieving UUCP
calls.

	-crl

The usual generic disclamers go here.