Path: utzoo!mnetor!motto!ecijmm!robohack!woods
From: woods@robohack.UUCP
Newsgroups: news.software.b
Subject: Re: C News, 386/ix, assorted questions/experiences
Summary: some of the same for AT&T 3B2 with SysVr3.1 & CPLU 4.1
Message-ID: <1989Aug14.134542.12546@robohack.uucp>
Date: 14 Aug 89 13:45:42 GMT
References: <1989Aug13.161806.15829@jdyx.UUCP> <1989Aug14.040740.3151@utstat.uucp>
Reply-To: woods@robohack.UUCP (Greg A. Woods)
Distribution: na
Organization: R. H. Lathwell Associates: Elegant Communications, Inc.
Lines: 54

In article <1989Aug14.040740.3151@utstat.uucp> geoff@utstat.uucp (Geoff Collyer) writes:
> Tom Friedel:
> >I am running 386/ix.  The libstdio code fails only in one case,
> >and that is when stdiock.fast -i -u is sent to stdout.  I get the
> >message that _cnt is not compatible.  Why, and will this be a problem.
>
> We don't know why your vendor has changed the meaning of _cnt, but it
> doesn't matter; if you get any stdiock failure, you have to use your
> vendor's stdio.  We hope that if they diddled the semantics of _cnt or
> _ptr that they have also tuned the guts, but we can't promise.

Just as a side note in this conversation:  I am running beta C News on
ISC 386/ix 1.0.6 with the 1.0.5 compiler and Jun23 C News on a 3B2
with SysVr3.1 and CPLU 4.1.  I have not done the stdio tests on the
386, but when I did them on the 3B2, I had the same result as Tom.

However, since I'd already been running with the libstdio code in both
places for >2 weeks on the 3B2, and >6 months on the 386, I've
continued to use it.

The only odd, un-explicable thing that has happened was an article
being tossed into the errlog because relaynews thought it was out of
sync (with "relaynews out of sync, tossing:" messages).  Since this
happened on both machines, I though it might have been a bad batch,
though I never got a chance to examine the batch.

[Geoff:]
> [Tom:]
> >When I first tried to build C News with dbz, I got a segmentation fault
> >in dbz hash(). I rebuilt with dbm and all was OK.  I am guessing that
> >i needed to do a mkhistory before posting to the newly created C News
> >with dbz, but have not confirmed this theory.  
> 
> Since dbm and dbz use completely different file formats, you have to
> pick one and use it consistently everywhere.  The core dump in dbz is
> one reason that we have been a bit slow to pick it up and endorse it,
> though some time we hope to have an improved dbz which we will endorse.

I use dbz on both machines, and have definite evidence of other
successes.  Someone should sdb or dbx the sucker!  I can't (yet),
'cause I've not had the core dump.  :-)

I did accidentally run the fake dbm here on the 3B2 ('cause I forgot
that the build stuff didn't recommend it), and it ran fine too, (but
slow).

The one thing I was impressed with was watching mkhistory work on a
system with ~50 Kb news in the spool, and using the fake dbm (it was a
25(? fast anyway) MHz AT&T 6386).
-- 
						Greg A. Woods

woods@{robohack,gate,tmsoft,ontmoh,utgpu,gpu.utcs.Toronto.EDU,utorgpu.BITNET}
+1-416-443-1734 [h]	+1-416-595-5425 [w]	Toronto, Ontario;  CANADA