Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!lll-winken!iggy.GW.Vitalink.COM!widener!msi.umn.edu!cs.umn.edu!kksys!pwcs!deans
From: deans@stpaul.gov (Dean R Schrimpf)
Newsgroups: comp.mail.uucp
Subject: RE:UUCP on a Sun SLC
Message-ID: <1991May4.012927.18106@pwcs.stpaul.gov>
Date: 4 May 91 01:29:27 GMT
Sender: deans@pwcs.stpaul.gov (Dean R Schrimpf)
Organization: City of St. Paul Public Works
Lines: 61

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
.