On Thu, 24 May 2001, Craig A. Berry wrote:
> At 4:15 PM +0100 5/24/01, BAZLEY, Sebastian wrote:
> >I cannot now reproduce the NFS/DECNET problem I attributed to
> >sys$check_access, but I know we had a problem when we moved from 5.4_3 to
> >5.5_2 - we ended up using 5.4_3 for that particular script.
> >
> >Perhaps changes to NFS / DECNET software versions are responsible for making
> >it work now?
To Sebastian: the poor caching and general chaos that ensues from using
just about any NFS client on VMS (most of my experience is with UCX and
Multinet) means that you have to use NFS mount points with gentle care.
If you run a program once and it attempts any sort of read of an NFS mount
it may very well fail, eg.
$ directory disk$NFS1:[foo.bar]
%DIRECT-E-OPENIN, error opening
DISK$NFS1:[FOO.BAR]*.*;* as in put
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file
$ directory disk$NFS1:[foo.bar]
Directory DISK$NFS1:[FOO.BAR]
MYAPPLES.DIR;1 1 23-MAY-2001 22:29:17.00
ZLEMODEN.DIR;1 1 23-MAY-2001 22:17:15.00
Total of 2 files, 2 blocks.
Note that NFS is defined in terms of UDP packets and reassmbling them
in proper order is up to the higher level software. NFS file sharing is
frought with trouble, particularly on non unix machines like VMS and
Windows.
> There are various potential pitfalls here. For one thing, we use
> lib$fid_to_name in some cases (see Perl_cando()), and lock IDs in
> other cases (see encode_dev()). I don't think either will work for
> remote DECNET nodes, much less NFS.
To Craig:
Just out of curiosity, other than parsing the output of
`DIRECTORY/FULL $file`; how does one invert lib$fid_to_name()? There does
not seem to be a lib$name_to_fid() library routine.
Peter Prymmer
