On Monday, July 21, 2003, at 12:03PM, <[EMAIL PROTECTED]> wrote:
>!>lib/Net/Ping/t/190_alarm.............FAILED at test 6
>!>lib/Net/Ping/t/450_service...........FAILED at test 8
>!
>!Those are skipped for folks running TCP/IP services
>!because there is no echo service by default and that's
>!what Net::Ping is based on. With Multinet they run but
>!fail because there is unixy file locking done on sockets.
>
>Indeed, they both have error messages similar to:
>
>$ perl lib/Net/Ping/t/190_alarm.t
>1..6
># Running under perl version 5.008001 for VMS
># Current time local: Mon Jul 21 12:56:45 2003
># Current time GMT: Mon Jul 21 16:56:45 2003
># Using Test.pm version 1.24
>ok 1
>ok 2
>ok 3
>ok 4
>ok 5
>not ok 6
># Failed test 6 in lib/net/ping/t/190_alarm.t at line 52
># lib/net/ping/t/190_alarm.t line 52 is: ok $@ =~ /alarm works/ or die $@;
>fcntl F_GETFL: invalid argument at lib/net/ping/t/190_alarm.t line 43
>%SYSTEM-F-ABORT, abort
>
>Does the $Config{'d_fcntl_can_lock'} variable have anything
>to do with this behavior
Yes, that's exactly the feature we don't have.
> and might we skip the last of 190_alarm.t
>and 450_service.t if it is C<undef> as in my build?
In the short run marking individual tests as to-do would be better. What's really
needed of course is to root around in Net::Ping and see if the unixy file locking is
even necessary on VMS. It generally isn't with files, but I've no idea how sockets
are handled.
