home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / modems / 11086 < prev    next >
Encoding:
Text File  |  1992-07-23  |  2.5 KB  |  55 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!ux1.cso.uiuc.edu!uchinews!machine!chinet!les
  3. From: les@chinet.chi.il.us (Leslie Mikesell)
  4. Subject: Re: Boom! You're Dead.
  5. Message-ID: <1992Jul24.031631.26450@chinet.chi.il.us>
  6. Date: Fri, 24 Jul 1992 03:16:31 GMT
  7. References: <2043@tymix.tymnet.com> <1992Jul18.142320.4269@qiclab.scn>
  8. Organization: Chinet - Public Access UNIX
  9. Lines: 44
  10.  
  11. In article <1992Jul18.142320.4269@qiclab.scn> leonard@qiclab.scn.rain.com writes:
  12. >tnixon@hayes.com writes:
  13. >>Of course, this means that there is 
  14. >>a fixed probability that your modem will inadvertently escape when
  15. >>you're transmitting random data (such as a compressed file) or any
  16. >>file that happens to mention the given character sequence
  17.  
  18. Adding the guard time lowers the probability but doesn't eliminate
  19. it.   And, as many of us have experienced, when using such modems
  20. on the host side of a connection, they will drop in response to
  21. the echoed characters regardless of the time delay so it doesn't
  22. help a bit there.
  23.  
  24. >Well, aside from the bit about "Hayes Improved Escape Sequence" with 
  25. >"Guard Time" as a description for a feature that is over a decade old,
  26. >it *does* sound like somebody was asleep at the switch.
  27.  
  28. Yes, maybe back in 1980 someone actually had a reason to put the
  29. modem in command mode in the middle of a connection.  Maybe they
  30. were using software that didn't offer the ability to drop DTR.
  31.  
  32. >They actually *don't check* for anything but the tripled character?
  33. >*Unbelievable*! 
  34. >
  35. >BTW, you seem to imply that the makers of these brain-dead modems are
  36. >actually pushing this bug as a *feature*? Is that true?
  37.  
  38. It would be a feature for a modem to have *no* default in-band escape
  39. to command mode these days (actually it would have always been better
  40. that way).  On the rare occasions when you felt the urge to be able
  41. to spuriously interrupt your communications (perhaps you are debugging
  42. and want to query the registers) you could always send the enabling
  43. command explicitly before dialing.  It's hard to believe that no one
  44. has gone this route as the simple solution.
  45.  
  46. Now that that's settled, does anyone want to talk about modems that
  47. refuse to stop dialing once they've started even though you drop DTR?
  48. (This is with &D3 set - they drop a completed connection on DTR loss).
  49. And then they insist on sending back the result code, even though
  50. the program that was trying to dial has given up and gone away.  Does
  51. anyone have a list of modems that don't act this way?
  52.  
  53. Les Mikesell
  54.   les@chinet.chi.il.us
  55.