Compressed PCSI kits - any issues?

[Sebastian Bazley]

We use CDs to transport PCSI kits for installation on customer sites, and the CDs tend to fill up rather too easily.

So I'm looking at converting the larger PCSI kits to compressed versions.

Just wondering if there are likely to be any problems with using the compressed version of the kits?

We use mainly VMS7.3-2, though some sites are still using 7.3-1.

[We could increase the compression by using zip "-V", but then the files would have to be unzipped before use.]

[Ian Miller.]

hp are moving to more PCSI$COMPRESSED kits exactly the same reason. The only trouble appears to be if I forget to do binary transfer when using ftp.

[John Gillings]

Sebastian,

If your CDs are FILES-11 there shouldn't be a problem, but if they're ISO 9660 you have to ensure the file attributes are restored before PCSI can process the file.

This is why the ITRC patch kits aren't compressed - HP haven't worked out a reliable way to fix the attributes when the files reaches the customer system.

You're obviously aware that you are also limiting yourself to post V7.3 systems

[Eberhard Wacker]

As far as I've seen HP provides the eco files for Itanium as ZIP files for download. No unique behaviour anymore ...

Whatever: in your case I would package all PCSI files into 1 (!!) VMS saveset and ZIP this afterwards.
Only 2 activities before burning (and 2 at customer site) and the compression result is better than using PCSI compression (from my experience).

Cheers,
EW

[Sebastian Bazley]

Thanks for all the feedback, a few comments:

Re: Ian Miller.
* Yes, but as far as I know, ordinary PCSI kits also require binary FTP transfers.

Re: John Gillings.
* Yes, we are using an ODS-2 disk. This allows us to install the kits directly from the CD if required.
* Not sure why HP should have problems with file attributes - surely the self-decompressor can restore compressed PCSI just as well as uncompressed?

Re: Eberhard Wacker.
* Yes, Zip compresses much better, but has to be decompressed before use.
* I can't see the point in using backup first - we find zip "-V" works fine and avoids the backup overhead.
* We use the disks for initial installation and upgrades, so one large Zip would be a nuisance.

So the view so far here is:
No problems noticed with PCSI$COMPRESSED on VMS 7.3+ so long as care is taken with the file attributes.

[Ian Miller.]

VMS I64 patches are supplied as .zipexe that is self uncompressing zip. I don't know why hp do not use pcsi$compressed format.

[John Gillings]

>* Not sure why HP should have problems
>with file attributes - surely the
>self-decompressor can restore compressed
>PCSI just as well as uncompressed?

> I don't know why hp do not use
>pcsi$compressed format.

There were a couple of patches released on ITRC in PCSI Compressed format, but they didn't always make it to the customer system with the right attributes. The biggest hurdle is that HP has no control over the way various browsers and non-OpenVMS operating systems treat the files in transit.

Sure, it's possible to do various layers of encpaulation and compression. Personally I tend to package things into BACKUP savesets, then ZIP or compress, because I know I can always repair a saveset, but multiple unpackaging steps and potential requirement for repair steps is a bit kludgy for production.

My preference would be to change both BACKUP and PCSI to either ignore, or offer to repair files with apparently incorrect attributes. There's enough information in the files themselves that the actual RMS attributes are redundant.

[Sebastian Bazley]

>The biggest hurdle is that HP has no
>control over the way various browsers and
>non-OpenVMS operating systems treat the
>files in transit.

Surely this does not apply to Zip/ZipExe or DCX_AXPEXE files? Or it it does, then the problem also applies to normal PCSI kits.

I don't see how PCSI$COMPRESSED kits are any different from PCSI kits in this respect.

==

I like the idea of BACKUP and PCSI offering to repair the files.

[Sebastian Bazley]

No reported issues, other than those caused by incorrect ftp file copy modes.