Shared File System (SFS) Architecture
- Allow multiple users to share and update data and programs
- Allow users on different z/VM systems to access shared files
- Control multiple users from updating at the same time
- Ensure file level security (control who accesses specific files)
- Preserve data integrity. (SFS is a protected resource. It can participate in CRR.)
For list of performance considerations when you use SFS, see Performance Tips.
SFS stores files in CMS file pools. A file pool is a collection of minidisks that contains the files for a number of users. This collection of minidisks is assigned to a virtual machine called a file pool server machine. The file pool server machine manages all of the file within the file pool. An SFS user is given a certain amount of space within a file pool. This space is called a file space.
SFS lets you share files with other applications. You, as the owner of the files, can grant authorities that let others read from or write to your files and directories. The owner of the directory has control over who accesses the files.
Two applications cannot write to the same file within SFS at the same time. To prevent two applications from writing to the same file at the same time, SFS has a locking facility. There are two types of locks: an implicit lock and an explicit lock. SFS acquires and releases an implicit lock automatically. However, all implicit locks are released at the end of a work unit. You can create an explicit lock by issuing a CMS command or routine that forces an object to be locked. An explicit lock can be in effect even if a work unit ends. A work unit is a group of related operations. SFS allows either all changes in a work unit to complete successfully or none of them to complete.
For more information on using SFS, see Manipulating SFS and Minidisk Files and Directories and the z/VM: CMS User's Guide.