sean@ukma.UUCP (Sean Casey) (06/25/85)
There was a problem with sps getting munched. Matt Crawford mailed me that he had narrowed the possible munching sites down to 4. The path to him was: > gargoyle!ihnp4!mhuxn!mhuxr!ulysses!allegra!mit-eddie! > genrad!panda!talcott!harvard!seismo!mcvax!cernvax!hslrswi!robert The path to me was: >ukma!cbosgd!ihnp4!mhuxn!mhuxr!ulysses!allegra!mit-eddie! >genrad!panda!talcott!harvard!seismo!mcvax!cernvax!hslrswi!robert allegra!mp said: >The garbled article was OK on allegra and ulysses. He concludes that the article got munched somewhere along: ulysses->mhuxr->mhuxn->ihnp4 Upon his suggestion, I delved into the latest version of compress digest. This message was in there. >[From: dsp@ptsfa.UUCP (David St. Pierre)] > > >About a month ago, I posted an article describing a problem we were >having with c*batch. To re-state the situation: > >My feed is Dual Corporation, running Unisoft System V, M68000 (10 Mhz). >Our site is an ATT 3B20S, running SV_R2. >Qantel Corp, also receives news from Dual, and is a Vax 11/750 running >4.2BSD. > >We were all running 2.10.2 news, but our batching was 2.10.1-derived. >Recently we agreed to upgrade to c*batch. At that time, I started >noticing some /tmp/unb* files after cunbatch completed. In almost >every case, the tail end of these articles were garbled. I suspected >something was wrong with compress, but Dual wasn't having any problems >at their end. Qantel also reported sporadic /tmp/unb* files and garbled items. > >------------------------------------------------- > >After posting the article, I started saving news-batch files and noticed >what appeared to be a size dependence. Files over a certain size would >invariably leave a /tmp/unb* file; batch files under the threshold had >no problems. Trying to uncompress the files manually seemed to confirm >this - with 57000 being about the breakpoint. > >James Woods (jaw@ames) sent me a copy of compress 3.0 (I subsequently >found it in my mod.sources archives) which I also tried with no luck. >Since the SA at my feed was on vacation, I decided to run some tests >on my own machine. The results pinpointed the problem: > >Files whose compressed size was greater than 57148 bytes which were >created by the netnews 2.10.2 version of compress do not work ON ALL >MACHINES. I could not uncompress them with either the netnews compress >or 3.0. Compress -C created a file of identical length, which could >be uncompressed by either version of compress. Running od/diff on pairs >of files leads me to the belief that the threshold is 57148. > >In glancing at the compress released with 2.10.2, it has an SCCSID >of 1.6. Some of the code is apparently VAX assembler - other machine >types go through some C code which may not have been machine dependent. >Looking through my news archives, I did notice that compress 2.0 preceded >the arrival of news 2.10.2 by a week or so. > >The misbehaviour of compress 1.6 has been demonstrated on ATT 3B20s, >Dual 68K/Unisoft and Masscomp 68K RTU 2.2. Other machines may or may >not have similar problems. One reason I fell prey to the problem was >because my feed raised the csendbatch limit to 120000, which caused more >files to go over the limit than would occur with a limit of 100000. > >----------------------------------------------- > >I suppose anyone using compress for non-news related work is on 2.0 or >3.0. At least I HOPE YOU ARE. Being a System V site, I thought pack >was all I needed in my public PATHs. I stand corrected - we ran >compress vs. pack for large text files and /unix, and compress is hands >down more effective. I've installed compress 3.0 in both my public >directory as well as $LIBDIR for news. Anyone running 2.10.2 would be >well advised to review what version of compress they are using, and >upgrade to compress 3.0 as soon as practical. Compress 3.0 has a "-C" >option which will provide downward compatible files if downstream sites >are also using the old version of compress. Since news 2.10.3 will >undoubtedly (?) contain a 3.0+ version of compress, it's important that >sites position themselves for the upgrade. Now assuming that compress is the culprit, one should keep articles under 64k until those sites can upgrade to compress 3.0. Sean -- - Sean Casey UUCP: sean@ukma or - Department of Mathematics {cbosgd,anlams,hasmed}!ukma!sean - University of Kentucky ARPA: ukma!sean@ANL-MCS.ARPA