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 through the
use of 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 setting up a shared file system in a sysplex, use the parameters
described in
Table 1.
Table 1. Parameters used when 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 defined as AUTOMOVE will
not be recovered after a system failure until that failing system
has been restarted.
Tip: To ensure that the root is
always available, use the default, which is AUTOMOVE.
|
Guideline: 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 taken by OMVS for various
AUTOMOVE settings.Automove value |
Action taken |
---|
NOAUTOMOVE |
An attempt to unmount the file system occurs.
The unmount fails if 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 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 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
taken for deaf 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 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 terminatedWhat happens if . . . |
Action taken |
---|
NOAUTOMOVE |
The file system is unmounted, and all the file
systems mounted within it are also unmounted. |
UNMOUNT |
The file system is unmounted, and all the file
systems 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 defined as
AUTOMOVE will not be recovered after a system failure until that failing
system is restarted.
Guidelines: 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 re-export by DFS or
SMB.
Tip: 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 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 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.