CRC errors?

John,

thanks for providing the .DIFF file, but I could actually 'visualize' a block of zeros myself So the important information are the corrupted VBN numbers !

118, 119, 242, 243 - note that those VBNs are 124. blocks apart ! COPY (in V8.3, actually since V8.2 - thanks to Guy !) is using a DEFAULT COPY BLOCK SIZE of 124 !

Re-try the COPY with /BLOCK_SIZE=63 - do the 'corruptions' still happen ?

You should start using IO$SDA tracing the COPY operation. I assume, that 124. block IOs to the files on CD is somehome overwhelming some of the drivers (FreeAXP, Windows, CD ?) in the IO stack. Backup will most likely be limited to 63. block IOs (you could also easily find this with IO tracing).

$ ANAL/SYS
SDA> IO LOAD
SDA> IO START TRACE/NOBIO/DIO
SDA> SPAWN COPY from-cd to-disk
SDA> IO STOP TRACE
SDA> IO SHOW TRACE/DIO
SDA> IO UNLOAD
SDA> EXIT

Volker.<hr>

A WORD OF WARNING for FreeAXP users !!!

Be careful when COPYing files from CD especially with OpenVMS Alpha V8.2 or higher using the COPY command ! File data may be getting corrupted.

You'll only easily see this with .ZIP files when you try to UNZIP them. Seeing corruption in other types of files may be more difficult.

As a workaround, use BACKUP to copy the files.

Volker.<hr>

No corruption with block size of 63.

I had to dismount the CD-ROM to clear the cache after the successful copy as the next copy I did with the default block size had no corruption. SDA showed no disk reads were done.

I/O Trace Information:

---

Timestamp CPU IRP SeqNum UCB Device Oper
Function Trace Buffer Byte Cnt Media

---

---

---

---

---

---

---

---

---

---

4-JUN 05:09:50.801979 00 81FD9240 0001F76E 81DF2780 DKA100 DirIO
writepblk FFFFFFFF.7B439588 00000200 02000001
4-JUN 05:09:50.785008 00 81EA5B40 0001F73B 81DF2780 DKA100 DirIO
writepblk FFFFFFFF.7B437B10 00000200 02000001
4-JUN 05:09:50.784876 00 81EA5B40 0001F73A 81DF2780 DKA100 DirIO
writepblk FFFFFFFF.7B4379F8 00000200 02000001
4-JUN 05:09:50.780077 00 81EA5B40 0001F739 81DF2780 DKA100 DirIO
writepblk FFFFFFFF.7B4378E0 00000200 02000001
4-JUN 05:09:50.779510 00 81EA5B40 0001F735 81DF4E00 DKA600 DirIO
readpblk FFFFFFFF.7B437678 00000200 02000001
4-JUN 05:09:50.778620 00 81EA5B40 0001F733 81DF4E00 DKA600 DirIO
readpblk FFFFFFFF.7B4374F0 00000400 04000001
4-JUN 05:09:50.766549 00 81F1DE80 0001F731 81DF4E00 DKA600 DirIO
readpblk FFFFFFFF.7B437368 00000200 02000001
4-JUN 05:09:50.765354 00 81F1DE80 0001F72F 81DF2780 DKA100 DirIO
writepblk FFFFFFFF.7B4371E0 00000200 02000001
4-JUN 05:09:50.756948 00 81EA5B40 0001F71A 81FC3080 MBA135 DirIO
setmode FFFFFFFF.7B436840 00000000 00000001
4-JUN 05:09:50.756937 00 81EA5B40 0001F6E4 8202FF40 ?????? DirIO
writeof FFFFFFFF.7B436798 00000000 00000001
4-JUN 05:09:50.753065 00 81EA5B40 0001F6BF 81F10440 FTA1 DirIO
sensemode FFFFFFFF.7B434038 00000000 000F0001
4-JUN 05:09:50.752950 00 81EA5B40 0001F6BE 820301C0 MBA133 DirIO
setmode FFFFFFFF.7B433F90 00000000 00000001
SDA&gt;

John,

to eliminate the XFC cache, you could MOUNT/NOCACHE the CD.

But the fact that /BLOCK=63 does NOT show corruptions, more or less proves my analysis.

Somewhere in the path between the OpenVMS 124-block QIO call and the data on the CD, you loose some blocks of real data.

As far as I understand, you're running FreeAXP in another 'virtual' environment, so all those components come into play now as well.

One EASY approch is to use PersonalAlpha instead of FreeAXP in the same 'virtual' environment. This will immediately show, if the problem is with FreeAXP. If PersonalAlpha would fail in the same way, chances are that the problem is 'in your virtual environment', this might become interesting then

Does FreeAXP use the Windows File Cache ? If so, are there parameters to suppress this ?

If you look at the BACKUP-E-VERIFYERR errors you've seen before, note that 615 and 243 are actually 3x124 blocks apart as well ! These numbers also indicate, that the error is systematic, but still intermittent !

In light of the recent findings, Astrodanco unfortunately did not supply enough information about VMS-version and Windows environment, to allow any more conclusions. He was using the V8.3 Hobbyist CD, so one could assume, he was also using OpenVMS Alpha V8.3. IF he would have run FreeAXP natively in Windows, we could quickly rule out your 'virtual environment'.

Volker.

I'm running OpenVMS V8.3 installed from the Hobbyist CD.

I'm running FreeAXP directly on Windows 7 64-bit on an Intel Core i7-920.

The unzip CRC problem only occurs for me if I first copy the .ZIP file off the CDROM with the copy command. It does not happen if I either copy the file with the backup command or if I unzip the file directly from the CDROM.

Thanks for the tips guys.

BTW, the latest beta gives me fewer errors, only a single CRC error. All the others have gone away.<hr>

Thanks for the confirmation. This explains, WHY you are also seeing this problem (V8.3 has COPY/BLOCK=124 as default).

This absolves John's 'virtual environment'.

So the next best step actually is testing with PersonalAlpha, to also rule out the Windows components.

The 3-APR-2010 entry by johncookson indicates that he was using PersonalAlpha and the V8.3 OpenVMS Hobbyist CD, but a confirmation would be needed to find out, IF he was running OpenVMS V8.3 and actually used COPY to copy the .ZIP file from the CD before unzipping it...

Volker.