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