Activation flow for the PFS

The LFS builds a general file system table (GFS) for each PFS and attaches the PFS's initialization entry point. This creates an independent MVS™ task, which is expected to follow these general steps:

Perform any PFS initialization that is necessary.
Load its VFS and vnode operation service routines and build their respective vector tables.
These are the PFS routines that the LFS calls to get such services as mount, open, read, and write. The VFS and vnode operations vector tables make up the major part of the PFS interface.

This loading may be done by link-editing the operational routines with the PFS_Init routine.
Save the OSI operations vector table (OSIT) address.
The OSI operations vector table contains the addresses of LFS routines that the PFS uses to get certain services, such as those used to create vnodes.
Pass back to the LFS an 8-byte token that is saved by the LFS and used on all subsequent VFS and vnode operations. This token typically contains the address of the PFS's main anchor block. Its use is optional.
Exchange miscellaneous items of information between the LFS and PFS. Refer to The PFSI structure and the PFSI structure in Interface structures for C language servers and clients for details on the specific information that is exchanged.
Notify the LFS that initialization has finished, by posting the initialization-complete ECB that was supplied.
Wait on the termination ECB, which is also supplied by the LFS. This ECB is posted by the LFS when it is time to terminate the PFS.

Each PFS is initialized synchronously and serially during z/OS UNIX initialization, so that no PFS may go into an extended wait during initialization.

Note: The file system is not available this early in z/OS UNIX initialization. If the PFS_Init routine needs configuration or other information from a file, it must use an MVS data set.