Xref: utzoo comp.sys.pyramid:224 comp.dcom.modems:2379
Path: utzoo!lsuc!hcr!ncrcan!brian
From: brian@ncrcan.UUCP
Newsgroups: comp.sys.pyramid,comp.dcom.modems
Subject: Re: Solution to Problems with UUCP/modems.
Message-ID: <899@ncrcan.Toronto.NCR.COM>
Date: Sat, 3-Sep-88 01:40:37 GMT
Article-I.D.: ncrcan.899
References: <14170@comp.vuw.ac.nz>
Reply-To: brian@ncrcan.Toronto.NCR.COM (Brian Onn)
Organization: NCR Canada Ltd., Mississauga, Ontario
Lines: 26

In article <14170@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes:
> [stuff deleted]
>The (old) Quattro manual I have does not document this "feature" [modem
>changing parity of the received data] , but I have
>spoken to one of the distributors engineers who says his manual does.  As a
>small consolation for all the time I spent trying to track the problem down, he
>is sending me a copy of the updated manual!  But he also claims the Quattro is
>behaving perfectly reasonably.  Is he right?  How many other modems behave like
>this?

No! He is not right.  No sane modem should mess with the data stream.  It's
purpose is to get the data across a communications channel *unchanged*.  If
I am on side A and send data at even parity I expect it to be received at the
other side also with even parity, not at the last parity that was used when
sending to the (broken) modem.  This is no feature, it is a bug!

No other modems I know of due this.  There may be some that allow this to
be configured (someone may want it), but it should not be forced upon you
because some designer thought that that's the way it should be done.

Brian.
-- 
 +-------------------+--------------------------------------------------------+
 | Brian Onn         | UUCP:..!{uunet!mnetor, watmath!utai}!lsuc!ncrcan!brian |
 | NCR Canada Ltd.   | INTERNET: Brian.Onn@Toronto.NCR.COM                    |
 +-------------------+--------------------------------------------------------+