download patch checksum problem with ITRC

[Jim Strehlow]

I went to the ITRC to get a list of patches for OpenVMS Alpha v7.3-1
In the list is the patch
ALP_DCE_030_SSRT3608-V0100
which is for various versions of OpenVMS.

After many gyrations of FTP to my OpenVMS server, I unzip what ITRC packaged and get the AXPEXE.
$ checksum ALP_DCE_030_SSRT3608-V0100.PCSI-DCX_AXPEXE

%CLI-E-READERR, error reading DISKMEDIA:[MEDIA.VMS072-1]ALP_DCE_030_SSRT3608-V0100.PCSI-DCX_AXPEXE;1
-RMS-W-RTB, 904 byte record too large for user's buffer

So I
A$SET FILE /ATTRIBUTE=LRL:8192 DISKMEDIA:[MEDIA.VMS072-1]ALP_DCE_030_SSRT3608-V0100.PCSI-DCX_AXPEXE
$checksum ALP_DCE_030_SSRT3608-V0100.PCSI-DCX_AXPEXE
$show symbol checksum*
CHECKSUM$CHECKSUM = "2805997751"

Now, where is the documentation of the checksum so that I can verify that I have a valid download?

Note: I can NOT find that patch in any of the usual FTP directories.

Jim

[Ian Miller.]

should be in readme but isn't in this case.
Another triumph :-(

[John Gillings]

Jim,

You could try CHECKSUM/IMAGE, but I'd assume that the RTB warning means the file is broken. It needs to be transferred as FTP BINARY, in which case I'd expect the record attributes to be fixed 512 byte records. What were the attributes? Anything STREAM is most likely wrong.

On the other hand, if you can successfully RUN the image and have it unpack, it's *probably* OK. Next check would be to see if PCSI can list the resultant file. Post any error messages issued from those steps.

Expect some improvements in mechanisms for validating patch downloads in the near future (sorry, I don't think I can give any more detail at this time).

[Jim Strehlow]

ITRC only allows me to click on "shopping cart items" into a zip file which I binary copy to OpenVMS, then set the file attribute, and then run a CHECKSUM.

I can not find the object in the usual FTP directories, nor can I find any CHECKSUM with which to verify I have a valid result.

That is not what I consider "user friendly" or "serving the needs of I.T." who install the patches.

I am manually checking that I have not overlooked any patches ... and ITRC showed me that patch which I did not have before.
But, I can only currently get that patch via ITRC's web site in the format that ITRC chooses.

Jim

[Martin P.J. Zinser · Accepted solution]

Hello Jim,


I just went through the execercise you described. Here are a couple of remarks.

a.) The "shopping cart" zip file contains a small file called patch_manifest. This does contain the path and size of the patch on the ftp server, e.g. for the patch you quote -

openvms_patches/layered_products/alpha/

and if you do think about it for a moment the way the ftp server is organized does make sense if you do not want to duplicate layered product patches in all of the various OS version directores they might apply to.

b.) I was able to reproduce the checksum problem on the dcx file. It would be nice if this could be fixed. Upon download/unpacking directly on VMS the file is created with

Record attributes: Carriage return carriage control

instead of fixed 512. OTOH I would expect a checksum (if there was one!) to apply to the actual PCSI archive, not to any of the intermediats. And unpacking from the DCX does work.

Generally speaking the patch site is far from perfect, but if you take a moment to look at it, it is also not entirely bad :-)

Obviously my 0.02 USD here and YMMV.

Greetings, Martin

[John Gillings]

Jim, Martin,

This is not necessarily what you want to hear. First, the CHECKSUM command is undocumented and therefore unsupported. Sure plenty of people use it, and some details of what it does are in the public domain, BUT it's really only there for VMSINSTAL. So if you use it, and it does what you want, that's great. If not, sorry!

I've just checked the process of downloading, and realise that the DCX file is in STREAM_LF record format. Although that's not very "OpenVMSish" it's only a problem if you poke at the file with things like CHECKSUM. Apart from some modest compression, the main reason for using self expanding DCX files for transporting patches is that the image activator generally doesn't care about record attributes. Therefore as long as you don't mess with the bits, it doesn't matter what else happens to the file in getting from ITRC to your system. A corollary is that any checksums you take of this file MAY NOT match, even though the file content has changed (some mechanisms for checksums include enough of the file header that a change from FIXED 512 to STREAM_LF is sufficient to modify the checksum). Bottom line, is the only thing you should do with the DCX file is RUN it.

Most file transfer errors will result in a failure to expand either the ZIP or the DCX and any that get past those will probably fail in PCSI. This is not perfect, but sufficient for most purposes.

>I can not find the object in the usual
>FTP directories, nor can I find any
>CHECKSUM with which to verify I have a
>valid result.
>
>That is not what I consider "user
>friendly" or "serving the needs of I.T."
>who install the patches.

Agreed! As I hinted, things will be done about this in the near future. Expect a mechanism using the patch manifest to include information to validate the download. As Martin suggests it will focus on the PCSI file, rather than any of the intermediate formats. Also expect it will be much "harder" than the rather simple algorithm in CHECKSUM (hacking a file so that the CHECKSUM result doesn't change is trivial - that wasn't the intention of the CHECKSUM command).

If you have any feedback about ITRC, please use the "contact hp" link in the top left of each page to send it to the people who can act on it.

[Jim Strehlow]

John, I got more information from this forum than I did when I contacted H.P. on our software support "obligation i.d.".

Thank you for your information regarding CHECKSUM. Most of us "seasoned veterans" (I am not yet a greybeard) have been "comfortable" for decades with comparing CHECKSUMs to validate that nothing corrupted during a download. I have always considered that a plus on the OpenVMS side.

When will H.P. will release its new algorithm?
Hopefully it will run on OpenVMS and not be a tool that only works on a Windows workstation.

Jim

[Martin P.J. Zinser]

Hello John,

I am well aware of the limitations of checksum,
actually according to our experience checksums
can even change when moving files between disks of different clustersize. I would expect the new scheme to use either GnuPG or MD5. I personally would prefer MD5 since it should be possible to support this way back on old versions of VMS.

Greetings, Martin