sps getting munched and problems with compress

[Sean Casey]

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 at 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 at 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 at ukma   or
-  Department of Mathematics			{cbosgd,anlams,hasmed}!ukma!sean
-  University of Kentucky		ARPA:	ukma!sean at ANL-MCS.ARPA