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





Reply via email to