No such file for OpenVMS connected to Debian NFS

Management of storage subsystems: SAN, volume shadowing, logical disks, file systems, and more.
Post Reply

Topic author
garyrevell
Contributor
Posts: 13
Joined: Thu Nov 19, 2020 7:15 am
Reputation: 0
Location: Basingstoke, UK
Status: Offline
Contact:

No such file for OpenVMS connected to Debian NFS

Post by garyrevell » Thu Jan 21, 2021 4:49 am

Here's my original post in another similar topic with a reply from Hein's questions:
We're using NFS mounts from a Debian server on our OpenVMS system and occasionally experience the "No such file" error, and this causes compilations to fail as source or include files are missing.
  • What's the usual cause of these errors?
  • How can we stop them occurring/fix them?

Typically it's only a 5-10 files out of hundreds that give this error.

Thanks

Gary
and this is Hein's reply:
Gary, the older base topic is about a very specific problem case.
For the OP a simple DIREXXX (XXX to prevent to pick up symbol definitions) would show the file, but any action on the file such as DIRECTORY/SIZE would fail with no-such-file .
Is the same situation true for your case?
What were your exact errors SYS$_NOSUCHFILE or RMS$_FNF ?

You may want to create a fresh post for your specific problem

Please include
- exact error message(s)
- why you think the files are looked for in the place they are looked for ( Logical names? Search lists?)
- how the files should have gotten there (always there? freshly compiled? freshly copied? SET FILE/ENTER ?)
Answers to your questions:

Please include
- exact error message(s)

For example here's a file that gives the error:

$ dir DNFS100:[GREVELL.xxxxxx.source]termco.inc

Directory DNFS100:[GREVELL.xxxxxx.source]

TERMCO.INC;1 no such file

Total of 1 file, 0KB
$


- why you think the files are looked for in the place they are looked for ( Logical names? Search lists?)

The files are either include files used by the Pascal compiler to create the .OBJs or .PAS/.C source files
that can't be opened due to the error.


- how the files should have gotten there (always there? freshly compiled? freshly copied? SET FILE/ENTER ?)

The files are in GIT repository setup on a DEBIAN server that are then built on the OpenVMS system

Regards

Gary


mw
Member
Posts: 6
Joined: Mon Jul 06, 2020 4:38 am
Reputation: 0
Status: Offline

Re: No such file for OpenVMS connected to Debian NFS

Post by mw » Thu Jan 21, 2021 5:29 am

Not a solution for the problem, but you may be able to work around it with vGit (https://vmssoftware.com/products/vgit/), which is "partial OpenVMS implementation of Git".


hein
Member
Posts: 5
Joined: Fri Dec 25, 2020 5:20 pm
Reputation: 0
Status: Offline

Re: No such file for OpenVMS connected to Debian NFS

Post by hein » Thu Jan 21, 2021 9:54 am

Ok, so the new subject highlighted gave critical info in that NFS is involved.
Thanks for calling that out as that I kind of skipped over that info in the initial reply.

I'm afraid that I forgot everything I every knew about NFS, which was not much to begin with.

Anyway, so the files are not actually OpenVMS files but they are stored on a remote (Debian) server with the NFS client mimicking the OpenVMS file system best it can given the differences in available file attributes.

Hopefully others can provide more useful suggestions, such as "mw"'s git link.

IF these were 'normal' Files-11 files and directories the follow up would be along the following lines, but this probably does not apply here:
---
From an OpenVMS file system perspective you do appear to have a dangling directory entry judging by the ";1" it picked up from the file name.
To make that more clear please execute $ direXXX as requested.
That XXX is a random string, use $direBLAH if you prefer or first SHOW SYMB DIR* and delete any found to avoid picking up 'helpful' directory re-definitions which hurt when the file does not exist.

Next try $ DIREXXX /FILE <your-file-spec>
That should return a FILE-ID (file-number, sequence-number, relative-volume-number) whether the file actually exists or not. The fileID corresponds with a Unix Inode number.

Any chance there are VOLUME SETS involved? I guess that question is meaningless if the files are hosted on Unix.

Are the files somehow anywhere else on the system/disk?
For a 'normal' volume one could check quickly with $ MCR DFU SEARCH/FILE=termco.inc DNFS100:
Again, that probably does not work for NFS, and a (slow?) $DIREXXX/file DNFS100: [*...] could be tried.

Hope this helps a little bit.
Regards,
Hein


My questions were all assuming This was all

Post Reply