Newly release OpenVMS V7.3-1 Checksum issue.

[PatchAdmin]

Hi all

I think that there's a problem with the checksum information in the text file of the patch which is ftp'ing from the new ITRC site, because the checksums does not correspond with the ones in the ".pcsi-dcx_axpexe" files of the patches when I checksum each file individually. See below, is there any one that has expierence the same problem and if so, is there an explaination or workaround regarding this issue.

VMS731_DCL-V0400.PCSI-DCX_AXPEXE Checksum: 1433005636

$ checksum VMS731_DCL-V0400.PCSI-DCX_AXPEXE;1
$ show symbol checksum$checksum
CHECKSUM$CHECKSUM = "4186712135"



VMS731_FIBRE_SCSI-V0400.PCSI-DCX_AXPEXE Checksum: 2780135907

$ checksum VMS731_FIBRE_SCSI-V0400.PCSI-DCX_AXPEXE;1
$ show symbol checksum$checksum
CHECKSUM$CHECKSUM = "2527069764"




VMS731_TTDRVR-V0100.PCSI-DCX_AXPEXE Checksum: 523747416

$ checksum VMS731_TTDRVR-V0100.PCSI-DCX_AXPEXE;1
$ show symbol checksum$checksum
CHECKSUM$CHECKSUM = "996639956"


and the rest of the newly release patches.


Cheers
Patchadmin

[Ian Miller.]

as the .PCSI-DCX_AXPEXE files are executable images you could try CHECKSUM/IMAGE to see if it gives a matching result.

[PatchAdmin]

Hi there

I've done the propose dcl command as requested, but it seems that the ouput does not correspond with the checksum in the text file yet.

Cheers
Patchadmin


Text file extraction:

VMS731_NETACP-V0100.PCSI-DCX_AXPEXE Checksum: 2854952091

DCL commands:

$ checskum VMS731_NETACP-V0100.PCSI-DCX_AXPEXE;1
$ show symbol checksum$checksum
CHECKSUM$CHECKSUM = "1714101403"

$ checskum/image VMS731_NETACP-V0100.PCSI-DCX_AXPEXE;1
file SYS$SYSDEVICE:[SWIST.TMP]VMS731_NETACP-V0100.PCSI-DCX_AXPEXE;1
image section %D'1' checksum is %X'9BD05C90'
image section %D'2' checksum is %X'435B683B'
image section %D'3' checksum is %X'FD1A7B92'
image section %D'4' checksum is %X'11E7FBA1'
image section %D'6' checksum is %X'05543174'
image header checksum is %X'00000019'
checksum of all image sections is %X'312285EC'
$ show symbol checksum$checksum
CHECKSUM$CHECKSUM = "824346092"

[John Gillings]

A problem with using CHECKSUM on VMS images is that the header is included. That means changing the RMS attributes will affect the result.

One of the reasons for compressing patch kits into executable images is that the image activator really doesn't care about the file organisation or record attributes, as long as the bits are in the right place. That means a file can be passed through the internet without getting "damaged" by losing its record attributes (unlike, say, a BACKUP saveset). However, unless the record attributes are identical with the original file, the checksum won't match.

You could try:

$ SET FILE/ATTR=(RFM:FIX,MRS:512)

This may give you the correct checksum.

[Martin P.J. Zinser]

Hello,

it does not. I just pulled the DCL kit directly via FTP to my VMS system, made sure that the attributes were correct and do receive the same (wrong) checksum reported here earlier. Just for completeness I also determined the checksum of the extractet PCSI kit and that does not match the one given by hp either. Seems the process at hp determining the checksums is still broken (it is very new for ITRC). John, can you get this resolved internally?

Greetings, Martin

[Derek Haining]

I saw this problem as well when a patch kit
was downloaded. I figured that there was
an internal problem that was causing the
kits to become corrupted when they were
posted onto ITRC.

[jrd]

These kits and the checksum issues are being investigated within OpenVMS Engineering. It does appear that something is wrong.

To clarify the intended usage of the CHECKSUM command:

1. Don't use CHECKSUM/IMAGE. Use plain CHECKSUM, or CHECKSUM/FILE, which is the same.

2. The calculated checksum is stored in the DCL symbol CHECKSUM$CHECKSUM.

3. CHECKSUM does NOT include the image header. ACLs etc. will not change the checksum. Changing record attributes may change the checksum, since RMS will interpret the data differently.

[Hein van den Heuvel]

Yeah, VMS Engineering is working this. The various combinations of FTP externally, and and internally SPOOL (aka FTSV) seem to have caused problems with the checksum. This is notably the case when the original file had an odd, non-multiple-of-512 EOF Byte, despite being fixed length 512. Yes, this is legal, and notably the linker exploits this for store symbol tables. The 'non-existent' bytes between EOF and the end of the last block may be behind this. Ongoing...

Hein.

[George_145]

The checksum issue is one we realized this week and have been investigating. The problem has to do with the kit build process and affects all VMS OS ECO kits that have the checksum information in the documentation header (limited to recently released kits). Because of the way Spool (used to compress the kits) and COPY work, once a kit is compressed and copied, if the last bit after the end of file is null it is zeroed. This changes the checksum but does not affect the integrity of the kit. Coincidently, FTP does the same thing. Since the checksum is calculated and added to the documentation before the compressed file is copied, the documentation does not have the final checksum. This bit zeroing was something that was never noticed before and only came to light when we started including checksums in the build process. Previously, checksums were calculated in a post processing step after the kits left VMS engineering.
Bottom line is that if the kits have copied properly and are the correct size they are good and can be installed. The checksum information is incorrect not because of kit corruption but because of a process problem. Now that the cause of the checksum discrepancies has been found, the process is being modified to eliminate the discrepancy. The documentaion for all kits that have been issued with checksums in the documentation are being re-issued with the correct checksum.

[Martin P.J. Zinser]

Hello George,

Thanks a lot for the update. Your effort getting this rectified is greatly appreciated. Now for another nit concerning ITRC:

I did report this problem via the "official" contact hp ITRC mail link as proposed in the ITRC BOF last week at the bootcamp. That was last Saturday. I did receive am automated reply that same day, but nothing else since then. Is that interface just a bit bucket in disguise?

Greetings, Martin

[George_145]

Martin, I don't think so. I was advised of this problem this morning from the ITRC, by which time we were already working the issue. So, your contact HP mail was routed to the correct victi, I mean contact.

[Martin P.J. Zinser]

Hello George,

Thanks for the update. It is good to know the process does work internaly, still may I suggest to check why no feedback to the mail has been sent. I am likely to catch up most of the stuff being said in the forums, other customers might not and would get frustrated by the perceived in-action of hp.

Greetings, Martin

P.S. And just to make that perfectly clear, I do appreciate engeneerings efforts to fix this and other problems as fast as possible very much. I just want to make sure that this is not clouded in the general perception by a not optimal communication

[George_145]

Martin,

I responded to the ITRC with an answer to the problem this morning. If you do not get an answer via the Contact ITRC route by tomorrow, please let me know.

George

[Martin P.J. Zinser]

Hello George,

nothing from the ITRC ask hp feedback link
yet (besides of the initial automated reply)...

Greetings, Martin

[Martin P.J. Zinser]

Hello George,

Received the following today:
---------------------------------------------

[Martin P.J. Zinser]

Seems the Webinterface chocked on the cut-n-paste from the mail received by ITRC support. Next try:

RE: 3203846592
FR: walter_bridges

Martin,

It appears that the problem with OpenVMS timing out when trying to download patches has been resolved, but due to some internal netw
ork problems with are having you may still see a consistency in it timing out. Please feel free in contacting us for any further as
sistance.

Regards,

Walter
ITRC Usage Support

Note: I have only opened one question with ITRC ask hp up to now. This is about the current thread with checksums. It has nothing todo with timeouts.

Looks like there is room for improvement...

Greetings, Martin

[George_145]

Martin,

I'll see if I can get a hold of the people behind the curtain and let them know there is a problem.

If anyone is not satisfied with the response from Contact HP please complain about it. I do get customer questions routed to me from services but I really have no idea if they are coming from Contact HP or from some other source.