home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / misc / 168 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  3.5 KB
  1. Xref: sparky comp.std.misc:168 comp.dcom.modems:19074
  2. Path: sparky!uunet!wupost!spool.mu.edu!news.nd.edu!bsu-cs!sam
  3. From: sam@bsu-cs.bsu.edu (B. Samuel Blanchard)
  4. Newsgroups: comp.std.misc,comp.dcom.modems
  5. Subject: Re: RS-232 and DTR when system dies
  6. Summary: cost benefit BS from one administration view
  7. Message-ID: <3402@bsu-cs.bsu.edu>
  8. Date: 7 Jan 93 14:51:50 GMT
  9. References: <1993Jan6.211938.3214@chg.mcd.mot.com>
  10. Followup-To: comp.dcom.modems
  11. Organization: Staring *NIX Users' Group in Indiana, ask for info!
  12. Lines: 68
  13.  
  14. PLEASE NOTE FOLLOWUP-TO comp.dcom.modems ( I recommend this to others replying
  15. from comp.std.misc )
  16.  
  17. In article <1993Jan6.211938.3214@chg.mcd.mot.com> heiby@chg.mcd.mot.com (Ron Heiby) writes:
  18. >I have been having a philosophical discussion [..] DTR line in the RS-232 [..]
  19. I will provide my scheme and reasoning. I use only layman's practical philosophy
  20.  
  21. >My interpretation of RS-232 is that the DTR line should be asserted
  22. >*only* when the DTE is ready to exchange data.  My colleague believes
  23. >that that is an over-strict interpretation.
  24. Only when the device is willing to try :-)
  25.  
  26. >The exact situation in question is what should be done with DTR on
  27. >serial ports coming from a UNIX based computer system that has either
  28. >locked up or panic'd.
  29. This is partly academic: a panic'd system is responsible to only one god.
  30. I hope the design specifies system integrity followed by some sort of reasonable
  31. attempt to restart services (at owner's option).
  32.  
  33. A locked system may not be capable of communicating data or signals.
  34.  
  35. >[..]My colleague believes that it is not important
  36. >that the modems attached to the dead computer continue to answer
  37. >incoming calls, and that since previous versions of the system
  38. >software have behaved in exactly the same way for half a dozen years
  39. >or more, that it's no big deal either way.
  40.  $$$$$$  how much does it "cost"
  41.    and
  42.   :-)    who does it cause problems for
  43.  
  44.  
  45. Here goes my scheme:
  46.   disclaimer: this is about how I do things at my company and may not apply
  47.               to the very real world in which you live.
  48.  
  49. Modems should not answer the phone if the system in unavailable because:
  50.   + it may cost someone money without "stimulating the economy"
  51.   + more information is available by having more modem states.
  52.      - busy, answer with no login, does not answer, works great, etc.
  53.      - no answer is not a "common" state in your colleagues arrangment
  54.   + it fits well with the rest of my scheme for maintaining systems and modems.
  55.  
  56. And other relevent items in brief:
  57.   + modems should drop DCD (and sometimes DSR/DTR) when connection closes.
  58.     - remote connection lost
  59.       - software can determine if it wants to maintain system - modem connection
  60.       - automated software can handle/record event.
  61.     - local (system) connection lost.
  62.       - always hang up when system connection is lost
  63.         - security
  64.         - phone costs
  65. ===>>   - most systems drop all signals via RS232 as part of system reset.
  66.         - reboot
  67.         - panic
  68.         - ;-) power out
  69.   + modems should default to local standard.
  70.   + modems should always resort to last saved settings (local std) between use.
  71.   + the administrator is the one who deals with the problems.
  72.     - a complex (read my favorite) solution must be setup and maintainted.
  73.     - a simple (yesterdays standard) solution is harder to maintain over time.
  74.     - a complicated solution is the worst of both worlds.  :-)
  75.  
  76. >Ron Heiby, heiby@chg.mcd.mot.com    Moderator: comp.newprod
  77.  
  78. -- 
  79. B. Sam Blanchard        sam@bsu-cs.bsu.edu
  80. 418 Winfield Dr         (317) 284-7131   work
  81. Greenfield, IN 46140
  82.