At 1:40 PM +1100 11/28/02, Keirnan, Paul wrote:
>Yesterday I downloaded Perl 5.8.0 onto an AlphaServer ES40 running
>OpenVMS V7.3-1.
>My compiler is Compaq C V6.4-008.
>I am using an ODS-2 volume on a fibre channel SAN.
assorted resolved issues snipped
>This fixed the first two, leaving ...
>
> $ @[.VMS]TEST .exe "" "-v" [-.lib]vmsish.t
> ok 21 - use vmsish qw(time)
> not ok 22 - (time) UTC:1038445842 VMS:1038445842
> LIB/VMSISH....FAILED at test 22
>
>Looking at the code in vmsish.t, I don't understand lines 115-125
>
> {
> use_ok('vmsish qw(time)');
> $vmstime = time;
> @vmslocal = localtime($vmstime);
> @vmsgmtime = gmtime($vmstime);
> $vmsmtime = (stat $0)[9];
> }
> $utctime = time;
> @utclocal = localtime($vmstime);
> @utcgmtime = gmtime($vmstime);
> $utcmtime = (stat $0)[9];
>
>$vmstime and $utctime end up with the same value,
>so line 133 will fail if SYS$TIMEZONE_DIFFERENTIAL is greater than 10 seconds.
>
>And, $vmsmtime and $utcmtime end up as undefined.
>
>Also line 133 should really be testing an absolute result
>i.e. abs($vmsval - $utcval + $offset) <= 10
This is something that definitely needs looking into. I think we
frequently see failures here for non-western time zones, or perhaps
it's anywhere SYS$TIMEZONE_DIFFERENTIAL is positive rather than
negative. Thanks for the report.
>Overall, quite successful, and as a Perl novice I learnt a fair bit
>about how the build environment is put together.
Well, you sure got a heck of a lot farther than I did the first time
I tried to build it.
>====================================================================
>
>Could I suggest for README.VMS
>Add to the list of dangerous logicals
>
> SYS "LOGICAL"
> UTIL "LOGICAL"
The configuration process does check for these and warn you if they
exist, but yes, it would be good if the docs also mentioned them.
>Under "Testing" or "CAVEATS" add something like
>
> Some tests will fail if the directory structure is not owned
>by the process doing the tests.
I guess we never gave much thought to testing under an account
different from the one that did the build. Was there a particular
reason you did that? As of 5.8.0 the test suite takes considerable
care to downgrade privs to the minimum required, so you're unlikely
to run into trouble testing from a privileged account. However, I
can appreciate that a savvy system manager might prefer not to do so.
In that case I'd recommend building and testing under a non-prived
account and then logging in as SYSTEM to do the install; you
shouldn't see any ownership problems if you do that.
>AND
>
> If you have SYSTEM defined logicals for PERL_ROOT and
>PERLSHR, then these will interfere with the test phase. It is
>easiest to deassign all logicals '*PERL*'.
Strictly speaking I don't think that's true, and in fact Perl depends
rather heavily on the logical name features that allow any given
process to have a quite different view of the world than other
processes on the system. I think this appeared to be true for you
not because system logicals got in your way but because your version
of PERL_SETUP.COM refused to create its own set of process logicals.
>The following was modified so that the same command file could be
>used by SYSTEM at system startup, and by SYLOGIN.COM for a user
>login.
custom PERL_SETUP.COM snipped.
You are quite right that PERL_SETUP.COM is really doing two different
types of things. It's setting up symbols that are by their very
nature process-specific, but it's also defining the PERL_ROOT and
PERLSHR logical names that a system manager may well want to define
system-wide. But this procedure as it exists is really just a shim
that's used for testing and installation and it only serves
production use by providing examples of the symbol and logical
creations. I think if we wanted to provide something that's suitable
for production we would create a PERL_SYMBOLS.COM that defines the
symbols and could be run from SYLOGIN.COM or individual LOGIN.COM
procedures, and then also a PERL_STARTUP.COM that does the logical
name definitions and possibly also installs the images as known
images.
In favor of leaving things the way they are is the fact that there
are only two logical names and it's not that heavy a burden to add
two lines to SYLOGICALS.COM. I'm open to rethinking this but I don't
believe trying to make PERL_SETUP.COM serve all purposes is the best
way to go.
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
