SAP directory definitions

Edit online

Read the topic for information about the SAP directories that need to be defined.

SAP global transport directory

The directory /usr/sap/trans must be globally accessible and shared. In addition, it must be exported by the NFS server.

SAP system-wide directories

The subdirectories of /usr/sap/<SAPSID>/SYS are defined at installation time as symbolic links to the corresponding subdirectories of /sapmnt/<SAPSID>, for example, /usr/sap/HA1/SYS/profile points to /sapmnt/HA1/profile. The directory /sapmnt must be created in the root file system and shared in the sysplex.

The directory /sapmnt/<SAPSID> is the mount point for the SAP system-wide file system. This file system must be exported by the NFS server such that it can be mounted by remote application server instances.

SAP local directories

On, z/OS® the directory /usr is a symbolic link to $VERSION/usr. This means that the contents of the /usr directory are different on every LPAR. However, it is not practical for the /usr/sap directory. It is recommended that you create the directory /sap in the root file system and to define symbolic links for /usr/sap to point to /sap. The symbolic links must be defined on each LPAR, that is, in each $VERSION/usr. With this approach, the subdirectories of /usr/sap are identical on all z/OS systems.

The /sap (alias /usr/sap) directory contains the mount point /usr/sap/<SAPSID> for the instance-specific file systems, such as ASCS00. These file systems do not need to be exported by NFS.

In order to get best performance in a shared zFS environment, all SAP file systems should be configured sysplex-aware (see Using sysplex-aware file systems).

SAP administrator home directory

The home directory /u/<sid>adm is shared in the sysplex.

SAP host agent file system

SAP requires to run an SAP host agent in each z/OS LPAR on which SAP components can run. One of the reasons for this is that the SAP host agent is used to collect and deliver data, which is only locally available on each LPAR. The SAP host agent infrastructure on each LPAR is required by other SAP tools, like, for example, the SAP NetWeaver Landscape Virtualization Management (LVM).

During installation of an SAP Central Services instance, the installation procedure places the SAP host agent into the SAP system independent path /usr/sap/hostctrl. Additionally, SAP requires that this path is local to the machine where the SAP host agent runs. On the other side, z/OS UNIX zFS file systems are normally shared between all the LPARs in a SYSPLEX. This is especially true for the /usr/sap directory, which is a link to /sap.

In order to have zFS file systems locally, you must take specific actions. In the case of an SAP host agent, the following recommendations are given. Note that the SA z/OS resources, which are part of the *SAPSRV add-on policy, exactly assume such a recommended setup.

The first step is to create a local zFS file system on each LPAR, for example like saphostctrl. The following samples show only the steps for one LPAR called COH1:

COH1:vsch:/COH1/saphostctrl>df -kvP .
Filesystem 1024-blocks Used Available Capacity Mounted on
OMVS.COH1.HOSTCTRL 360000 158294 201706 44% /COH1/saphostctrl
ZFS, Read/Write, Device:84, ACLS=Y
File System Owner : COH1 Automove=N Client=N
Filetag : T=off codeset=0
Aggregate Name : OMVS.COH1.HOSTCTRL

The second step is to copy the contents of the shared zFS, which was used during installation of the SAP host agent, into the new local zFS file system on each LPAR:

COH1:vsch:/COH1/saphostctrl>cp -p -R /usr/sap/hostctrl/*

The third step is to delete the standard shared zFS and to create a link to the local copies:

cd /usr/sap/hostctrl
rm -R *
cd ..
rmdir hostctrl
ln -s /\$SYSNAME/saphostctrl hostctrl

Now you have a hostctrl -> /$SYSNAME/saphostctrl link in the shared /usr/sap directory (which is a link to /sap directory). This way the saphostctrl is a local directory on COH1. This procedure needs to be repeated for each LPAR in your sysplex.

The consequence of having the hostctrl directory locally to each LPAR is that you must care for manually propagating adaptions/changes/updates to each LPAR, where the SAP host agent can run.

The SAP host agent can be upgraded either manually or automatically. The upgrade process stops the SAP host agent executables first, then copies the new executables into the /usr/sap/hostctrl/exe directory and finally restarts the SAP host agent. The stop and restart happens outside of System Automation because there is no synchronization between the upgrade process and System Automation. As soon as System Automation detects that the SAP host agent is stopped, it triggers the restart. This restart normally fails as it interferes with the copy process. This does not happen, if the restart can be delayed. With this version of the *SAPSRV add-on policy, a delay is introduced by adding a sleep for 1 minute command before the start command. An SAP host agent upgrade process is then noticed by System Automation as an external shutdown and the System Automation initiated restart is executed successfully.

Note that a normal start or restart via System Automation is also delayed by one minute. As the SAP host agent is not a business-critical SAP component, this should be an acceptable delay.

The following automated mechanism can be used to automatically propagate updates of the SAP host agent executables to all LPARs from one central shared directory.

For details on the automated upgrade, see the SAP Host Agent documentation.

For example, you might create a directory hostctrl_update in the shared file system /usr/sap and configure the automated upgrade of the SAP host agent to use this directory by setting DIR_NEW in the host agent profile host_profile to point to this directory:

DIR_NEW = /usr/sap/hostctrl_update

See the SAP documentation for further configuration options that help you to avoid incomplete updates and that influence the time when the automated upgrade is triggered.