dsp@ptsfa.UUCP (David St. Pierre) (05/06/85)
[Actually a non-commercial endorsement for compress 3.0]
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.
I'd like to thank James Woods for his help in providing compress 3.0
and verifying my compress problems on another machine type.
-----------------------------------------------------------
Any opinions expressed above are mine alone.
David St. Pierre {ihnp4,dual}!ptsfa!dsp