Adding an NFS share that persists through startup

[JeradMason]

Hello,

I've added an NFS share through tcpip ( system=OpenVMS V8.4-2L1 ) and I want to know that it will persist on both the server and client. Are there any files, such as SYS$MANAGER:SYSTARTUP_VMS.COM, that I should modify to make sure the proxys, exports, mounts, etc. are still there on reboot? Apologies, I've read so many documents up to this point, and I see nothing about persistance. 

Best Regards,

Jerad

[JeradMason]

What I ended up doing (Would still like to know the answer, as I'm not sure this was necessary.):

Within SYS$MANAGER:SYSTARTUP_VMS.COM, after the TCPIP service was started, I added the line  "@SYS$STARTUP:TCPIP$NFS_CLIENT_SYSTARTUP.COM". 

Within SYS$STARTUP:TCPIP$NFS_CLIENT_SYSTARTUP.COM I added my mount command.

I am making the assumption the proxy and export will remain after a reboot. If the share disappears next time a reboot is necessary (these are live systems, can't test) I'll add more lines.

[Steven Schweda]

> [...] Are there any files, such as SYS$MANAGER:SYSTARTUP_VMS.COM, that
> I should modify to make sure the proxys, exports, mounts, etc. are still
> there on reboot? [...]

   I do very little with NFS, so I know nothing, but it seems that at
least some of that stuff can be made to persist:

      TCPIP HELP SET CONFIGURATION MAP

   You might need to add some mount commands to SYSTARTUP_VMS.COM, say,
if the automounter isn't engaged.

> [...] I added the line "@SYS$STARTUP:TCPIP$NFS_CLIENT_SYSTARTUP.COM".

   "TCPIP$NFS_CLIENT_STARTUP.COM"?  Knowing nothing, I might expect
that to be run automatically (by something?).  And I wouldn't fiddle
with it.  If you don't see an obvious user-modify-here section, then I'd
fiddle elsewhere.

> [...] I am making the assumption the proxy and export will remain
> after a reboot. [...]

   The proxy database should persist.  "export" is not an NFS thing on
VMS-TCPIP, as I recall.

   I seem to have some nonvanishing MAPs, left-over from different
hardware, with disk names which don't match the current disks, so my
OPERATOR.LOG includes complaints like:

%%%%%%%%%%% OPCOM 23-JUN-2019 20:21:35.41 %%%%%%%%%%%
Message from user TCPIP$NFS on ITS
%TCPIP-E-NFS_BFSCAL, operation MOUNT_POINT failed on file /dka1

   There currently is no DKA1, but:

ITS $ tcpip show conf map
            Filesystem Map Configuration
Pathname                                Logical File System
 
/dka1                                   ITS$DKA1:
/dka4                                   ITS$DKA4:

   So, I'd guess that someone is trying to do some (server) MOUNT
operations based on those data.  I see no explicit "DKA1" in any
"sys$startup:*.com", so I doubt that it was my idea.

[Volker Halle]

From the TCP/IP Services for OpenVMS Management manual:

SYS$STARTUP:TCPIP$NFS_CLIENT_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when the NFS client is started.
For example, use this file to store systemwide MOUNT commands.

Volker.