Customizing BPXPRMxx for a shared file system

You can use one BPXPRMxx member to define all the file systems in the sysplex. Each participating system has its own BPXPRMxx member to define system limits, but shares a common BPXPRMxx member to define the file systems for the sysplex. The sharing is done by using system symbolics. Figure 1 shows an example of this unified member. You can also have multiple BPXPRMxx members defining the file systems for individual systems in the sysplex. An example of this is Figure 2.

Tip: You can use the USS_CLIENT_MOUNTS check provided by IBM® Health Checker for z/OS® to verify that, in a shared file system configuration, sysplex-aware file systems are not function-shipping.

When you are setting up a shared file system in a sysplex, use the parameters that are described in Table 1.

Table 1. Parameters used when you are setting up shared file systems in a sysplex. This table lists the parameters that are used when setting up shared file systems in a sysplex.
Parameter	What it does
SYSPLEX(YES)	Indicates that this system is to participate in the shared file system configuration. This involves joining the SYSBPX XCF group. Those systems that specify SYSPLEX(YES) make up the systems that participate in the shared file system configuration and are members of the SYSBPX XCF group. If SYSPLEX(YES) is specified in the BPXPRMxx member, but the system is initialized in XCF-local mode, either by specifying COUPLE SYSPLEX(LOCAL) in the COUPLExx member or by specifying PLEXCFG=XCFLOCAL in the IEASYSxx member, then the kernel will ignore the SYSPLEX(YES) value and initialize with SYSPLEX(NO). This system will not participate in a shared file system support after the initialization completes.
VERSION('`nnnn`')	Allows multiple releases and service levels of the binaries to coexist and participate in a shared file system. `nnnn` is a qualifier to represent a level of the version file system. The most appropriate values for `nnnn` are the name of the target zone, &SYSR1, or another qualifier meaningful to the system programmer. A directory with the value `nnnn` specified on VERSION will be dynamically created at system initialization under the sysplex root and will be used as a mount point for the version file system. There is one version file system for every instance of the VERSION parameter. More information about version file system appears in Mounting the version file system.
The SYSNAME(`sysname`) parameter on the MOUNT statements	Specifies the particular system on which a mount is to be performed. `sysname` is a 1-to-8 alphanumeric name of the system. This system will then become the owner of the file system that is mounted. The owning system must also be IPLed with SYSPLEX(YES). Tip: Only specify a SYSNAME() value if you want only the specified system to be the file system owner. The MOUNT statement is ignored during z/OS UNIX initialization processing if SYSNAME() specifies another system. Once mounted on the specified owner, the file system will become locally available as a client or non-owner system. For SET OMVS and SETOMVS processing, the MOUNT statement is processed and the MOUNT is function-shipped to the system specified by SYSNAME(). If SYSNAME() is used with a value other than &SYSNAME. then there should not be any subsequent parmlib MOUNT statements that specify a MOUNTPOINT() with a path name that includes a directory in this file system The SYSNAME parameter is also used with SETOMVS when moving file systems, as demonstrated in Moving file systems in a sysplex.
The AUTOMOVE, NOAUTOMOVE, and UNMOUNT parameters on the ROOT and MOUNT statements	Indicate what happens to the file system if the system that owns that file system goes down. Note that the system list form of the AUTOMOVE parameter only applies to the MOUNT statement, and not to the ROOT statement. AUTOMOVE without a system list specifies that ownership of the file system is automatically moved to another system. It is the default. AUTOMOVE with a system list (SYSLIST) indicates which systems the file system should or should not be moved to when the owning system leaves the sysplex. NOAUTOMOVE specifies that the file system will not be moved if the owning system goes down and the file system is not accessible. UNMOUNT specifies that the file system will be unmounted when the system leaves the sysplex. This option is not available for automounted file systems. Define your version and sysplex root file system data as AUTOMOVE, and define your system-specific file systems as UNMOUNT. Do not define a file system as NOAUTOMOVE or UNMOUNT and a file system underneath it as AUTOMOVE. If you do, the file system that is defined as AUTOMOVE will not be recovered after a system failure until that failing system has been restarted. To ensure that the root is always available, use the default, which is AUTOMOVE.

For file systems that are exported by the Distributed File System (DFS) or System Message Block (SMB) server to their remote clients, consider specifying NOAUTOMOVE on the MOUNT statement. Then the file systems will not change ownership if the system is suddenly recycled, and they will be available for automatic reexport. Specifying NOAUTOMOVE is suggested because a file system can only be exported by the DFS or SMB server at the system that owns the file system. Once a file system has been exported, it cannot be moved until it has been unexported by the server that exported it. When recovering from system outages, you need to weigh sysplex availability against availability to the server. When an owning system recycles and a DFS-exported file system has been taken over by one of the other systems, the server cannot automatically reexport that file system. The file system will have to be moved from its current owner back to the original system, the one that has just been recycled, and then exported again.

The owner of a file system is the first system that processes the mount. This system always accesses the file system locally; that is, the system does not access the file system through a remote system. Other non-owning systems in the sysplex access the file system either locally or through the remote owning system, depending on the PFS and the mount mode. If a PFS allows a file system to be locally accessed on all systems in a sysplex for a particular mode, then the PFS is sysplex-aware for that mount mode.

Even if a PFS is sysplex-aware for a particular mode, if a non-owning system does not have DASD connectivity, the file system is accessed remotely through the owning system. For example, HFS is non-sysplex aware for read/write mode, because all non-owning systems must access read/write file systems through the remote owning system. The non-owning systems are said to be sysplex clients. However, HFS is sysplex-aware for read-only mode, which means that each system can access read-only file systems locally, and do not need to contact the owning system. For more information, see File system availability.

TFS file systems do not participate in move operations, regardless of the AUTOMOVE setting. They are unmounted if the file system owner becomes unavailable

Restrictions: Keep the following restrictions in mind:

An AUTOMOVE file system cannot be moved to a system where z/OS UNIX was shut down or where F BPXOINIT,SHUTDOWN=fileowner was issued.
Automount-managed file systems are handled as AUTOMOVE if the file system is being locally used.
NOAUTOMOVE and system list are permitted for a sysplex-aware file system and are honored on a V1R9 system. However, if the file system is moved to a system at an earlier release, the automove setting is changed to AUTOMOVE.

Table 2 shows what happens during soft shutdown for various AUTOMOVE settings. Soft shutdown is done by issuing one of the following MODIFY commands:

F BPXOINIT,SHUTDOWN=FILESYS
F BPXOINIT,SHTUDOWN=FILEOWNER

A leaf file system refers to a file system that does not contain any file systems that are mounted on a directory within that file system. A subtree is the file system and all file systems that are mounted beneath that file system.

Table 2. Soft shutdown actions for various AUTOMOVE settings. This table lists the soft shutdown actions for various AUTOMOVE settings.
Automove value	Action taken
NOAUTOMOVE or UNMOUNT	An attempt to unmount the file system occurs. The unmount fails if it is not a leaf file system.
AUTOMOVE without a system list	Moves the file system to any system. If the move fails, the unmount is not attempted.
AUTOMOVE with a system list	Moves the file system to any system. If the file system cannot be moved, then the unmount is not attempted.

Table 3 shows what happens during soft shutdown for various AUTOMOVE settings for an OMVS shutdown, performed by using the F OMVS,SHUTDOWN system command.

Table 3. OMVS shutdown actions for various AUTOMOVE settings. This table lists the shutdown actions that are taken by OMVS for various AUTOMOVE settings.
Automove value	Action taken
NOAUTOMOVE	An attempt to unmount the file system occurs. The unmount fails if it is not a leaf file system and the file system becomes unowned. The file system remains unowned until the last owning system restarts, or until the file system is unmounted. Because the file system still exists in the file system hierarchy, the file system mount point is still in use.
UNMOUNT	The file system is unmounted, and all the file systems that are mounted within it are also unmounted.
AUTOMOVE without a system list	Moves the file system to any system. If the move fails, the file system becomes unowned. The file system remains unowned until the last owning system restarts or until the unowned recovery daemon can establish a new file system owner.
AUTOMOVE with a system list	An attempt to move ownership of the file system to eligible systems (as defined by the INCLUDE or EXCLUDE system list) is performed. If no systems could become the file system owner, the file system is unmounted, as well as all the file systems mounted within it.

Automount-managed file systems are unmounted by a soft shutdown operation if the file system is not referenced by any other system in the sysplex. If it is referenced by another system or systems, ownership of the file system is moved. If the move fails, an unmount is not attempted and ownership does not change.

Table 4 shows what happens during dead system takeover for various AUTOMOVE settings for sysplex-aware file systems. Dead system takeover (otherwise known as Member Gone Recovery) is the action that is taken by systems in a sysplex when they attempt to take over ownership of file systems that were previously owned by a system that has just left the XCF BPXGRP member group.

Table 4. Dead system (member gone) takeover for various AUTOMOVE settings. This table lists the action that is taken for dead system takeover for various AUTOMOVE settings.
Automove value	Action taken
NOAUTOMOVE	The file system becomes unowned. The file system remains unowned until the last owning system restarts, or until the file system is unmounted. Because the file system still exists in the file system hierarchy, the mount point for the file system is still in use.
UNMOUNT	The file system is unmounted, and all the file systems that are mounted within it are also unmounted.
AUTOMOVE without a system list	An attempt to move ownership of the file system to all other eligible systems in the participating group is performed. If another file system cannot become the owner of the file system, the file system becomes unowned. The file system remains unowned until the last owning system restarts or until the unowned recovery daemon can establish a new file system owner.
AUTOMOVE with a system list	An attempt to move ownership of the file system to eligible systems (as defined by the INCLUDE or EXCLUDE system list) is performed. If another system could not become the file system owner, the file system is unmounted, in addition to all the file systems mounted within it.

There is no attempt to take over automount-managed file systems if the file system is not being used locally. Automount-managed, unowned file systems are unmounted.

Table 5 shows what happens during PFS termination for various AUTOMOVE settings.

Table 5. PFS termination for various AUTOMOVE settings. This table discusses what happens if PFS is terminated
What happens if . . .	Action taken
NOAUTOMOVE	The file system is unmounted, and all the file systems that are mounted within it are also unmounted.
UNMOUNT	The file system is unmounted, and all the file systems that are mounted within it are also unmounted.
AUTOMOVE without a system list	An attempt to move ownership of the file system to all other eligible systems in the participating group is performed. If another system cannot become the owner of the file system, the file system is unmounted, in addition to all the file systems mounted within it.
AUTOMOVE with a system list	An attempt to move ownership of the file system to eligible systems (as defined by the INCLUDE or EXCLUDE system list) is performed. If another system cannot become the file system owner, the file system is unmounted, in addition to all the file systems mounted within it.

Table 6 shows what happens when a move file system is requested to move a specific file system to any target system (wildcard is used). A move file system request can be issued with a SETOMVS operator command or a chmount shell command.

Table 6. Move a specific file system to any system for various AUTOMOVE settings. This table lists what happens during an automove for a fixed file system.
What happens if . . .	For sysplex-aware file systems
NOAUTOMOVE	Move is attempted to all systems.
UNMOUNT	Move is attempted to all systems.
AUTOMOVE without a system list	Move is attempted to all systems.
AUTOMOVE with a system list	Move is attempted only to systems in the system list.

Table 7 shows what happens when a move filesystem is requested to do a multi-file system move, moving all file systems from a system to a specific target system. A move file system request can be issued with a SETOMVS operator command or a chmount shell command.

Table 7. Move all file systems from a system to a specific target system for various AUTOMOVE settings. This table lists what happens when all file systems are moved to a specific target system.
What happens if . . .	Action taken
NOAUTOMOVE	Move is not attempted.
UNMOUNT	Move is not attempted.
AUTOMOVE without a system list	Move is attempted to the target system.
AUTOMOVE with a system list	Move is attempted to the target system and the system list is ignored.

Rules: Define your version and sysplex root file system as AUTOMOVE. Also:

Define your system-specific file systems as UNMOUNT.
Do not define a file system as NOAUTOMOVE or UNMOUNT and a file system under it as AUTOMOVE. If you do, the file system that is defined as AUTOMOVE will not be recovered after a system failure until that failing system is restarted.

To ensure that the root is always available, use the default, which is AUTOMOVE. Also:

For non-sysplex aware file systems that are mostly exported by the DFS or SMB server to their remote clients, consider specifying NOAUTOMOVE on the MOUNT statement. Then the file systems will not change ownership if the system is suddenly recycled, and they will be available for automatic reexport by DFS or SMB.
Consider NOAUTOMOVE because a file system can only be exported by the DFS or SMB server at the system that owns the file system. Once a file system has been exported by DFS, it cannot be moved until it has been unexported by DFS. The same holds true of file systems that are exported by SMB. When recovering from system outages, you need to weigh sysplex availability against availability to the DFS or SMB clients.
- When an owning system recycles and a file system that is exported by DFS or SMB has been taken over by one of the other systems, DFS or SMB cannot automatically re-export that file system.
- When an owning system is recycled and an exported file system has been taken over by one of the other systems, that file system will not be automatically reexported. The file system will have to be moved from its current owner back to the original system, the one that has just been recycled, and then exported again.
If a file system that is mounted as AUTOMOVE with or without a SYSLIST is not moved or recovered as expected, use D OMVS,MF on all systems to review MOUNT or MOVE failures relating to the specific file system.

For more information about VERSION, SYSPLEX, SYSNAME and AUTOMOVE, NOAUTOMOVE, and UNMOUNT, see z/OS MVS Initialization and Tuning Reference.