Installing a PFS

A physical file system (PFS) is packaged as one or more MVS™ load modules, which must be installed in an APF-authorized load library. The load modules cannot be installed in the z/OS® UNIX file system because it is not available when a PFS is loaded.

The PFS must have an initialization routine whose entry point, called PFS_Init, is externally known through the system link list or the STEPLIB of the OMVS cataloged procedure. If the PFS runs in a colony address space (see Running a PFS in a colony address space), it must be found through the system link list or a STEPLIB of the colony address space's procedure.

A physical file system is defined to z/OS UNIX through the BPXPRMxx parmlib member you specify when you start the kernel address space (OMVS=xx). The FILESYSTYPE statement defines a single instance of a PFS.

Additional MOUNT, ROOT, SUBFILESYSTYPE, or NETWORK statements activate file system or socket support in the PFS.

  FILESYSTYPE TYPE(file_system_type)
              ENTRYPOINT(PFS_Init)
              PARM(parameter_string)
              ASNAME(procname)

where:

TYPE specifies a 1-to-8-character name that uniquely identifies this PFS. This name is used to route subsequent MOUNT, ROOT, SUBFILESYSTYPE, or NETWORK statements (as well as later MOUNT and PFSCTL syscalls) to the correct PFS.
ENTRYPOINT specifies the name of the PFS's initialization module. The LFS attaches the PFS_Init entry point as an MVS task. This task remains active for as long as the PFS is active. See Activating and deactivating the PFS for a description of initialization processing requirements for this routine.
PARM specifies a PFS-defined parameter text string that can contain any value and be up to 1024 bytes long. The meaning of this string is defined by the individual PFS. The string is passed to the PFS when the PFS_Init routine is attached.
ASNAME specifies that the PFS is to run outside the kernel in a separate address space.
procname is the name of the procedure to be used when starting this address space, and a logical name for the address space. Each procname generates a different address space when it is first encountered, and each PFS with the same procname shares that address space. These address spaces are logical extensions of the kernel. They are referred to as colony address spaces.

All PFSs are activated automatically when z/OS UNIX is started, based on the FILESYSTYPE and SUBFILESYSTYPE statements in the parmlib member. This is the only way a PFS can be started.

Mounts may also be issued dynamically at a later time through a TSO/E command or a program function call. A mount is not strictly necessary, but it is required if the files that are managed by the PFS are to be visible in the file hierarchy (that is, if they are to be represented by standard pathnames). Support for mount generally implies support for the lookup operation, which is used to resolve a pathname to a file. Pipes and sockets are examples of files that are not in the hierarchy; these PFSs do not use mount.

For a discussion of mount processing, refer to Mounting file systems.

The ROOT statement is a special case of MOUNT. It can be issued only from parmlib, and it defines the system's root file system.

The NETWORK statement does for a sockets PFS what MOUNT does for a data file type of PFS: It activates an address family, or domain, so that subsequent socket() calls are routed to that PFS to service.

For a discussion of network processing, refer to Activating a domain.