I've compressed (spool compress/method=dcx_axpexe), a lot of files (about 1GB each), of our experiment, now we've a more disk space and i've started to decompress these files, but it's impossible to decompress thousands of them. I receive this error:
$ spool decomp HG0203C007.EVEN-DCX_AXPEXE;1 dkb2:[gianni]
%FTSV-I-STADCMP, starting decompression of file DKA5:[EXPLORER]HG0203C007.EVEN-DCX_AXPEXE;1 to output file DKB2:[GIANNI]HG0203C007.EVEN;
%FTSV-W-DCMPFAIL, decompression routine aborted while processing DKA5:[EXPLORER]HG0203C007.EVEN-DCX_AXPEXE;1
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000007AEAEF30, PC=FFFFFFFF801D0984, PS=0000001B
%W, fatal decompressor error
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000007AEAD8E0, PC=FFFFFFFF801D0984, PS=0000001B
%FTSV-W-NOTCMP, DKA5:[EXPLORER]HG0112C006.EVEN-DCX_AXPEXE;1 not compressed or unknown compression method - decompression skipped
Please, can anyone help me?
Thank you very much,
thanks for your help!
yes, it work fine, I've problems only with more old files, i.e. files compressed from the year 2000 to the year 2004, maybe they are "degraded" or I've compressed these files wit a more old FTSV software?
N.B. some of these files had been decompressed without problems.
Thanks again, I'ld like to remember that these files are very important for analisys of our experiment data.
I've got an old VAX running with FTSV V3.0-001 and SYS$SHARE:FTSV$COMP_*_SHARE.EXE files from 31-JAN-1994.
I would not expect an OpenVMS product to 'degrade' or even produce newer versions, which are NOT upwards compatible with older versions. This would NOT be according to OpenVMS standards !
As far as I remember, FTSV grew out of some 'midnight' project, which some people had written for transferring files through the sometimes unstable corporate-wide global DECnet network during DEC times.
Did you try to further diagnose those ACCVIOs ? Maybe by using SET PROC/DUMP to get a process dump ? Or by using SET WATCH FILE/CLASS=MAJ to find out which files were being opened ? Or by examining the failing instructions with SDA ? Or by running FTSV with the debugger ?
OpenVMS allows much more and deeper analysis of problems, if you know OpenVMS internals and know how to apply various troubleshooting techniques.
So you can easily answer that part of my questions. You may also want to run ANAL/IMAGE on those files to verify the integrity of the image portion.
For .EXE-DCX_AXPEXE files compressed with FTSV Version V3.0-001, the FIRST 98 blocks seem to be identical for all files and therefore must represent the executable auto-decompression image. The compressed file data seems to start at VBN 98.
These files should have 512 byte fixed length records.
Please verify this information against the files you can successfully decompress and also against those files, where the decompress operation results in errors.
Please be patient but I'm the last member of my group the remember the bare minimum for manage an OpenVMS system,
about your questions:
1 - I don't know how use SET PROC/DUMP
2 - in Help, there is'nt SET WATCH FILE
3 - The files are on an Alpha Server 1000A with OpenVMS 7.3-2 (but maybe that in the year 2001 the OpenVMS was an early version), on a Infortrend RAID
4 - the FTSV was allways the same: V3.0-001
5 - Yes, I've copied these files from a disk to another of the same RAID
Can I send you 4 txt files of a bad file and of a good files? my mail address is: [email protected]
Thank you a lot for your help!
I installed FTSV V3.0-001 on OpenVMS Alpha V8.2 and created a .xxx-DCX file. Then I patched that file and ZEROed just some longword in the compressed data section of that file (beyond VBN 98) and then tried to de-compress the file. This is what I get:
the ACCVIO itself happens in a system routine (MESSAGE_ROUTINES+089A4). The failing virtual address points to a P1 space address in the CLI data area, which is protected from read access from USER mode. This explains the ACCVIO.
But this only is a secondary effect, which I can reproduce when corrupting a single longword in the compressed data section of the compressed file. There probably is some software problem in FTSV related to error handling or exception or message handling, when something bad happens during data decompression.
Your task would be to find out, how and to which extent your old files have been corrupted and whether it might be possible to at least recover some data from them.
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!