HCL VersionVault and the NFS automounter

HCL VersionVault is compatible with the NFS automount facility that is supported on Linux and the UNIX system, though certain guidelines apply.

Note: This topic is about mounting VOB storage, not to be confused with the automounting of VOBs. For information about automounting VOBs, see Automounting VOBs.
Hosts that run Linux or the UNIX system typically use the automounter to mount exported file systems, including VOB and view storage directories, on remote hosts. Because various HCL VersionVault commands must derive a global pathname to a VOB or view storage directory that has been (or will be) mounted by the automounter, you may need to understand the details of how your automounter constructs the local mount points through which remote storage is accessed.
Note: Implementations of automount vary. For information about automount, see the reference information for your supported platform.

Automounter maps and mount points

You can use direct or indirect automount maps to access remote VOB or view storage. The heuristics used to construct a global pathname assume that all hosts use a common automounter map. If you create a VOB or view on a host that does not use an automounter map, you must take additional steps to ensure network access to the VOB or view. For more information, see The automounter on Linux or the UNIX system does not use the hosts map.

When constructing a global path to remote VOB or view storage, HCL VersionVault attempts to access the remote host by using a pathname that begins with one of the standard NFS mount points /net, /hosts, or /nfs. For example, to construct a global path to VOB storage on a host named mars, HCL VersionVault starts with the pathname /net/mars, and then adds the name of the VOB storage directory specified in the mkvob command or VOB creation wizard. If it cannot access the specified storage directory using this path, it tries the other standard mount points.

Specifying nonstandard mount points

You can use the environment variable CCASE_GPATH_HINTS to specify one or more mount points for HCL VersionVault to try before the standard mount points are used. Set this environment variable to a value that is a colon-separated list of mount points to try when constructing a global path to VOB or view storage on a remote host running Linux or the UNIX system. For example, if you set CCASE_GPATH_HINTS="/vob_servers:/view_servers", HCL VersionVault attempts to construct a pathname to a remote NFS directory starting with the mount point /vob_servers; if a valid global path cannot be constructed from that mount point, /view_servers is tried next. If none of the mount points listed in CCASE_GPATH_HINTS can be used to construct a valid global path, HCL VersionVault tries the standard mount points.
Note: You can also set CCASE_GPATH_HINTS to a value of "" (null) to force cleartool commands that create VOBs or views to use an explicit global storage path as specified in the command-line interface. For more information, see the env_ccase, mkvob, mkview, and mkstgloc reference pages.

Specifying a nonstandard mount directory

On most Linux or the UNIX system platforms, the automounter mounts remote file systems directly on one of the standard mount points. Some automounters must mount remote file systems under /tmp_mnt and then access them through a symbolic link to /tmp_mnt from /net or one of the other standard mount points. If an HCL VersionVault host has an automounter that creates this kind of symbolic link to some other mount point, you must specify the name of that mount point in the file /var/adm/hcl/versionvault/config/automount_prefix. For example, if the automounter uses /autom instead of /tmp_mnt, place this line in the automount_prefix file:
/autom