z/TPF file system support

TFS provides support for a subsystem-unique, processor-shared file system that is maintained across processor IPLs.

TFS uses z/TPF collection support as its storage mechanism; therefore, files in TFS cannot be created, updated, or deleted unless get file storage (GFS) is active.

TFS does not use the atime (access time) or ctime (change time) time stamp; however, you can set the access time by using the utime function.

MFS provides support for a subsystem-unique, processor-unique file system that is not maintained across processor IPLs and is reinitialized every time it is mounted.

MFS uses system heap as its storage mechanism; therefore, it is a substantially faster file system than the TFS. Furthermore, because MFS stores files in system heap storage, those files can be created, updated, and deleted in any z/TPF system state.

FFS provides support for a processor-unique file system that is built by using a subsystem-unique, processor-shared fixed file record type; that is, only one processor can mount an FFS in read/write mode at one time, but multiple processors can mount the same FFS in read/only mode. The file system supports record buffering, i-node and directory caching, file and byte locking, and user-named attributes for files.

The file system uses core locking to serialize write access to the file. By being able to mount the file system on multiple processors in read/only mode, dirty reading can be done; however, if your application reads data from a file that is not locked, that data might change after the read.

FFS uses fixed file records for both i-nodes and data records; therefore, FFS provides a file system for files that need to be maintained across system IPLs where performance is more important than minimizing the use of file space, and where data must not be exposed to corruption that might be caused by applications inadvertently overwriting pool records.

PFS provides support for a processor-unique file system that is built by using a subsystem-unique, processor-shared fixed file record type for i-nodes and pool records for data; that is, only one processor can mount an PFS in read/write mode at one time, but multiple processors can mount the same PFS in read/only mode. The file system supports record buffering, i-node and directory caching, file and byte locking, and user named-attributes for files.

The file system uses core locking to serialize write access to the file. By being able to mount the file system on multiple processors in read/only mode, dirty reading can be done; however, if your application reads data from a file that is not locked, that data might change after the read.

PFS uses fixed file records for i-nodes and pool records for data records; therefore, PFS provides a file system for files that need to be maintained across system IPLs with a high level of performance but by using pool records for data provides a more efficient use of file space.

The PROCFS provides support for a processor-unique psuedo-file system that is mounted on the /proc subdirectory of the TFS when the file system is initialized. The PROCFS uses files and directories called targets to access process-specific system services and data structures through standard file system APIs. The structure of the PROCFS is defined through the use of a system table of targets and an optional user table of targets that define the behaviors of files in the file system. The user table allows you to extend the capabilities of the PROCFS by creating your own targets and supporting programs.

The SYSFS provides support for a processor-unique psuedo-file system that is mounted on the /sys subdirectory of the TFS when the file system is initialized. The SYSFS uses files and directories called targets to access system services and data structures through standard file system APIs. The structure of the SYSFS is defined through the use of a system table of targets and an optional user table of targets that define the behaviors of files in the file system. The user table allows you to extend the capabilities of the SYSFS by creating your own targets and supporting programs.

The VCFX provides support for a subsystem-unique, processor-unique, memory resident file system that is mounted on the /vcfx subdirectory of the TFS when the file system is initialized.

The VCFX is a special purpose file system containing symbolic links that provide transparent access to file versions residing in the TFS.

The VCFX is not a general purpose file system. You must use the E-type loader to use the VCFX.

The directory structure in the VCFX is organized by file name and activation number, and each file in the VCFX is a symbolic link to the appropriate file version that is located in the TFS. To the application, however, the VCFX appears to contain only the file versions that the application is eligible to access based on its ECB activation number, and the extra levels of hierarchy based on activation number are suppressed. The appearance of the VCFX to the application is provided by the special implementation of relevant file system operations, which is transparent to you and your applications.