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
Date: 7 Jan 93 14:51:50 GMT
Followup-To: comp.dcom.modems
Organization: Staring *NIX Users' Group in Indiana, ask for info!

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