Is there an (UN)ZIP api?

[Craig A Berry]

No one seems to have mentioned the backup API, which now has the BCK_OPT_K_DATA_FORMAT_COMPRESS option. That sounds promising and is documented here:

http://www.openvms.compaq.com/doc/84final/4493/4493pro_001.html#4493_bu_chap

Another thing to keep in mind is I think you are looking for archiving as well as compression, and the two things don't necessarily come in one package. For example, I think zlib only compresses a data stream but doesn't know on its own how to assemble compressed files into an archive.

[Hein van den Heuvel]

I thought of, and should have mentioned the backup API.
I discared it because best I know savesets are static.
You can not add files after the fact.
With zip you can.

fwiw,
Hein

[abrsvc]

I am currently contracted with a client that has a similar problem with file creation. The solution here was to create daily backup savesets and store them on an archive server. These savesets are rarely accessed and reside on their own server system. The savesets are created directly over the network and the text files are deleted after 20 days in rotation. We have found that any "lookups" usually occur within the 20 day window. On the rare occassion that a file is needed, we restore it from the daily run.

We chose to run this via a self-submitting batch job rather than using the API through an application.

Dan

[John McL]

John Gillings and abrsvc have practical ideas but a couple of other ideas that might be helpful even if they do involve more effort.

Have you seen zlib (see http://www.zlib.net/)? We run it here on VMS to create and write compressed files.

Maybe think about separating the creation of the printer output from the data preparation. The main processing would sort out what's to appear on the invoice and write it to a growing indexed file, but another function or image would be responsible for reading that data and formatting it. You'd probably end up storing less data and have the flexibility of probably making changes in one place if the output document had to be modified.

[Jur van der Burg]

In newer vms versions (V8.3 or later) there's compress$share with entries ZLIB$UNCOMPRESS and ZLIB$COMPRESS2 wich is used by backup. An application could use that.

Fwiw,

Jur.

[Peter Barkas]

FWIW, my experience of repeatedly adding files to existing zip files is that performance really starts to suffer with large zip files.

Unless something has changed since then, the new file is not 'tacked on the end', the whole zip file is read and rewritten with the new file inserted.

[Steven Schweda]

> Unless something has changed since then,
> the new file is not 'tacked on the end',
> the whole zip file is read and rewritten
> with the new file inserted.

Zip is somewhat averse to damaging an
existing archive while building its
replacement. Tacking stuff onto the end of
an existing archive could lead to damage, if
something goes wrong while tacking. Other
(riskier) schemes may be possible, but are
not currently on the Zip to-do list.