home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!math.fu-berlin.de!unidui!flyer!flatlin!smurf.sub.org!news
- From: urlichs@smurf.sub.org (Matthias Urlichs)
- Newsgroups: comp.dcom.modems
- Subject: Re: RS-232 and DTR when system dies
- Date: 22 Jan 1993 17:37:48 +0100
- Organization: University of Karlsruhe, FRG
- Lines: 29
- Message-ID: <1jp7ssINN52g@smurf.sub.org>
- References: <1993Jan6.211938.3214@chg.mcd.mot.com> <3402@bsu-cs.bsu.edu>
-
- In comp.dcom.modems, article <3402@bsu-cs.bsu.edu>,
- sam@bsu-cs.bsu.edu (B. Samuel Blanchard) writes:
- > In article <1993Jan6.211938.3214@chg.mcd.mot.com> heiby@chg.mcd.mot.com (Ron Heiby) writes:
- >
- > >The exact situation in question is what should be done with DTR on
- > >serial ports coming from a UNIX based computer system that has either
- > >locked up or panic'd.
- > This is partly academic: a panic'd system is responsible to only one god.
- > I hope the design specifies system integrity followed by some sort of
- > reasonable attempt to restart services (at owner's option).
- >
- > A locked system may not be capable of communicating data or signals.
- >
- Therefore, the job defaults to the modem.
-
- IMHO, a good modem should have the following option: If the remote system
- disconnects, assume that DTR is low (which usually implies not answering the
- phone) until DTR _really_ goes down, or until an AT command is sent.
-
- This would mean that a panic'ed system would answer at most one phone call
- per modem. That's not a perfect solution, but it's simple and it works.
-
- --
- A likely impossibility is always preferable to an unconvincing possibility
-
- -- Aristotle
- --
- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
- Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany -- +49-721-9612521 \o)/
-