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 you can take to help manage the placement of data in the event of a system failure.

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 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 supported by the MOUNT command.
Automove option	Action
UNMOUNT	Attempts will not be 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. Tip: 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 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 described in Customizing BPXPRMxx for a shared file system. See the associated documentation for the exact syntax.

Guideline: 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 are available for automatic re-export. 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.

In addition, 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 re-export 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.

Tip: 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.