Re: Experience installing on Alpha VMS 8.3

> On Feb 19, 2021, at 5:17 PM, Miller, Edward S. via vmsperl =
<[email protected]> wrote:
>=20
> As I stated presviously in this thread, our PERL installation (Alpha =
VMS 8.3) was apparently successful
> and I had my previous questions answered, thank you.

I have updated README.vms based on your comments and some other things I =
noticed reading through it:

=
<https://github.com/Perl/perl5/commit/f1bf079f5ffcef6c6cc3eed62b84949770fa=
03e9>

> I have an additional question, which is mostly academic so it's fine =
if I don't get an answer.
> Also I have some observations/suggestions related to the test =
procedures.
>=20
> My question:  if I were to do a new install on another VMS system, =
could I skip the MMK TEST step?
> Does this step do anything that is a prerequisite for the final MMK =
INSTALL step?  Does this step ever
> fail in such a way as to make the INSTALL step impossible?

As far as I can think of, nothing would prevent an installation without =
running tests.  If all your systems are on the same version of VMS and =
similar configuration (same networking set-up, quotas, volume settings, =
logical names, etc.) you're unlikely to learn anything new by running =
the test suite on a different system.

If you are on v8.4 or later, the easiest way to get a semi-recent Perl =
is to just install one of the PCSI kits from here:

<https://sourceforge.net/projects/vmsperlkit/files/>

That project also includes procedures for building PCSI kits, so if you =
have more than a handful of systems, it might well be easier to build =
your own kit and install it everywhere than to build on every system.

If you have a VSI version of VMS, they provide a kit built with the same =
kitting procedures, but last time I checked it was a fairly old version =
of Perl (5.20?).

> Some observations about the test procedures.
>=20
> At the end of the MMK TEST job the following message appears:
>     ### Since not all tests were successful, you may want to run some =
of
>     ### them individually and examine any diagnostic messages they =
produce.
>     ### See the INSTALL document's section on "make test".
>     ### You have a good chance to get more information by running
>     ###   ./perl harness
>     ### in the 't' directory since most (>=3D80%) of the tests =
succeeded.
>=20
> I have performed both of these operations.  The recommendation to run =
the HARNESS test is not
> mentioned in the README.VMS file.  I'd suggest some mention in =
README.VMS about HARNESS and the
> motivation for running it as well (in addition to MMK TEST). =20

There is some discussion of harness in [.pod]perlhack.pod and there is =
nothing really VMS-specific about it.  The default test driver is =
intended to have fewer requirements and can still run some tests when, =
for example, dynamic loading of extensions isn't working. It also aborts =
a test script on first failure rather than running the rest of the =
tests.  Harness has more requirements (notably the Test::Harness module) =
and runs every test script to completion.  I think it also reports more =
detail that may provide information about why a test failed.

> My IMPRESSION is that the information
> these tests provide is not likely to be actionable by the =
unknowledgable bloke who is just trying to
> install PERL to satisfy a user request.

Right.  The assumption is really that anyone building Perl from source =
is ready and willing to debug Perl and C code if any tests fail.  I have =
done a ton of that for a couple of decades but can never quite keep up =
with new tests that sometimes fail, often for reasons having nothing to =
do with what's being tested.  That said, I only see about 8 tests =
failing on my system, not 58.

> My experience running HARNESS:
>    It reported 64 failed tests (where MMK TEST reported 58).  Most =
were the same, but 8
>    failures were unique to HARNESS, 2 were unique to MMK TEST.
>=20
>           Tests which fail with MMK_TEST but not HARNESS:
>             io/socketpair.t  (explicitly skipped by the HARNESS job)
>             op/lexsub.t      (not mentioned by the HARNESS job)
>=20
>           Tests which fail with HARNESS but not MMK_TEST:
>             ../lib/File/Copy.t
>             ../lib/diagnostics.t
>             io/data.t
>             op/gv.t
>             op/lex.t
>             op/sigdispatch.t
>             run/switchC.t
>             run/switchx.t
>             (None of the above HARNESS failures were mentioned as =
being tested in the MMK_TEST job.)
>=20
>    I ran the 8 tests uniquely reported as failed by HARNESS thru the =
procedure
>              $ @[.vms]test .EXE "" -"v"   <testname>
>=20
>    That procedure found NO failures in any of those failed HARNESS =
tests.
>    It appears that failure is in the eye of the beholder.

There is no way to know what makes the difference without debugging in =
detail and identifying whether the problem is the test scripts, the Perl =
operators used by the test scripts, the test drivers, the local system =
environment, etc.  In particular, without detailed test output =
indicating what was expected and what the test got instead of what it =
expected, I can't even guess at what might be not working correctly.

________________________________________
Craig A. Berry

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser