Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.mail.uucp
Subject: Re: UUCP on a Sun SLC
Message-ID: <7642@auspex.auspex.com>
Date: 6 May 91 23:10:22 GMT
References: <1991May4.012927.18106@pwcs.stpaul.gov>
Organization: Auspex Systems, Santa Clara
Lines: 21

>What it sounds like to me is that you are using 7 data bits instead of 8.
>Sun assumes 7 data bits even parity as default and UUCICO does not 
>automatically change to 8 data bits no parity when invoked.
>
>At first you might have only been sending ASCII text, and then you hit a 
>binary file which you then stall on.

If your UUCP stalls on a binary file because, when using the "g"
protocol, it's using 7 data bits even parity, you have a Mutant UUCP
from Hell - you don't have the SunOS-pre-4.1 UUCP, nor the 4.1-and-later
UUCP, nor any other UUCP I know about.

The "g" protocol, on any sane UUCP, puts the port into 8 bits, no parity
mode, forcibly.

Now, *before* the "g" protocol is started up, although the serial port
hardware *is* in 8-bits-no-parity mode, UUCP will glue on a parity bit
as specified by the P_ flag, with the default being even parity.  Having
the wrong parity for the site to which you're connecting can cause
problems when logging in; it can't disrupt the "g" protocol, though. 
P_ZERO tells it to glue a zero bit on.