At 7:16 PM -0500 10/30/00, Peter J. Farley III wrote:
>At 02:58 PM 10/30/00 -0800, Peter Prymmer wrote:
><Snipped>
>>This was with the perl@7483 kit: the build was fine (no need to
>>mess with vms/vms_yfix.pl), but there were two test failures:
>>
>>[.lib]st-lock...........FAILED on test 1
>
>Peter, does VMS have the same lack of functionality for file locking
>that DJGPP/DOS does (i.e., no working versions of flock or lockf or
>fcntl(...,F_SETLK/W,...))? If so, look at the changes I helped put
>into both t/lib/st-lock.t and ext/Storable/Storable.pm for DJGPP.
>Essentially, the changes made the locking versions of store/retrieve
>and the tests for them no-ops if ($^O eq 'dos'). If VMS has the
>same problem, it would be easy to add VMS to those no-op tests.
Thanks for the tip; I'll try to take a look at Storable and see if
omitting locking seems like the right thing to do for VMS.
My punishment for not getting a patch out yet is having to explain
again how all this works on VMS. There's no flock() at all, nor, I
believe lockf(). It usually doesn't matter because files are locked
by default; if you want shared access you have specify it explicitly.
fcntl() exists on some versions of the C RTL from the last two years
or so, but it doesn't do F_SETLK/W. It does have those defined in
the header, but it doesn't do anything with them, thus fooling the
test for them in pp_sys.c where it tries to see if fcntl() can
emulate flock(). We should probably have something in configure.com
that checks to see if (when fcntl exists) F_SETLK and F_SETLKW
actually work and undef's them if not; this would make the test in
pp_sys.c realize that fcntl() cannot emulate flock().
BTW, I get "All tests successful" with perl@7483 using DEC C V5.2-003
on OpenVMS Alpha V7.1. I do notice, however, that with perl -V its
identity lags slightly behind:
Locally applied patches:
DEVEL7481
--
____________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
