PC#RestartPFS X'8000000D' restarts the PFS by reattaching the PFS_Init module.

• If no argument is passed, or if the argument value is not 1, the LFS waits for the PFS initialization to complete before returning to the caller.
• If a fullword argument value of 1 is passed, the LFS returns to the caller immediately after posting the internal thread that does the reattach. The caller and the PFS must coordinate between themselves for the restart. This is similar to a startup during IPL.

The Return_value is 0 if the PFS was found and was awaiting this restart. The Return_value is 1 if the PFS was found but was not waiting to be restarted. This would be a normal situation immediately after an IPL, or if the caller did not recycle the PFS. If the PFS is not found the call fails.

This call can be made before the PFS has finished terminating, in which case the LFS proceeds directly to the PFS restart when it does finally terminate.

If all copies of the PFS have been recycled and the PFS load module does not reside in the LPA, the first reattach of the load module brings a fresh copy into storage.

The PFS should run through a more or less normal PFS initialization sequence with respect to the LFS. The regular sequence of returning VFS and vnode operation vectors, posting the LFS ECB, and waiting for the PFS termination ECB must be followed.

On each restart of a PFS, the previously returned value of pfsi_pfsanchor is passed into the new instance of the PFS. The PFS may use a design in which this anchor points to persistent storage so that it can reuse or reclaim resources from a prior instance.

For File System PFSs, prior active mounts are reissued.

The PFS does not have to remember anything from one instance to the next with respect to the LFS and the LFS/PFS interfaces.