home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.dcom.modems
- Path: sparky!uunet!psgrain!qiclab!leonard
- From: leonard@qiclab.scn.rain.com (Leonard Erickson)
- Subject: Re: Procomm 2.01 strip 8th bit (How TO)
- Message-ID: <1992Aug14.225002.8341@qiclab.scn.rain.com>
- Reply-To: 70465.203@compuserve.com
- Organization: SCN Research/Qic Laboratories of Tigard, Oregon.
- References: <l889h4INN8ak@aludra.usc.edu> <1992Aug10.063634.8667@huracan.cr> <1992Aug11.044425.21444@qiclab.scn.rain.com> <1992Aug14.023851.24942@usenet.ins.cwru.edu>
- Distribution: usa
- Date: Fri, 14 Aug 1992 22:50:02 GMT
- Lines: 26
-
- wb8foz@skybridge.SCL.CWRU.Edu (David Lesher) writes:
-
- >Others said
- ># >For Procomm: set up the "translate table" such that the upper 128 bytes are
- ># >just like the lower 128 bytes, and turn "translate table _on_". Then, keep
- ># >it set to 8-bits/no-parity and you'll be set.
-
-
- >I've been trying to follow this thread and I admit I'm getting
- >confused..
-
- >If you are working over a 7 bit-wide path, and the protocol needs 8,
- >what good does it do to play with a translate table? Can it magically
- >guess what the 8th bit [if there WAS one] would be?
-
- No, the path is 8-bits. It's just that some Unix systems will cheerfully
- send text to you as 7-E-1 even though you are connected at 8-N-1. Data
- transfers at 8-N-1 work fine. You just can't read the #$%%^ screen
- prompts without stripping the 8th bit!
-
- I have to deal with that on the system I'm entering this on.
- --
- Leonard Erickson leonard@qiclab.scn.rain.com
- CIS: [70465,203] 70465.203@compuserve.com
- FIDO: 1:105/51 Leonard.Erickson@f51.n105.z1.fidonet.org
- (The CIS & Fido addresses are preferred)
-