z/OS UNIX System Services Planning
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Implications of shared file systems during system failures and recovery

z/OS UNIX System Services Planning
GA32-0884-00

File system recovery in a shared file system environment takes into consideration file system characteristics such as the PFS capabilities, whether or not the file system is automount-managed, and the AUTOMOVE value. Customizing BPXPRMxx for a shared file system describes the various AUTOMOVE values and the system actions taken for the various shutdown and recovery flows.

Generally, when an owning system fails, ownership of a file system that is mounted as AUTOMOVE is moved to another system and the file system remains usable. However, if a file system is mounted as read/write and the owning system fails, then all file system operations for files in that file system will fail. This happens because data integrity is lost when the file system owner fails. All files should be closed (BPX1CLO) and reopened (BPX1OPN) when the file system is recovered. See z/OS UNIX System Services Programming: Assembler Callable Services Reference for more information about BPX1CLO and BPX1OPN.

For file systems that are mounted as read-only, specific I/O operations that were in progress at the time the file system owner failed might need to be started again.

In some situations, even though a file system is mounted as AUTOMOVE, ownership of the file system might not be immediately moved to another system. This can occur, for example, when a physical I/O path from another system to the volume where the file system resides is not available. As a result, the file system becomes unowned; if this happens, you will see message BPXF213E. This is true if the file system is mounted either read/write or read-only. The file system still exists in the file system hierarchy so that any dependent file systems that are owned by another system are still usable. However, all file operations for the unowned file system will fail until a new owner is established. The shared file system support will continue to attempt recovery of AUTOMOVE file systems on all systems in the sysplex that are enabled for shared file system. If a subsequent recovery attempt succeeds, the file system moves from the unowned to the active state.

Applications using files in unowned file systems will need to close (BPX1CLO) those files and reopen (BPX1OPN) them after the file system is recovered. File systems that are mounted as NOAUTOMOVE will become unowned when the file system owner exits the sysplex. The file system will remain unowned until the original owning system restarts or until the unowned file system is unmounted. Because the file system still exists in the file system hierarchy, the file system mount point is still in use. File systems that are mounted below a NOAUTOMOVE file system will not be accessible via path name when the NOAUTOMOVE file system becomes available.

Restriction: Do not mount AUTOMOVE file systems within NOAUTOMOVE file systems. When a NOAUTOMOVE file system becomes unowned and there are AUTOMOVE file systems mounted within it, those AUTOMOVE file systems will retain a level of availability, but only for files that are already open. When the NOAUTOMOVE file system becomes unowned, it will not be possible to perform path name lookup through it to the file systems mounted within it, which will make those file systems unavailable for new access. When ownership is restored to the unowned file system, access to the file systems mounted within it is also restored.

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

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014