Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!wuarchive!rice!uw-beaver!milton!ogicse!intelhf!ichips!inews!iwarp.intel.com!gargoyle!chinet!rmtodd
From: rmtodd@chinet.chi.il.us (Richard Todd)
Newsgroups: news.software.b
Subject: Re: C news problem:  spacefor script
Message-ID: <1991Mar12.031806.19021@chinet.chi.il.us>
Date: 12 Mar 91 03:18:06 GMT
References: <1991Mar10.204709.10460@panix.uucp> <1991Mar11.180913.29468@zoo.toronto.edu> <1991Mar11.190920.3655@casbah.acns.nwu.edu>
Organization: Chinet - Chicago Public Access UNIX
Lines: 48

In article <1991Mar11.190920.3655@casbah.acns.nwu.edu> phil@eecs.nwu.edu (William LeFebvre) writes:
>In article <1991Mar11.180913.29468@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes:
>|> In article <1991Mar10.204709.10460@panix.uucp> alexis@panix.uucp (Alexis Rosen) writes:
>|> >Henry Spencer suggests, in a followup message, that some old uuxqt's were
>|> >sloppy about closing files. This is the case with A/UX, and (after months
>|> >of headscratching) when I finally came up with a workaround, Richard Todd
>|> >mentioned in a followup posting that MultiMaxes had this problem too.

I did?  I don't recall saying any such thing.  I did mention that I had heard
of other systems that had the infamous uuxqt bug, but I don't really know if 
Encore is one of them, for reasons explained below:

>|> My stars.  I'd thought that bug had been eradicated long ago; I mentioned
>|> it just on the off chance.
Alas, at least on one moderately recent system (A/UX 2.0, SVR2), it's still
alive and thriving.  Thanks to Alexis and I yelling about it, I think it 
won't be in 2.0.1, though...

>Well, just to make matters more confusing, my predecessor installed
>and used a different uucp than the one Encore distributes.  I am not
>positive, but I think that it came from the 4.3 BSD source tapes.  I
>never had the courage to switch back to Encore's version, because I
>didn't (and still don't) know what subtle changes he made to make it
>all work, and I didn't want to risk breaking everything.  I'll look
>at what I believe are the sources for what we are running and see if
>I can find the problem there.  Thanks for the tips.

The plot thickens.  You see, the Multimax I know the most about, uokmax.ecn.
uoknor.edu, doesn't run Encore UUCP either.  It runs a UUCP off of the 
4.3 BSD tapes.  And, interestingly enough, I don't think it has the "uuxqt bug";
I'm pretty sure I've seen its uuxqt go thru 20-30 jobs at a time without 
problem, and I don't recall that Encore has an unusually large # of 
file descriptors per process.  Interesting, no?  

Now, I'm not certain that it was indeed a 4.3BSD tape that it came off of;
it might be a Mt Xinu 4.3/NFS tape instead, and it's entirely possible that
someone years ago hacked on this code at OU ECN and stomped on this bug.  And,
alas, I can't get anyone to check on it right now because uokmax is down for
disk repartitioning over Spring Break....

BTW, if I remember correctly, you *don't* really want to go back to the 
Encore UUCP.  It had all sorts of reliability problems last time they tried it
at ECN, notably uucico hanging in midtransfer for no obvious reason.  Also,
they found it startling that a UUCP shipped on a system purporting to be 
BSD 4.3-tahoe didn't seem to know about the D., X., C., etc subdirectories of
/usr/spool/uucp....
--
Richard Todd   rmtodd@chinet.chi.il.us   rmtodd@servalan.UUCP