deans@stpaul.gov (Dean R Schrimpf) (05/04/91)
From: deans@stpaul.gov (Dean R Schrimpf) Newsgroups: Comp.mail.uucp Subject: Re:UUCP on a Sun SLC Organization: City of St. Paul Public Works >My first UUCP connection using this new setup (Sun Sparc SLC, SunOS >4.1) went smooth as silk. Lots of files were transferred. All was >well in the land. The *next* time, and all subsequent times, I get >connected, the log shows that it's starting a transfer (from the >remote to my site), and I immediately get "alarm n" messages until the >converstaion fails. I can send more detailed log info for anyone who >thinks they can help. The modem (if it matters) is a Telebit T1000. >Everything worked fine (as far as UUCP went) on a '386 box running >various flavors or Unix. I anyone has *any* insight into this >problem, or think they would if I gave them more info, please E-mail a >response. > >While I'm at it... does anyone know why the serial port (/dev/ttya) on >the Sparc should want to hang (*completely*) so that I have to reboot >to get it back? When it gets in this state UUCP and tip can't touch >it ("all devices busy") and stty < or > to/from it hang and I have to >kill it with a QUIT signal. Any info on this, too, would be >appreciated. > >Thanks much! > >-EricF >ericf@zurich.ai.mit.edu We have had similar problems with or Sun SLC running SunOS 4.1.1. 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. We discovered two ways to solve this problem. First, in your Dialers file add two things put a "" P_ZERO "" in the front of your dialer script and at the end of your script put STTY=raw. This will put UUCICO in 8 data bits no parity, along with some other setup information that you can read about in your Administration manual. Also, I found that even though you set STTY=raw which does set no parity if the other site is activly checking for no parity this will not completely solve the initial handshake problem, which P_ZERO does, and it does not definitely hurt. Secondly, you can change your default configuration for 8 data bits no parity, of the top of my head you need to put ap in place of something 7. But I would not go all the way to STTY=raw, because this affects everthing that might be connected to your SLC, I found out the hard way with a WYSE terminal, becuase raw has no handshaking. Hope I could be of some help. Let me know if this solves your problem. Dean Schrimpf deans@pwcs.stpaul.gov .
guy@auspex.auspex.com (Guy Harris) (05/07/91)
>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.