Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!uw-beaver!mit-eddie!snorkelwacker.mit.edu!ai-lab!zurich.ai.mit.edu!ericf
From: ericf@zurich.ai.mit.edu (Eric Feigenson)
Newsgroups: comp.mail.uucp
Subject: UUCP on a Sparc SLC, SunOS 4.1
Message-ID: <ERICF.91Apr19222734@montreux.ai.mit.edu>
Date: 20 Apr 91 02:27:34 GMT
Sender: news@ai.mit.edu
Reply-To: ericf@zurich.ai.mit.edu
Distribution: comp
Organization: M.I.T. Artificial Intelligence Lab.
Lines: 27

This is deja vu... I've had a similar problem before, and it went away.  
It's back.

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