Sharing a File

Accessing and controlling a ￿le that is open only to y ou is a relatively simple matter. However, when several users are sim ultaneously accessing a ￿le, eac h user must be aware of special considerations for sharing the ￿le:

How will others be allow ed concurrent access to the ￿le?

Will concurrent access require special managemen t?

When an HPFOPEN or FOPEN intrinsic call is issued for a ￿le, the File System regards the request as an individual accessor of the ￿le and establishes a unique ￿le n umber and other ￿le control information for the ￿le. Ev en when a program issues sev eral di￿erent HPFOPEN or FOPEN intrinsic calls for the same ￿le, eac h call is treated as a separate accessor. Under the normal (default) securit y provisions of MPE/iX, when an accessor opens a ￿le not curren tly in use, the access restrictions that apply to this ￿le for other accessors depend on the access mode this ￿rst accessor requested:

If the ￿rst accessor opens a ￿le for read-only access, then an y other accessor can open it for any other type of access (for example, write-only or append). Ho wever, the other accessors are prohibited exclusiv e access.

If the ￿rst accessor opens a ￿le for an y other access mode (for example, write-only , append, or update), this accessor main tains exclusive access to the ￿le un til it closes it; no other accessor can access the ￿le in an y mode.

A program can override the defaults b y specifying other options in HPFOPEN and FOPEN intrinsic calls. A user running this program can, in turn, o verride both the defaults and programmatic options b y using the :FILE command. Table 6-7 describes these options and the actions MPE/iX tak es when the options are in e￿ect and sim ultaneous access is attempted by other HPFOPEN or FOPEN intrinsic calls. The action depends on the curren t use of the ￿le and the access requested.

File System 6-35