home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / dcom / modems / 19083 < prev    next >
Encoding:
Text File  |  1993-01-07  |  3.1 KB  |  72 lines
  1. Newsgroups: comp.dcom.modems
  2. From: fred@genesis.demon.co.uk (Lawrence Kirby)
  3. Path: sparky!uunet!pipex!demon!genesis.demon.co.uk!fred
  4. Subject: Re: RS-232 and DTR when system dies 
  5. Distribution: world
  6. References: <1993Jan6.211938.3214@chg.mcd.mot.com>
  7. Organization: BT
  8. X-Mailer: Simple NEWS 1.90 (ka9q DIS 1.19)
  9. Lines: 58
  10. Date: Thu, 7 Jan 1993 14:06:39 +0000
  11. Message-ID: <726415599snz@genesis.demon.co.uk>
  12. Sender: usenet@demon.co.uk
  13.  
  14. In article <1993Jan6.211938.3214@chg.mcd.mot.com> heiby@chg.mcd.mot.com writes:
  15.  
  16. >I have been having a philosophical discussion with one of my
  17. >colleagues, on the subject of the DTR line in the RS-232 standard.
  18. >I'm looking for information to help resolve the disagreement that has
  19. >emerged.
  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. >
  25.  
  26. You must be careful not to confuse this with flow control. Serial printers
  27. confuse the issue by essentially using DTR for flow control.
  28.  
  29. >The exact situation in question is what should be done with DTR on
  30. >serial ports coming from a UNIX based computer system that has either
  31. >locked up or panic'd.
  32. >
  33. >In my opinion, this circumstance is such that the DTE (the UNIX
  34. >computer system) is *not* ready to exchange data, so the DTR line
  35. >should not be true.  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. >
  41.  
  42. You're looking at a system in a crash condition so the results are simply not
  43. well defined - you can't tell or guarantee what will happen. However a panic'd
  44. system goes through some sort of shutdown procedure which, if it thinks it is
  45. safe to do so, might usefully drop DTR on all serial ports.
  46.  
  47. >I'm looking for opinion as to what the *right* thing to do is and how
  48. >important it is to do the *right* thing.  I'm also looking for actual
  49. >data regarding computer systems from various vendors, and their
  50. >treatment of DTR in such a situation.
  51. >
  52.  
  53. If the only process on a port aborts the port will be closed and DTR dropped.
  54. If the serial driver locks there's nothing you can do as you've completely
  55. lost control of the port. If the kernel crashes you've lost control of the
  56. entire system. What situations would your question be relavent to? How would
  57. you detect a dead computer?
  58.  
  59. Don't worry too much about what vendors are doing - there is a general
  60. tendancy to mess up the serial port!
  61.  
  62. Don't worry too much about adhering to every last letter of the spec. either.
  63. Do what serves the user best. If you can prevent the user being charged for
  64. a connection to a dead system then do so. Your question should be whether
  65. dropping DTR under the conditions you cite would break anything. I don't think
  66. so! Does it add anything? Yes! Is it implementable? Probably not!
  67.  
  68. -----------------------------------------
  69. Lawrence Kirby | fred@genesis.demon.co.uk
  70. Wilts, England | 70734.126@compuserve.com
  71. -----------------------------------------
  72.