[Info-vax] Howto make OpenVMS remember "SET CONFIGURATION MAP"

[Marco Beishuizen]

On Sun, 16 Jul 2017, the wise Stephen Hoffman via Info-vax wrote:

> SET CONFIGURATION MAP and SET CONFIGURATION NOMAP is supposed to be the 
> permanent version of the MAP and UNMAP stuff.  Which implies you have 
> either found a bug, that there's an error here that's being suppressed 
> or some odd logical names, or there's something odd in the local 
> configuration that's discarding or otherwise overwriting the NFS 
> mapping.

Didn't do anything weird afaik. The node is called "OVMS1" and the 
exported filesystem is "/vmsdisk".

> Or maybe that the NFS services aren't being correctly auto-started, and 
> are tossing some errors somewhere in a log file?  Some of the TCP/IP 
> Services servers sort-of work, when there are errors in the particular 
> service-specific startup procedures for the service or sometimes even 
> when the service is not configured.  See if the NFS server log file 
> provides any insights here, if you've not already looked there.  The NFS 
> server chatter is often stored in SYS$SYSDEVICE:[TCPIP$NFS], but can be 
> relocated elsewhere. (Probably not for this particular case, but 
> sometimes check for NFS errors on the remote end of the NFS mount too, 
> as sometimes that can provide some insight into the failure.  Sometimes 
> client-side errors can also provide confusion, unfortunately.)

Looked into all logfiles in SYS$SYSDEVICE:[TCPIP$NFS], but only messages 
are from a few months ago when NFS wasn't configured correctly yet. 
There are no new error messages when mounting the exported filesystem 
at this point. The NFS clients also don't give any errors since it all 
seems to work.

> Obvious brute-force: implement and issue the MAP commands during each 
> startup, after the NFS server has been started.

Hmm, was hoping to avoid this but it's not a very big deal either.

Thanks for the help anyways.

Regards,
Marco

-- 
The greatest of faults is to be conscious of none.