With the upgrade, I am getting two failures in blead on OpenVMS Alpha.
Built with Non threaded build, large files, and experimental symbolic
link support on an ODS-5 volume.
ODS-5 volume means that the traditional name mangling of extra dots in
the filename on disk to be C<_> is not always being done, and my source
tree is identical in filenames, including case to that on a UNIX platform.
ext/Compress/Zlib/t/03zlib-v1......................FAILED at test 398
not ok 398 - flush not ok
# Failed test 'flush not ok'
# at [-.ext.compress.zlib.t]03zlib-v1.t line 1184.
not ok 399
# Failed test at [-.ext.compress.zlib.t]03zlib-v1.t line 1185.
# got: '0'
# expected: '-2'
not ok 400 - flush ok
# Failed test 'flush ok'
# at [-.ext.compress.zlib.t]03zlib-v1.t line 1186.
ok 401 - Closed
# Looks like you failed 3 tests of 401.
I am in the debugger, and the call to flush is looking up an error to a
previous operation and getting "stream error".
I am in both the Perl debugger and the VMS code debugger at this point,
running the commands manually through the Perl debugger.
Any hints on where I should be setting code breakpoints to look for what
is causing this error? Or any hints at all?
I will not be able to investigate further for at least 10 hours.
Be aware of an issue that the length of a file as reported by stat() on
VMS may be larger than the actual amount of bytes that are readable in
the file. This is due to the way that VMS stores the files on disk, and
the only work around is to actually read the file and count the bytes.
I do not know if that may be an error, but it has tripped up other
programs ported from UNIX.
ext/Compress/Zlib/t/14gzopen.....................FAILED at test 30
I have not started looking at the 14gzopen issue yet.
-John
[EMAIL PROTECTED]
Personal Opinion Only
