I wrote to Craig A. Berry:
> > Ah, I see the patch now. It's actually not such a wacky value:
> >
> > $ write sys$output f$message(114762)
> > %RMS-E-DNF, directory not found
> >
> > or
> >
> > $ sea rmsdef.h rms$_dnf
> > #define RMS$_DNF 114762
[snip]
> So it didn't quite help. However, with this sort of thing I could redo
> my hack in terms of the RMS$_DNF macro (although this does diff not check
> for __ALPHA, the __DECC_VER or __VMS_VER like my previous patch):
>
> $ gdiff -u [.vms]vms.c;-1 [.vms]vms.c
> --- [.vms]vms.c;-1 Mon Mar 13 16:58:28 2000
> +++ [.vms]vms.c Mon Mar 13 16:58:39 2000
> @@ -4668,7 +4668,7 @@
> if ((privused & CHP$M_READALL) && !curprv.prv$v_readall) return FALSE;
> return TRUE;
> }
> - if (retsts == SS$_ACCONFLICT) {
> + if (retsts == SS$_ACCONFLICT || retsts == RMS$_DNF) {
> return TRUE;
> }
> _ckvmssts(retsts);
> end of diff.
A hunch about the configure process on VMS crept up on me this afternoon.
What values do you get from:
$ perl -e "print(join(""\n"",@INC,''))"
Are there any "/perl_root/", that is, unixy values in there? For extra
credit: which version of post 5.005_5* perl did the unixy dir specs show
up in your @INC?
I realize that I am the one who saw the problem hence I should answer
the question that I just posed but I am on FreeBSD now with no VMS
access til later (boo hoo :-(. I think we may need to get rid of the unixy
ones. Follow the ''perl_prefix' variable in [.vms]subconfigure.com and
see where it winds up in the config_h.sh + config.sh -> config.h process.
Peter Prymmer