Managing the movement of data

File systems can be managed so as to maximize their availability when systems exit the participating group. You have more control over this when the outage is planned, but there are steps that you can take to help manage the placement of data if a system failure occurs.

Recovery processing for the file systems that are owned by a failed system is managed internally by all the systems in the participating group. If you want special considerations for the placement of certain file systems, you can use the options that are provided by the various mount services to specify the original owner and subsequent owners for a particular file system.

Customizing BPXPRMxx for a shared file system describes the behavior of the various AUTOMOVE options.

Table 1 shows the AUTOMOVE options that you can use with the MOUNT command to manage file systems.

Table 1. AUTOMOVE options supported by the MOUNT command . This table lists the automove options that are supported by the MOUNT command.
Automove option Action
UNMOUNT Attempts are not made to keep the file system active when the current owner fails. The file system is unmounted when the owner is no longer active in the participating group, as well as all the file systems mounted within it.

Use UNMOUNT when mounting system-specific file systems, such as those that would be mounted at /etc, /dev, /tmp, and /var.
NOAUTOMOVE Attempts are not made to keep the file system active when the current owner fails. The file system remains in the hierarchy for possible recovery when the original owner reinitializes. Use this option on mounts for system-specific file systems if you want to have automatic recovery when the original owner rejoins the participating group.

When the NOAUTOMOVE option is used, the file system becomes unowned when the owning system exits the participating group. 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.

An unowned file system is a mounted file system that does not have an owner. Because it still exists in the file system hierarchy, it can be recovered or unmounted.
AUTOMOVE without a system list Recovery of the file system is performed when the current owner fails. Use this option on mounts of file systems that are critical to operation across all the systems in the participating group. AUTOMOVE is the default.
AUTOMOVE with a system list AUTOMOVE(EXCLUDE|INCLUDE,sysname1,sysname2,...sysnameN) specifies managed recovery of the file system if the current owner fails.
  • Use the EXCLUDE list to prevent recovery of a file system from transferring ownership to a particular system, or set of systems, in the participating group. When the current owner fails, recovery of the file system is performed to an owner outside the exclude list. When the current owner fails, recovery of the file system is performed to a randomly selected owner outside the exclude list.
  • Use the INCLUDE list to ensure that recovery of a file system will transfer ownership only to a particular system or set of systems in the participating group. Recovery of the file system is performed in priority order only by the list of systems that are specified in the INCLUDE list.
Restriction: Only use this option on mounts of file systems that are critical to operation across a subset of systems in the participating group, or when you do not want certain systems in the participating group to have ownership of the file system.

If recovery processing fails to establish a new owner for the file system, the file system is unmounted, along with all the file systems mounted within it.

Most of the z/OS UNIX interfaces that provide for mounting file systems (such as TSO, shell, ISHELL, and BPX2MNT) support some form of the options that are described in Customizing BPXPRMxx for a shared file system. See the associated documentation for the exact syntax.

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

In addition, when recovering from system outages, you need to weigh sysplex availability against availability to the server.

When an original owner system reinitializes, you might want to move the read/write file system back to this original owner if the original owner is the primary system that accesses the file system and if the PFS does not support accessing the read/write file system in a sysplex-aware mode. Better performance should occur when the file system is locally mounted (owned) at the system that most frequently accesses the file system. See also File system availability and Tuning z/OS UNIX performance in a sysplex.