In z/OS V2R3, a new directory /global is available in the versions root and sysplex root. It can be used to store and maintain a single copy of configuration files or mount points of program products that can be referenced by all members of the sysplex. Prior to z/OS V2R3, individual copies of the same configuration file had to be maintained in each member of the sysplex.
Note: Follow this link for details and configuration of the z/OS V2R3 /global feature.
Use Case #1: SAP hostagent update
SAP requires an SAP hostagent to be installed and running on each z/OS LPAR on which SAP components can run. That includes LPARs on which SAP Central Services are installed, but also LPARs on which just a Db2 subsystem for SAP is installed. This can result in a significant number of SAP hostagents in an SAP environment that you have to maintain.
For our environment I created a sub-directory /global/usr/sap/hostctrl_update.
Then I configured each instance of an SAP hostagent to use this new directory by setting the SAP hostagent profile parameter DIR_NEW to point to this directory:
DIR_NEW = /global/usr/sap/hostctrl_update
I also created for each SAP hostagent a /usr/sap/hostctrl/.delay file with an entry "60random60". This configures a delayed auto-upgrade and prevents updating all SAP hostagents at the same time. Auto-upgrade will check the version of the file contained in DIR_NEW every 60 minutes. Once the version of SAP hostagent contained within DIR_NEW is newer, the upgrade will be started within the next 60 minutes. The exact time when the upgrade is started is a random value between 1 and 60 minutes.
The SAP hostagent picks up profile changes when you issue the command "/usr/sap/hostctrl/exe/saphostexec -restart"
The SAP hostagent automatically will look for updates in DIR_NEW.
After all that there is only one thing left to do: Download the most recent SAPHOSTAGENT archive from SAP Marketplace and unpack it into /global/usr/sap/hostagent_update.
- Saves resources - local update directories - and guarantees that all SAP hostagents in my environment are always on the same level.
- The update installation is automated and starts randomly between participating systems within 60 minutes.
Note: Follow this SAP link for details on the topic Automated Upgrade of SAP Host Agent.
Use Case #2 Jointly used automounter master file
In an SAP High Availability (HA) environment with shared zFS file systems and NFS server on z/OS, each participating system has its own automounter configuration file.
For our environment I configured a /global/auto.master and created symbolic links from each system's auto.master to the /global/auto.master
- Reduces maintenance and guarantees a consistent automount master configuration for every system.
- Works as well for non-HA environments.
Use Case #3 Consistent and valid /etc/hosts configuration
The file /etc/hosts is a key file to organize and provide network information like IP addresses and matching hostnames and short names to the local system.
In an SAP High Availability environment where systems rely on a well defined and highly available network infrastructure this can result in quite a number of /etc/hosts/ files to maintain.
For our environment I defined one common /global/hosts file and created symbolic links from each system's local /etc/hosts to /global/hosts
- Eliminates missing hostnames or IP addresses from a variety of accidentally different /etc/hosts files.
- Reduces maintenance and guarantees a consistent and valid /etc/hosts file for each participating system.
- Works as well for non-HA environments.
Use Case #4 Correct and complete USERIDALIASTABLE
A correctly and completely maintained USERIDALIASTABLE is key in a shared zFS configuration in a heterogeneous environment.
In our environment the parameter USERIDALIASTABLE of the BPXPRMxx parmlib member points to a file /etc/ualiastable.
I defined a /global/ualiastable with all jointly used user names and group names. Then I created symbolic links from each system's /etc/ualiastable to /global/ualiastable
- Eliminates missing and misspelled user names and group names that potentially come from a variety of different /etc/ualiastable files.
- Reduces maintenance and guarantees a consistent and valid /etc/ualiastable file for evey participating system.
Note: Follow this link for details on the USERIDALIASTABLE.
I'm sure you can find a lot more valuable uses cases for this new z/OS V2R3 feature.
Have fun trying this out and let me know how it works for you.