From: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: re: Need Info and Advice re VMS DCX Routines
Date: 29 Aug 92 13:35:08 GMT
Article-I.D.: uu3.9208291334.AA29538
Distribution: world
Organization: The Internet


	While skimming the VMS System Routines manual for something else, I
	found a chapter entitled "Data Compression/Expansion (DCX) Routines."
	The introductory note states "There is no DCL-level interface to this
	facility nor is there a DCX utility."

	With a good bit of time and effort, I suppose I could learn how to use
	these routines to write my own compression/decompression programs. But
	since I have no prior experience, I'd like to pose a few questions
	first:

	1) Is it correct to assume that since the DCX routines are part of
	VMS, they will be "better" (however that may be defined - faster, more
	reliable, etc.) than other available compression packages for
	processing files in our system (a VAX 6320 running VMS 5.4-3, soon to
	upgrade to 5.5)?

Only with a very careful definition of "better".  At one time, I did a fair
amount of experimentation with DCX, comparing it to LZCOMP.  LZCOMP almost
always gets a higher compression ratio.  As I recall, they have comparable
running speeds.  While I haven't tried them, statistics I've seen claim that
more recent compressors like those in ZOO get even better compression ratios
than LZCOMP.

DCX does one thing that the others I'm aware of do not:  It does a good job
of compressing small, independent blocks of data.  The main use of DCX is by
the VMS Librarian:  If you specify /DATA:REDUCE when you create a library,
the individual modules in the library will be compressed.  This will be quite
transparent, since the Librarian will decompress the modules when you extract
them.  This requires that each module be separately compressed, since you
don't want to have to decompress the whole thing to extract one module.

It was, in fact, for exactly this purpose that DCX was developed.  Various
libraries (like the help libraries) that ship on VMS kits are compressed.
This helps keep kits smaller - which was a big deal at the time, when a VMS
kit came on umpteen RX50's.  Except on systems that are very tight on disk
space, the libraries are normally decompressed after installation - there's
a command file, SYS$UPDATE:LIBDECOMP.COM, that the system manager can run to
do this.

I have seen no reliability problems with LZCOMP in years.  That makes it
impossible to say if DCX is "more reliable".  In any case, such reliability
problems as there were had nothing to do with compression/decompression;
they had to do with difficulties restoring certain kinds of file attributes.
DCX as such doesn't deal with files; if you were to use it to compress whole
files, you'd first have to build something to extract and save all the
necessary file attributes, then put them back on expansion.  This code would
be identical in specification (and potential bugs) to similar code in LZCOMP.

Of course, if LZCOMP (which I've been using as the example I'm most familiar
with; there are plenty of other such tools out there) does break, you are
pretty much on your own; if DCX breaks, you can go after DEC.

	2) Does anyone else have experience exploiting these routines? Would
	you recommend them? 

I've never seen a general file-compression interface built for them.  For
compressing libraries that you want to continue to access AS libraries, they
are your only choice.  Also, they are the only callable compression package
for VMS that I've seen.  That makes them potentially usable in a variety of
circumstances similar to libraries.  (For example, one could theoretically
have MAIL compress saved messages, or BACKUP compress files as it puts them
into a BACKUP saveset.  In fact, since BACKUP can use the DEC encryption
package, it already has "callout's" at the right points; theoretically, one
could write a package that provided the same entry points as the encryption
package, but compressed the data handed to it, rather than encrypting it.  I
looked into doing this at one time, but never determined if it would actually
work - for example, it might be that the "encrypted" block you hand back has
to have the same size as the cleartext block you were handed.)

	3) Are there any publically available packages based on DCX?

Well, you've got the VMS Librarian right there on your system!  If what you
want to compress is a text file, the easiest thing to do is to create a
data-reduced text library to hold it.  You can similarly easily compress
object files or executable files.

	4) Assuming that the answer to 1) is yes and 3) is no - would the
	advantage of DCX be sufficient to warrant trying to master it? Or
	would it be best to just use something already available?  

To summarize:  I see little to be gained from building yet another general-
purpose file compression utility for VMS, this one on top of DCX.  DCX isn't
a particularly good compressor in that role, and the potential problems in
such a program would be in the NON-compression parts, not in the underlying
"compression engine".
							-- Jerry
Newsgroups: comp.os.vms