Article View: comp.std.misc
Article #198Re: RS-232 and DTR when system dies
From: B. Samuel Blanchard
Date: Thu, 07 Jan 1993 14:51
Date: Thu, 07 Jan 1993 14:51
68 lines
3641 bytes
3641 bytes
PLEASE NOTE FOLLOWUP-TO comp.dcom.modems ( I recommend this to others replying
from comp.std.misc )
In article <1993Jan6.211938.3214@chg.mcd.mot.com> heiby@chg.mcd.mot.com (Ron Heiby) writes:
>I have been having a philosophical discussion [..] DTR line in the RS-232 [..]
I will provide my scheme and reasoning. I use only layman's practical philosophy
>My interpretation of RS-232 is that the DTR line should be asserted
>*only* when the DTE is ready to exchange data. My colleague believes
>that that is an over-strict interpretation.
Only when the device is willing to try :-)
>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.
>[..]My colleague believes that it is not important
>that the modems attached to the dead computer continue to answer
>incoming calls, and that since previous versions of the system
>software have behaved in exactly the same way for half a dozen years
>or more, that it's no big deal either way.
$$$$$$ how much does it "cost"
and
:-) who does it cause problems for
Here goes my scheme:
disclaimer: this is about how I do things at my company and may not apply
to the very real world in which you live.
Modems should not answer the phone if the system in unavailable because:
+ it may cost someone money without "stimulating the economy"
+ more information is available by having more modem states.
- busy, answer with no login, does not answer, works great, etc.
- no answer is not a "common" state in your colleagues arrangment
+ it fits well with the rest of my scheme for maintaining systems and modems.
And other relevent items in brief:
+ modems should drop DCD (and sometimes DSR/DTR) when connection closes.
- remote connection lost
- software can determine if it wants to maintain system - modem connection
- automated software can handle/record event.
- local (system) connection lost.
- always hang up when system connection is lost
- security
- phone costs
===>> - most systems drop all signals via RS232 as part of system reset.
- reboot
- panic
- ;-) power out
+ modems should default to local standard.
+ modems should always resort to last saved settings (local std) between use.
+ the administrator is the one who deals with the problems.
- a complex (read my favorite) solution must be setup and maintainted.
- a simple (yesterdays standard) solution is harder to maintain over time.
- a complicated solution is the worst of both worlds. :-)
>Ron Heiby, heiby@chg.mcd.mot.com Moderator: comp.newprod
--
B. Sam Blanchard sam@bsu-cs.bsu.edu
418 Winfield Dr (317) 284-7131 work
Greenfield, IN 46140
Technical Details
Message-ID:
<3402@bsu-cs.bsu.edu>Path:
arc1-ca.pugleaf.net!sparky!uunet!wupost!spool.mu.edu!news.nd.edu!bsu-cs!samReferences:
<1993Jan6.211938.3214@chg.mcd.mot.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!wupost!spool.mu.edu!news.nd.edu!bsu-cs!sam From: sam@bsu-cs.bsu.edu (B. Samuel Blanchard) Newsgroups: comp.std.misc,comp.dcom.modems Subject: Re: RS-232 and DTR when system dies Summary: cost benefit BS from one administration view Message-ID: <3402@bsu-cs.bsu.edu> Date: 7 Jan 93 14:51:50 GMT References: <1993Jan6.211938.3214@chg.mcd.mot.com> Followup-To: comp.dcom.modems Organization: Staring *NIX Users' Group in Indiana, ask for info! Lines: 68