home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zephyr.ens.tek.com!psgrain!qiclab!leonard
- From: leonard@qiclab.scn.rain.com (Leonard Erickson)
- Newsgroups: comp.dcom.modems
- Subject: Re: Boom! Our lawyers are tougher than your lawyers. You're Dead.
- Message-ID: <1992Jul23.183052.1972@qiclab.scn.rain.com>
- Date: 23 Jul 92 18:30:52 GMT
- References: <1992Jul17.035105.6535@ddsw1.mcs.com> <BrsyEw.Dst@wsrcc.com> <nktpnuk@rhyolite.wpd.sgi.com>
- Reply-To: 70465.203@compuserve.com
- Organization: SCN Research/Qic Laboratories of Tigard, Oregon.
- Lines: 26
-
- vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
-
- >In article <BrsyEw.Dst@wsrcc.com>, wolfgang@wsrcc.com (Wolfgang S. Rupprecht) writes:
- >>
- >> This has nothing to do with "good modem manufacturers". Anyone
- >> relying on "<pause>+++<pause>" not occurring during a data transfer is
- >> not writing good defensive code. Good programmers don't *hope* that a
- >> certain set of characters and delays never happens. They turn off the
- >> inband +++ escape kludge and use a good *out-of-band* escape.
-
- After perusing my manual, I see *two* "possible" out-of-band signals
- for dropping into command mode. The first is dropping DTR. But I need
- that to drop the *connection* as well as enter command mode.
-
- That leaves sending a "true break". Alas, I need that to get the attention
- the very machine I'm entering this message from! (I've had times when it
- was not possible to get it to pick the right port rate without hitting
- it with a break).
-
- So now what?
-
- --
- Leonard Erickson leonard@qiclab.scn.rain.com
- CIS: [70465,203] 70465.203@compuserve.com
- FIDO: 1:105/56 Leonard.Erickson@f56.n105.z1.fidonet.org
- (The CIS address is checked daily. The others infrequently)
-