Those of you with many years of experience with z/OS (and previously OS/390® and MVS before that) will have noticed the growing role of UNIX System Services in the z/OS environment. OMVS is now an integral part of z/OS, and critical parts of the system cannot initialize without OMVS being available. For this reason, we provide recommendations for how to keep the time for OMVS initialization as short as possible.
5.5.1 BPXMCDS
In “Sysplex Couple Data Set size” on page 59 we describe how XCF reads the entire Couple Data Set (CDS) at IPL time, and how a very large CDS can elongate the time for XCF to initialize. Similarly, the size of the BPXMCDS Couple Data Set can affect how long OMVS takes to initialize.
To understand the impact of oversizing your BPXMCDS data set, we IPLed with two BPXMCDS data sets formatted as shown in Table 5-1 on page 86.
Table 5-1 BPXMCDS attributes
The two things to consider in relation to the size of the BPXMCDS are:
How the size affects the amount of time that OMVS takes to initialize at IPL time
Whether the size affects the processing of each mount command
To determine the former, we IPLed the system with the normal-sized BPXMCDS, and then again with the maximum-sized BPXMCDS. The results are shown in Figure 5-2. As you can see, changing the OMVS size doubled the initialization time for OMVS. As with the sysplex CDS, if you already have a very large (larger than necessary) OMVS CDS, you are unlikely to want to do a sysplex IPL simply to reduce the CDS size. However if you are planning to increase the size of your existing CDS, consider making a small increase, on the basis that you can always make the CDS larger nondisruptively.
Figure 5-2 Results of BPXMCDS size on OMVS initialization time
We also tried issuing a Mount command for a file system using both the normal-sized
BPXMCDS and the maximum-sized BPXMCDS. Unfortunately, there is no console command to mount or unmount a file system, so getting precise timing for these commands is difficult. In the end, we submitted batch jobs containing Unmount and Mount commands, and monitored the elapsed time of the jobs.
Size Number of systems Number of mounts Number of AUTOMOUNT rules
Run 1: Normal size 12 500 50
Run 2: Maximum size 32 50000 1000
Note: Subsequent to our residency tests, z/OS 1.11 (and APAR OA26802 for z/OS 1.9 and
1.10) added the ability to MOUNT or UNMOUNT a file system from the console using SYSREXX.
Impact of OMVS CDS Size
0 5 10 15 20 25 30 35 40
Time to zFS Start Time to OMVS Initialization Complete Se co n d s Small Maximum
With the maximum-sized CDS, the elapsed time for the job averaged 3.78 seconds. When we switched to the normal-sized CDS (which required a sysplex IPL), the average elapsed time dropped to only .2 seconds.
As with the sysplex couple data sets, we do not expect anyone to do a sysplex IPL simply to move to a smaller BPXMCDS data set. However, if you want to increase the size of your couple data sets, consider making small adjustments (because you can always move to a larger CDS nondisruptively) rather than one large adjustment.
5.5.2 Mounting file systems during OMVS initialization
During OMVS initialization, OMVS attempts to mount any file systems that are referenced on MOUNT statements in the BPXPRMxx Parmlib members that are pointed to on the OMVS parameter in IEASYSxx. Obviously, the more file systems that are listed in this member, the longer OMVS takes to initialize (because it mounts each one serially). Therefore, if you find that important subsystems are being delayed in their startup because they are waiting for OMVS to complete initialization, consider moving non-critical file systems out of the BPXPRMxx member and mounting them later in the IPL process.
One way to achieve this is to define these file systems as AUTOMOUNT-managed, so that if any process attempts to use them before you have a chance to mount them, the file system will be automatically mounted. However, to avoid the delay that is encountered by the first process that causes the file system to be mounted, you can run a small batch job that touches all these file systems, causing them to be mounted before any user actually tries to use them. Alternatively, after OMVS has initialized, you can:
Run a little job that would issue MOUNT commands for all those other file systems.
Use a set omvs=xx command to issue MOUNT commands contained in another BPXPRMxx member.
Exploit the new SYSREXX APIs for mounting UNIX System Services file systems, for example F AXR,MNTMORE (where MNTMORE is a SYSREXX routine that mounts more file systems.
We highly recommend using the following methodology to determine from where the MOUNT for a given file system is issued:
In the BPXPRMxx member, mount the SYSPLEX and version file systems, product file systems (including IBM subsystems such as CICS, DB2, and so on), and the /etc, /tmp, and /var file systems.
In /etc/rc, mount the file systems for critical applications.
In /etc/local/rc (or some other location) issue the mounts for non-critical applications. You would run a batch job after the system has IPLed to mount these file systems. One contributor to this book reduced the length of time to make OMVS available by over 20 minutes by organizing the mounts in this matter.
Use of SUB=MSTR for colony address spaces
Colony address spaces are normally started under JES. However if you are concerned with how long JES takes to start, you have the option of starting the colony address spaces with SUB=MSTR. This capability can allow the startup of the colony address spaces to proceed before JES initialization completes. To use this capability, in your BPXPRMxx member, use SUB=MSTR on FILESYSTYPE statements that use ASNAME. This can apply to zFS, NFS, and TFS.
For more information about this capability, see “Starting colony address spaces outside of JES” in z/OS UNIX System Services Planning, GA22-7800.
5.5.3 Commands processed during OMVS initialization
Just as mounting files can elongate OMVS initialization time, so can the processing of commands. The /etc/rc file contains commands that are issued during OMVS initialization. Review this file to ensure that only commands that must be issued at this time are contained in the file. Any commands that can be issued later in the IPL process should be moved to a different file and issued by automation after the critical subsystems that depend on OMVS being available have completed initialization.
5.5.4 Mounting file systems read/write or read/only
The UNIX System Services sysplex file-sharing method that is implemented by UNIX System Services is basically a function-shipping model, conceptually similar to a CICS FOR. For each file system that will use sysplex file sharing, the file system is mounted on one member of the sysplex, and all read or write requests for that file system from any member of the sysplex is forwarded to that system using XCF. This provides great flexibility, because work that uses that file system can be run anywhere in the sysplex. However, the cost of this flexibility is in reduced performance: asking another system to retrieve some data and pass that data back over XCF obviously takes longer than if the requesting system could just read the data itself. For file systems that contain mainly programs, such as the version root (that is, the vast majority of accesses are reads), consider moving any files or directories that require write access to another file system. The file system that contains only code can then be mounted as read-only on every member of the sysplex, meaning that each system can do its own I/O, and receive correspondingly better performance.
z/OS 1.11 includes performance enhancements for sysplex file-sharing. However even with these enhancements, performance would still not be equivalent to a file that is mounted as read-only.
5.5.5 Shutting down OMVS
All I/Os to a UNIX file system are processed by OMVS. Just as you would not intentionally IPL a system without first doing an orderly shutdown of your database managers, equally, you should not IPL a system without doing an orderly shutdown of OMVS. The preferred way to shut down OMVS is to follow these steps to bring down OMVS in an orderly manner: 1. Stop any address spaces such as TSO, TCPIP, VTAM, DFSS, FTP, WebSphere
Application Server, batch jobs and other address spaces that might use any part of OMVS prior to stopping OMVS.
2. Stop the NFS file system. To do this, issue:
F OMVS,STOPPFS=NFS
3. When you are ready to stop OMVS, issue:
F OMVS,SHUTDOWN
If you need to escalate the shutdown, issue:
If you have thousands of OMVS file systems, OMVS shutdown could take quite a long time. To minimize the impact of this time, try to shut down all the OMVS tasks/subsystems, then shut down OMVS, and in parallel, shut down any other non-OMVS tasks