Craig A. Berry wrote:
At 7:10 PM -0400 7/22/04, Thomas Pfau wrote:That's what I was afraid of. I'm really surprised it built and tested as clean as it did.
At work, our application still runs on VMS 6.2 on VAX systems. I installed perl 5.8.0 last year and don't remember having any problems. Alas, I must have deleted the source tree after a successful build because I can't find them or any traces of the build other than the PERL_ROOT directory tree.
Anyway, I recently found SIMH (http://simh.trailing-edge.com/) and decided to give it a workout. I figured I'd install 6.2 first since that's the version I'm familiar with and maybe later I could move to 7.3. A new VMS install needs a new perl install so I figured I'd try to build 5.8.4. I hit errors during the build on both SIMH and the real VAXen at work.
5.8.5 came out a couple of days ago but is unlikely to help with your
situation as no recent testing I'm aware of has been done on VAX or
on pre 7.x VMS.
As far as I can tell, none of the tests exercise this function. All I know is it compiled clean. I've never used out-of-band data on a TCP socket before so I don't know if I can come up with a good test for this. It might be better to just make the routine unsupported on VMS pre-7.x unless someone needs it and can write a good test.The first problem I hit during the build was an attempt to use ioctl(SIOCATMARK). VMS 6.2 doesn't support ioctl(). I ended up writing a vms_siocatmark() function using a QIO to plug into [.ext.io]io.xs.
Good golly. That sounds like a seriously useful bit of backporting
for folks in a similar situation. It shouldn't be too hard to
determine from the appropriate appendix to the CRTL manual what
particular #ifdefs should go around this code to get it into the
sources.
The second problem was with Time::HiRes. Although VMS 6.2 does not have many (if any) of the functions needed by this module, it's included in the default list of modules to build. I reconfigured without this module but the test phase still tried to reference it.
That should be a simple matter of adding lines similar to the following in the BEGIN block of the test:
require Config; import Config;
if ($Config{'extensions'} !~ /\bTime\/HiRes\b/) {
print "1..0 # Skip: Time::HiRes was not built\n";
exit 0;
}
I'll plug that in and see if it works.
It seemed to be spitting out some errors where MMK TEST would just say 'FAILED'.Lastly, several tests failed. MMS TEST doesn't reveal much information about failures so I tried using harness.
harness is the canonical unixy way to get more details. The idiomatic VMS way (documented in README.vms) is, for example:
$ @[.vms]test .exe "" -"v" [.op]pack.t
I hope they haven't broken harness on VMS since the last time I tried it.
I think VMS 6.2 is 11 years old (good guess!). Last year we went looking into this and found it was 10 so it's at least nearing 11.There were several things along the lines of 'unrecognized command verb \ECHO\' but also some real failures. op/pack failed with what appears to be a floating point overflow. Several Tie::File, Math::BigInt and Math::BigRat tests failed. I can post the errors from the build logs if anyone is interested.
Does anyone know if any of these errors are serious? Are they worth looking into or am I the last diehard still trying to use perl on VAX/VMS 6.2?
Tie::File is heavily dependent on POSIX-compliant seek()
functionality in the CRTL. It's totally unsurprising that this
doesn't work in a version of VMS that is, what, 10 or 12 years old
and long since off the vendor's support matrix. As far as I know, no
other core packages depend on Tie::File, so if you don't intend to use it
explicitly, you should be fine.
The various math-related problems most likely come from D_FLOAT notI think some of the harness output seems to support this. Maybe I'll leave a G_FLOAT build running over the weekend and see what happens.
representing the floating point ranges that tests expect. Whether
this will cause you problems really depends on what sort of floating
point work you may be doing. You can try configuring with G_FLOAT
(instructions in README.vms) and see if that makes a difference. I
believe I was supposed to make G_FLOAT the default on VAX, but I
either got busy, forgot, decided I shouldn't without the ability to
test it, or all of the above.
I'll dig into the pack problem a little and see what I can come up with. That one's pretty important to me.
