Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!hao!ames!oliveb!pyramid!csg
From: csg@pyramid.UUCP (Carl S. Gutekunst)
Newsgroups: comp.dcom.modems
Subject: Re: Answering modems should need no commands! // 2400 answer is fragile
Message-ID: <2467@pyramid.UUCP>
Date: Sun, 24-May-87 02:18:54 EDT
Article-I.D.: pyramid.2467
Posted: Sun May 24 02:18:54 1987
Date-Received: Sun, 24-May-87 08:48:56 EDT
References: <2130@hoptoad.uucp> <913@runx.ips.oz>
Reply-To: csg@pyramid.UUCP (Carl S. Gutekunst)
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 16

In article <913@runx.ips.oz> dave@runx.ips.oz (Dave Horsfall) writes:
>Then again, I get annoyed when making several expensive phone calls to
>remote machines, hearing the answer tone, then zilch.  If the machine
>has crashed or is turned off, the modem doesn't know this, and quite
>happily answers the phone for you.

That is what DTR is for. If the machine dies (particularly if it loses power)
the DTR signal to the modem should fall, and the modem will not answer calls.

Installations that botch DTR are widespread, either becuase the serial port is
too limited, the software is weak, the cable was built incorrectly (using only
pins 2, 3, and 7 is not enough for a modem), or the modem is misconfigured. Of
course, it is much easier to fix the installation to handle DTR correctly than
it is to modify the login routine to interact with the modem.

<mplr