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.
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'.
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.
Edited by astrodanco on June 04 2010 13:11
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...
In response to a request from Volker, here are the results from using Unzip 6.0 on PersonalAlpha with the OpenVMS 8.3 Hobbyist CD. Note that I have tested cases where the ZIP archive is copied from the CD before Unzipping and also where Unzipping is performed directly from the CD media.
$ SH DEF
DKA100:[CRAP]
$
$ COPY DKA200:[KITS]BASIC016.ZIP;1 []
$
$ UNZIP -t BASIC016.ZIP
Archive: DKA100:[CRAP]BASIC016.ZIP;1
testing: basic016/documentation/ OK
testing: basic016/kit/ OK
testing: basic016/documentation/basic016_cover.ps OK
testing: basic016/documentation/basic016_cover.txt OK
testing: basic016/documentation/basic016_iguide.ps OK
testing: basic016/documentation/basic016_iguide.txt OK
testing: basic016/documentation/basic016_spd.ps OK
testing: basic016/documentation/basic016_spd.txt OK
testing: basic016/kit/basic016.a OK
testing: basic016/kit/basic016.b OK
testing: basic016/kit/basic016.c OK
testing: basic016/kit/basic016.d OK
testing: basic016/kit/basic016.e OK
testing: basic016/kit/basic016.f OK
testing: basic016/kit/basic016.g OK
testing: basic016/kit/basic016.h OK
testing: basic016/kit/basic016.i OK
No errors detected in compressed data of DKA100:[CRAP]BASIC016.ZIP;1.
$
$ UNZIP -t DKA200:[KITS]BASIC016.ZIP
Archive: DKA200:[KITS]BASIC016.ZIP;1
testing: basic016/documentation/ OK
testing: basic016/kit/ OK
testing: basic016/documentation/basic016_cover.ps OK
testing: basic016/documentation/basic016_cover.txt OK
testing: basic016/documentation/basic016_iguide.ps OK
testing: basic016/documentation/basic016_iguide.txt OK
testing: basic016/documentation/basic016_spd.ps OK
testing: basic016/documentation/basic016_spd.txt OK
testing: basic016/kit/basic016.a OK
testing: basic016/kit/basic016.b OK
testing: basic016/kit/basic016.c OK
testing: basic016/kit/basic016.d OK
testing: basic016/kit/basic016.e OK
testing: basic016/kit/basic016.f OK
testing: basic016/kit/basic016.g OK
testing: basic016/kit/basic016.h OK
testing: basic016/kit/basic016.i OK
No errors detected in compressed data of DKA200:[KITS]BASIC016.ZIP;1.
$
As you can see, there are no problems to report. I will perform the same test using FreeAXP release 283 and report back shortly.
Note that I am using the exact same hardware and O/S that I used for this test on PersonalAlpha, which is Intel Core 2 Duo, LG DVD drive WinXP Pro SP3 32 bit.
It seems fairly conclusive from my test results that these CRC errors emanate from a bug in the FreeAXP emulator.
$ SH DEF
DKA100:[CRAP]
$
$ COPY DKA200:[KITS]BASIC016.ZIP;1 []
$ UNZIP -t BASIC016.ZIP
Archive: DKA100:[CRAP]BASIC016.ZIP;1
testing: basic016/documentation/ OK
testing: basic016/kit/ OK
testing: basic016/documentation/basic016_cover.ps OK
testing: basic016/documentation/basic016_cover.txt OK
testing: basic016/documentation/basic016_iguide.ps OK
testing: basic016/documentation/basic016_iguide.txt OK
testing: basic016/documentation/basic016_spd.ps bad CRC c174c123 (should
be 31b98e50)
testing: basic016/documentation/basic016_spd.txt OK
testing: basic016/kit/basic016.a OK
testing: basic016/kit/basic016.b bad CRC 7becf1cb (should be a444e794)
testing: basic016/kit/basic016.c bad CRC d4f8f664 (should be cef1e30f)
testing: basic016/kit/basic016.d
error: invalid compressed data to inflate
testing: basic016/kit/basic016.e OK
testing: basic016/kit/basic016.f bad CRC 92a0891b (should be 6f16cea2)
testing: basic016/kit/basic016.g OK
testing: basic016/kit/basic016.h
error: invalid compressed data to inflate
testing: basic016/kit/basic016.i
error: invalid compressed data to inflate
At least one error was detected in DKA100:[CRAP]BASIC016.ZIP;1.
$
$
$ UNZIP -t DKA200:[KITS]BASIC016.ZIP
Archive: DKA200:[KITS]BASIC016.ZIP;1
testing: basic016/documentation/ OK
testing: basic016/kit/ OK
testing: basic016/documentation/basic016_cover.ps OK
testing: basic016/documentation/basic016_cover.txt OK
testing: basic016/documentation/basic016_iguide.ps OK
testing: basic016/documentation/basic016_iguide.txt OK
testing: basic016/documentation/basic016_spd.ps bad CRC c174c123 (should
be 31b98e50)
testing: basic016/documentation/basic016_spd.txt OK
testing: basic016/kit/basic016.a OK
testing: basic016/kit/basic016.b bad CRC 7becf1cb (should be a444e794)
testing: basic016/kit/basic016.c bad CRC d4f8f664 (should be cef1e30f)
testing: basic016/kit/basic016.d
error: invalid compressed data to inflate
testing: basic016/kit/basic016.e OK
testing: basic016/kit/basic016.f bad CRC 92a0891b (should be 6f16cea2)
testing: basic016/kit/basic016.g OK
testing: basic016/kit/basic016.h
error: invalid compressed data to inflate
testing: basic016/kit/basic016.i
error: invalid compressed data to inflate
At least one error was detected in DKA200:[KITS]BASIC016.ZIP;1.
$
thanks a lot. With this kind of cooperation, it looks like we've actually nailed the problem quickly !
Now it's up to Bruce and his engineering team to fix it...
Let me add one observation on your FreeAXP test:
I would NOT have expected the UNZIP test directly from the CD to fail, because I don't think UNZIP would actually be using large IO block sizes, but the 'corrupted' file data (from the COPY operation) may have still been in the XFC cache. Could you try again with MOUNT/NOCACHE DKA200: ? Or UNZIP from CD first (before COPY).
Volker.
Edited by VolkerHalle on June 05 2010 01:10
if using XFC, it will probably allocate demand-zero pages and fill the data read into those pages using 'DMA' (being emulated in FreeAXP). If skipping XFC (you can also reduce VCC_MAX_IO_SIZE to < 124), COPY might present 'dirty' buffers, which are being filled by DMA. If the DMA algorithm has a problem, you might see the 'previous data' in those buffers.
you could also check the corrupted VBN numbers after COPY/BLOCK_SIZE=nnn by varying the IO block size. We know that nnn=63 works. When does the problem start, with nnn=64 ? What happens with nnn=127 ?
Now when the corrupted blocks do NOT contain ZEROs, but some data (after MOUNT/NOCACHE), can you find out, if this data is from 'other' blocks ? If so, from which ones ?
We know it's the 'big' reads from CD, which are causing the problem. Reading from the virtual disk is fine, right ? If you COPY a 'good' zip file from disk to disk, it should NOT get corrupted. You can do a SET FILE/NOCACHE first to eliminate XFC.
You can also trace the IOs to the CD by using LDDRIVER. It has a TRACE mode, which can trace all IOs. You create a LDA1: device, which sends all IOs straight to the real device (FROG$DKA200: - your CD).
I've now also verified, that this problem does NOT happen with PersonalAlpha V2.0.17 and E8.4. Neither by COPYing a file with /BLOCK_SIZE=124 from a real CD nor from an .ISO file.
The problem also cannot be reproduced on FreeAXP .283 against an .ISO file copy of a CD with E8.4.
Using FreeAXP .283 and OpenVMS V7.3-2 also works fine.
This seems to be some FreeAXP 'internal state' problem, because the following makes the problem go away:
- start FreeAXP .283
- Boot V7.3-2
- execute test -> success
- shutdown V7.3-2
- boot E8.4 (NOTE: do NOT stop FreeAXP)
- execute test -> success !!!
If you stop and start FreeAXP after running V7.3-2 and boot E8.4 as the first thing after starting FreeAXP, the problem shows up again !
And another observation:
the 'bad' data in block 118 and 119 seems to come from blocks 358 and 359, block-offset = 2 x 120. COPY/Block_size UP TO 120 does work !
NOTE: when testing this operation with FreeAXP, watch out:
If you copy a file from CD, which is mounted with /CACHE (this is the default) and use a smaller /BLOCK_SIZE first, then subsequent tests with larger /BLOCK_SIZE may seem to work, as the file data is still in the XFC cache !
So for testing this problem, either use MOUNT/NOCACHE cd: or set VCC_MAX_IO_SIZE to 120 or less (default is 127). This will cause IOs with this size to bypass the XFC file cache !
Volker,
Edited by VolkerHalle on June 05 2010 21:53
I performed the test you requested with FreeAXP whereby I unzipped the archive directly from the hobbyist CD without first performing a DCL copy operation. As you can see below, no errors were generated using this method.
$
$ mount dka200:
_Label: ALPHA083
_Log name:
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-MOUNTED, ALPHA083 mounted on _HOBBY$DKA200:
$
$
$
$
$ UNZIP -t DKA200:[KITS]BASIC016.ZIP
Archive: DKA200:[KITS]BASIC016.ZIP;1
testing: basic016/documentation/ OK
testing: basic016/kit/ OK
testing: basic016/documentation/basic016_cover.ps OK
testing: basic016/documentation/basic016_cover.txt OK
testing: basic016/documentation/basic016_iguide.ps OK
testing: basic016/documentation/basic016_iguide.txt OK
testing: basic016/documentation/basic016_spd.ps OK
testing: basic016/documentation/basic016_spd.txt OK
testing: basic016/kit/basic016.a OK
testing: basic016/kit/basic016.b OK
testing: basic016/kit/basic016.c OK
testing: basic016/kit/basic016.d OK
testing: basic016/kit/basic016.e OK
testing: basic016/kit/basic016.f OK
testing: basic016/kit/basic016.g OK
testing: basic016/kit/basic016.h OK
testing: basic016/kit/basic016.i OK
No errors detected in compressed data of DKA200:[KITS]BASIC016.ZIP;1.
$
malmberg August 04 2022 No more VAX hobbyist licenses. Community licenses for Alpha/IA64/X86_64 VMS Software Inc. Commercial VMS software licenses for VAX available from HPE.
ozboomer July 20 2022 Just re-visiting.. No more hobbyist licenses? Is that from vmssoftware.com, no 'community' licenses?
valdirfranco July 01 2022 No more hobbyist license...sad
mister_wavey February 12 2022 I recall that the disks failed on the public access VMS systems that included Fafner
parwezw January 03 2022 Anyone know what happened to FAFNER.DYNDS.ORG? I had a hobbyist account here but can longer access the site.
gtackett October 27 2021 Make that DECdfs _2.1A_ for Vax
gtackett October 27 2021 I'm looking for DECdfs V2.4A kit for VAX. Asking here just in case anyone is still listening.
MarkRLV September 17 2021 At one time, didn't this web site have a job board? I would love to use my legacy skills one last time in my career.
malmberg January 18 2021 New Hobbyist PAKs for VAX/VMS are no longer available according to reports. Only commercial licenses are reported to be for sale from HPE
dfilip January 16 2021 Can someone please point me to hobbyist license pak? I'm looking for VAX/VMS 7.1, DECnet Phase IV, and UCX/TCPIP ... have the 7.1 media, need the license paks ... thanks!
