Xref: utzoo comp.unix.xenix:2325 comp.mail.uucp:1326 comp.unix.questions:7225
Path: utzoo!attcan!uunet!husc6!bbn!uwmcsd1!ig!agate!ucbvax!ucsd!ucsdhub!jack!elgar!ag
From: ag@elgar.UUCP (Keith Gabryelski)
Newsgroups: comp.unix.xenix,comp.mail.uucp,comp.unix.questions
Subject: Re: UUCP on SCO Xenix '386 2.2.2 (bad boy)
Keywords: Why doesn't DIALOUT go away?
Message-ID: <154@elgar.UUCP>
Date: 24 May 88 17:23:51 GMT
References: <260@mjbtn.UUCP>
Reply-To: ag@elgar.UUCP (Keith Gabryelski)
Followup-To: comp.unix.xenix
Organization: Elgar Corporation, San Diego, CA
Lines: 107
Fear: That this post will be as wrong as my last post.

In article <260@mjbtn.UUCP> root@mjbtn.UUCP (Mark J. Bailey) writes:
>...[explaination of ports not getting reset]...
>
>My question is, has anybody else experienced these odd behaviors, and if so
>what have you done to work around or fix it.

Yes.  See below.

>ALso, is UNGETTY really a 
>trustworthy program that I can sit back and forget about.

From dial(M):

	"If the specified line has been configured as a
	dial-in/dial-out line, dial invokes ungetty(M) to suspend the
	getty, makeing it a dial-out line.  When the dial-out session
	is finished, dial should be called with the `-h' option to
	restore the dial-in line.  (See ungetty(M).)  If uucp or cu
	abort abnormally, the line will still be enabled for dial out.
	Use `who -a' to check the line status.  If the serial line is
	still in a dial-out state, use `ungetty -r' to restore the
	dial-in line."

I was given this advice when I queried a long-time SCO user.

[From: Greg Laskin; Tue, 15 Mar 88 <8803152033.AA13831@gryphon.CTS.COM>]
 From Keith Gabryeslki, private mail to greg@gryphon
 >Hmmmm...  This seems to be the problem, but LOGFILE does not record
 >any errors that may occured during the uucico invocation.  Curious!
 >
 >In any case, I can not consistently recreate the problem, so I am
 >unsure on execatly why uucico aborts.
 >
 >Have you a clue?

 No.  Ask:  who were you talking to at the time.  Is there a 
 conversation complete in LOGFILE.  Is there a core file in
 /usr/spool/uucp.  Did you have any traffic for the site.
 Did they have any traffic for you.  Was the traffic delivered.

 I've seen uucico core dump in 2.1.3 under some circumstances (remote
 requests file transfer after calling system had no traffic).  I've
 never played with 2.2 uucp and ungetty.

 Try making more stack space for uucico -
 fixhdr -F 4000 uucico

 that's been know to help in earlier versions.

The above didn't seem to help my problem too much.  It may help you.
I offer this shell script.  I run it in cron under the account uucpadm
every so often to fix any gettys that may be hosed.  It is brute
force, but until the problem is fixed, it is satisfactory.  The code
does keep a log in /usr/spool/uucp/FIXLOG of all gettys that had to be
reset.

Also, I've only seen this problem on the Anchor 2400E's that we have
here, not of the USRobotics.  There is probably an incompatibility
that I haven't been able to detect with dialHA24???  Me thinks it
doesn't drop disconnect when it should.  But that is unfounded
assumption.

:
#
# Fix a hung getty.
#
# 3,18,33,48 * * * *	/usr/lib/uucp/fixgetty       >/dev/null 2>&1
#

DIALOUTS=`who -a | grep DIALOUT | awk '{ print $2 }'`

for i in $DIALOUTS
do
    if test ! -f /usr/spool/uucp/LCK..$i
    then
	echo "`date` DIALOUT $i" >> /usr/spool/uucp/FIXLOG
	/usr/lib/uucp/ungetty -r $i
    fi
done

#
# End of script
#

>I should I try a bi-directional getty like uutty, or maybe some other
>alternative.  Why isn't there a UUGETTY for it already?

As far as I know, SCO Xenix will not run any getty except for
/etc/getty.  The field in /etc/inittab that specifies the getty to run
is ignored.  Hopefully this will be fixed in 2.3.

>I had uucp working like a dream on the 6000 Xenix, but I am very concerned
>about SCO uucp.  It even will try and use the port (the dialer) when I am
>logged in via a remote terminal and a modem.  I understood from the dialer
>code that that isn't supposed to happen either.

Not sure what is happening here.  Maybe you could elaborate?  Dial
should try to use the line only if the port is marked as LOGIN.  What
port are you logging in on?  What port does the lockfile get made for
in /usr/spool/uucp when dial runs?  What happens on your screen when
dial grabs your line?

(I really) hope this helps.
--Keith
-- 
[  Keith   ]  UUCP: {ucsd, cbosgd!crash, sdcsvax!crash, nosc!crash}!elgar!ag
[Gabryelski]  INET: ag@elgar.cts.com              ARPA: elgar!ag@ucsd.arpa