Home · Articles · Downloads · Hobby Wear · Forums · Web Links · News CategoriesWednesday, September 19, 2018
Navigation
Home
Articles
Downloads
Hobby Wear
FAQ
Forums
Web Links
News Categories
Contact Us
Photo Gallery
OpenVMS Bigot
Search
Users Online
Guests Online: 9
No Members Online

Registered Members: 7,202
Newest Member: cliff0fleming
PdfFactory Pro Enterprise 2.31, MATFOR 4.00.061031 in Lahey Fortran, Adobe PhotoShop 9.0 CS2 oem, Trend Micro InterScan VirusWall 6.0, Adobe Acrobat 7.0 Professional sale, Salon Iris 5.05, Drafix Pro Landscape 11.2, oem Adobe PhotoShop CS 8.0 cheap buy, Catia 5 R12 P3 with SP2, Mcafee Secure Internet Gateway 4.5, oem Adobe Acrobat Professional 8 oem, Visual UML 4.1 Developer Edition, sale Adobe CS3 Design Premium Vol for Mac low price, Nuance Dragon Naturally Speaking 9.0 Professional With SP1, Adobe After Effects Plugins, low price AutoCAD 2006 cheap buy, Avid NewsCutter XP 3.8, The Movie Library 1.7.11, oem Adobe Creative Suite Premium Edition 2.0, ProFlyers 6.0 PDF Forms for Adobe Acrobat, PTC Pro Engineer Routed Systems Designer 5.0, sale DVDXCopy Platinum 4.0.38, CyberBizPlan v1.0.165 WinAll, NeverCenter Silo 1.16b, cheap buy AutoCAD 2005, Norton Save And Restore 11, sale Adobe Creative Suite 3 Design Premium sale, Adobe Premiere Plugins Collection 2007, cheap buy Adobe Creative Suite Premium Edition 2.0 for Mac sale, Active Desktop Calendar 6.5.061124, sale Adobe Acrobat 6.0 Professional, X-Rite MonacoPROFILER Platinum 4.8, EmailUnlimited 6.1 Win98NTME, oem Adobe Photoshop CS3 Extended sale
Sponsors
Island Computer
View Thread
OpenVMS Hobbyist Program | Alpha Systems Forums | FreeAXP
Page 2 of 2 < 1 2
Author RE: CRC errors?
malmberg
Moderator

Posts: 469
Joined: 15.04.08
Posted on June 04 2010 02:28
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>
Author RE: CRC errors?
VolkerHalle
Member

User Avatar

Posts: 96
Location: Germany
Joined: 02.04.10
Posted on June 04 2010 03:49
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.
http://www.invenate.de
Author RE: CRC errors?
astrodanco
Member

Posts: 36
Joined: 04.03.10
Posted on June 04 2010 06:19
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
Author RE: CRC errors?
VolkerHalle
Member

User Avatar

Posts: 96
Location: Germany
Joined: 02.04.10
Posted on June 04 2010 06:35
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.
http://www.invenate.de
Author RE: Testing UNZIP
johncookson
Member

Posts: 26
Location: Canada
Joined: 04.12.08
Posted on June 04 2010 08:53
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.
Author RE: Testing UNZIP
johncookson
Member

Posts: 26
Location: Canada
Joined: 04.12.08
Posted on June 04 2010 09:18
Volker

Here is the same test performed with FreeAXP 283.

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.
$

JohnC
Author RE: CRC errors?
VolkerHalle
Member

User Avatar

Posts: 96
Location: Germany
Joined: 02.04.10
Posted on June 04 2010 20:14
JohnC,

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
http://www.invenate.de
Author RE: CRC errors?
malmberg
Moderator

Posts: 469
Joined: 15.04.08
Posted on June 05 2010 03:16
With nocache, blocks are corrupted, but not zeroed.

For the file appdev010.zip, starting at block 118, two blocks at exactly 124 blocks apart are corrupted throughout the entire file.

The data pattern looks like nothing from the device was read for those blocks.

blocks 118, 119,
242. 243.
366, 367
490, 491
614, 615
738, 739
862, 863
986, 987
1110, 1111
1234, 1235
1358, 1359
1482, 1483
1606, 1607
1730. 1731
1854, 1855
Author RE: CRC errors?
VolkerHalle
Member

User Avatar

Posts: 96
Location: Germany
Joined: 02.04.10
Posted on June 05 2010 04:47
John,

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).

$ ld connect/replace FROG$DKA200: lda1:
$ MOUNT/OVER=ID LDA1:
$ LD TRACE LDA1:
$ COPY LDA1:<x,y>some-file.ZIP other_disk:<other_dir>
$ LD SHOW/TRACE LDA1:
...
$ LD NOTRACE LDA1:
$ DISM LDA1:
$ LD DISC LDA1:

Volker.
Edited by VolkerHalle on June 05 2010 05:05
http://www.invenate.de
Author RE: CRC errors?
Bruce Claremont
Moderator

Posts: 506
Joined: 07.01.10
Posted on June 05 2010 05:17
Thanks for all the feedback and testing. We'll have a go at reproducing the problem locally.
Author RE: CRC errors?
VolkerHalle
Member

User Avatar

Posts: 96
Location: Germany
Joined: 02.04.10
Posted on June 05 2010 06:54
Absolutely easy to reproduce:

OpenVMS E8.4, FreeAXP .283, Lenovo ThinkPad, MATSHITA DVD-RAM UJ862AC, OpenVMS Alpha V7.1-2 Operating System CD.


$ MOUNT/NOCACHE/OVER=ID dka600:

Create the following DCL procedure (updated 6-JUN-2010):


$ test_file = "dka600:<vms$common.sysexe>opcom.exe"
$!
$ vers = F$EXTRACT(1,3,F$GETSYI("VERSION"))
$ SHOW SYMB vers
$ IF vers .LTS. "8.2"
$ THEN
$ WRITE SYS$OUTPUT "cannot use /BLOCK_SIZE qualifier"
$ ENDIF
$!
$ nn=120 ! start with /BLOCK_SIZE=120
$ set noon
$loop:
$ bs = ""
$ IF vers .GES. "8.2" THEN $ bs = "/BLOCK_SIZE=''nn'"
$ WRITE SYS$OUTPUT "Using $ COPY''bs' ..."
$ copy/log'bs' 'test_file' x.x;0
$ backup/log/compare 'test_file' x.x;0
$ IF $STATUS
$ THEN
$ IF vers .GES. "8.2"
$ THEN
$ RENAME/NOLOG x.x.0 x_'nn'.good
$ ELSE
$ DELETEE/NOCONF/LOG x.x;0
$ ENDIF
$ ELSE
$ RENAME/LOG x.x;0 x_'nn'.bad
$ ENDIF
$ if nn .LT. 128 .AND. vers .GES. "8.2" ! only for V8.2 and higher
$ THEN
$ nn=nn+1
$ GOTO loop
$ ENDIF



then execute it (NOTE: the problem starts with nn=121 and does NOT occur with nn=127 and nn=128).

$ @x
NN = 120 Hex = 00000078 Octal = 00000000170
%COPY-S-COPIED, DKA600:<VMS$COMMON.SYSEXE>OPCOM.EXE;1 copied to SYS$SYSROOT:[SYS
MGR]X.X;1 (404 blocks)
NN = 121 Hex = 00000079 Octal = 00000000171
%COPY-S-COPIED, DKA600:<VMS$COMMON.SYSEXE>OPCOM.EXE;1 copied to SYS$SYSROOT:[SYS
MGR]X.X;2 (404 blocks)
%BACKUP-E-VERIFYERR, verification error for block 118 of SYS$SYSROOT:[SYSMGR]X.X
;2
%BACKUP-E-VERIFYERR, verification error for block 119 of SYS$SYSROOT:[SYSMGR]X.X
;2
NN = 122 Hex = 0000007A Octal = 00000000172
%COPY-S-COPIED, DKA600:<VMS$COMMON.SYSEXE>OPCOM.EXE;1 copied to SYS$SYSROOT:[SYS
MGR]X.X;3 (404 blocks)
%BACKUP-E-VERIFYERR, verification error for block 118 of SYS$SYSROOT:[SYSMGR]X.X
;3
%BACKUP-E-VERIFYERR, verification error for block 119 of SYS$SYSROOT:[SYSMGR]X.X
;3
%BACKUP-E-VERIFYERR, verification error for block 362 of SYS$SYSROOT:[SYSMGR]X.X
;3
%BACKUP-E-VERIFYERR, verification error for block 363 of SYS$SYSROOT:[SYSMGR]X.X
;3
NN = 123 Hex = 0000007B Octal = 00000000173
%COPY-S-COPIED, DKA600:<VMS$COMMON.SYSEXE>OPCOM.EXE;1 copied to SYS$SYSROOT:[SYS
MGR]X.X;4 (404 blocks)
%BACKUP-E-VERIFYERR, verification error for block 118 of SYS$SYSROOT:[SYSMGR]X.X
;4
%BACKUP-E-VERIFYERR, verification error for block 119 of SYS$SYSROOT:[SYSMGR]X.X
;4
%BACKUP-E-VERIFYERR, verification error for block 242 of SYS$SYSROOT:[SYSMGR]X.X
;4
NN = 124 Hex = 0000007C Octal = 00000000174
%COPY-S-COPIED, DKA600:<VMS$COMMON.SYSEXE>OPCOM.EXE;1 copied to SYS$SYSROOT:[SYS
MGR]X.X;5 (404 blocks)
%BACKUP-E-VERIFYERR, verification error for block 118 of SYS$SYSROOT:[SYSMGR]X.X
;5
%BACKUP-E-VERIFYERR, verification error for block 119 of SYS$SYSROOT:[SYSMGR]X.X
;5
%BACKUP-E-VERIFYERR, verification error for block 242 of SYS$SYSROOT:[SYSMGR]X.X
;5
%BACKUP-E-VERIFYERR, verification error for block 243 of SYS$SYSROOT:[SYSMGR]X.X
;5
%BACKUP-E-VERIFYERR, verification error for block 366 of SYS$SYSROOT:[SYSMGR]X.X
;5
%BACKUP-E-VERIFYERR, verification error for block 367 of SYS$SYSROOT:[SYSMGR]X.X
;5
NN = 125 Hex = 0000007D Octal = 00000000175
%COPY-S-COPIED, DKA600:<VMS$COMMON.SYSEXE>OPCOM.EXE;1 copied to SYS$SYSROOT:[SYS
MGR]X.X;6 (404 blocks)
%BACKUP-E-VERIFYERR, verification error for block 118 of SYS$SYSROOT:[SYSMGR]X.X
;6
%BACKUP-E-VERIFYERR, verification error for block 119 of SYS$SYSROOT:[SYSMGR]X.X
;6
NN = 126 Hex = 0000007E Octal = 00000000176
%COPY-S-COPIED, DKA600:<VMS$COMMON.SYSEXE>OPCOM.EXE;1 copied to SYS$SYSROOT:[SYS
MGR]X.X;7 (404 blocks)
%BACKUP-E-VERIFYERR, verification error for block 118 of SYS$SYSROOT:[SYSMGR]X.X
;7
%BACKUP-E-VERIFYERR, verification error for block 119 of SYS$SYSROOT:[SYSMGR]X.X
;7
%BACKUP-E-VERIFYERR, verification error for block 370 of SYS$SYSROOT:[SYSMGR]X.X
;7
%BACKUP-E-VERIFYERR, verification error for block 371 of SYS$SYSROOT:[SYSMGR]X.X
;7
NN = 127 Hex = 0000007F Octal = 00000000177
%COPY-S-COPIED, DKA600:<VMS$COMMON.SYSEXE>OPCOM.EXE;1 copied to SYS$SYSROOT:[SYS
MGR]X.X;8 (404 blocks)
NN = 128 Hex = 00000080 Octal = 00000000200
%COPY-S-COPIED, DKA600:<VMS$COMMON.SYSEXE>OPCOM.EXE;1 copied to SYS$SYSROOT:[SYS
MGR]X.X;9 (404 blocks)


Interesting VBN number patterns...

Volker.
Edited by VolkerHalle on June 05 2010 21:33
http://www.invenate.de
Author RE: CRC errors?
malmberg
Moderator

Posts: 469
Joined: 15.04.08
Posted on June 05 2010 08:20
I can not reproduce this issue with logical disks as I posted earlier.
Author RE: CRC errors?
VolkerHalle
Member

User Avatar

Posts: 96
Location: Germany
Joined: 02.04.10
Posted on June 05 2010 20:31
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
http://www.invenate.de
Author RE: CRC errors?
johncookson
Member

Posts: 26
Location: Canada
Joined: 04.12.08
Posted on June 06 2010 03:05
Volker

Your analysis is spot on.

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.
$

JohnC
Author RE: CRC errors?
Bruce Claremont
Moderator

Posts: 506
Joined: 07.01.10
Posted on June 07 2010 08:24
Problem confirmed, we are working on it.
Page 2 of 2 < 1 2
Jump to Forum:
Login
Username

Password



Not a member yet?
Click here to register.

Forgotten your password?
Request a new one here.
Member Poll
Are you going to OpenVMS Boot Camp 2016?

Yes

No

You must login to vote.
Shoutbox
You must login to post a message.

malmberg
June 26 2018
https://www.openvmshobbyi
st.com/forum/viewthread.p
hp?forum_id=10&thread_id=
2363


bhamakripa
June 24 2018
I am trying OpenVMS via SIMH. Need to get OS binaries for v7.3. Registered here but don't have any membership number yet which is needed to get license. Pls suggest what to do. I hardly know anyth

basilh
June 05 2018
Any other forum members in Perth, Australia?

LouF91
April 05 2018
ah maybe they love that!

malmberg
March 24 2018
Probably. More people hang out on the comp.os.vms newsgroup.

vaxpert
March 23 2018
I have a PE42A and other Alpha system stuff for sale. I'm in So California. Any interest out there?

goodbyespy
February 27 2018
To Prohorenko. Please, visit group OpenVMS in the ok.ru

peteherrera
February 24 2018
How much does it cost to buy a complete OpenVMS hardcopy documentation set of the latest version

prohorenko
February 17 2018
Please help to obtain the license on OpenVMS

malmberg
December 12 2017
HPE only makes the most current version of OpenVMS Alpha / IA64 /VAX available to hobbyists. When I had access to the Alliance 1 program it was the same. No public downloads are allowed by HPE.

nmbonao
December 08 2017
Is anybody knows OpenVMS 8.2 version downloadable version? or CD copy? Thank you very much

aarommes
December 02 2017
Bitcoin and Blockchain enthusiasts ( plus distributed computing ) please connec / reply: http://www.openvmshobbyis
t.com/forum/viewthread.ph
p?forum_id=130&thread_id=
2991


malmberg
September 10 2017
https://sourceforge.net/p
/vms-ports/wiki/VMSInstal
lation/ For the most part just use VMS 6.1 media instead of 7.3. But why run the older release?


DoeveR
August 07 2017
Where can I find the write up on running VMS 6.1 using the simh emulator?

Bart
March 20 2017
Happy to have found my password again!

Shoutbox Archive