Open System Services Porting Guide (G06.24+, H06.03+)

Porting UNIX Applications to the OSS Environment
Open System Services Porting Guide—520573-006
7-19
Using OSS Function Calls
Using OSS Function Calls
The OSS function calls specified by the POSIX.1 and POSIX.2 standards are
compliant with those standards. However, the POSIX standards do allow for
implementation-defined behavior, which is described in this subsection. UNIX
application programs ported to the OSS environment might be affected by this
behavior. Because many of the OSS file system and process-control function calls can
also manipulate Guardian objects, access to Guardian objects can affect the behavior
of the function call. Some error codes can be returned by these function calls that
would not be returned in a UNIX environment. These errors are documented in the
online reference pages for the OSS function calls.
OSS File Function Calls
Most file-related function calls that implement the POSIX standards or the XPG4
specifications have no side effects or implementation-defined behavior when used with
OSS files. Some of these function calls on Guardian files behave differently from the
same operations on OSS files.
The Guardian files that can be operated on are limited to odd-unstructured, EDIT, and
terminal emulation processes. Access to files is determined by the security model of
the object. Guardian files are protected by the Guardian security model; OSS files are
protected by the POSIX.1 security model. The file-related function calls that exhibit
implementation-defined behavior or which behave differently when manipulating
Guardian files are discussed following.
Using the access() Function
For the access() function call, the behavior on OSS files is defined by the POSIX.1
standard with minor implementation-defined behavior. When the filename resolves to
the /G directory, the permissions are “r-xr-xr-x.” For Guardian volumes and
subvolumes, the permissions are “rwxrwxrwx.” For a Guardian disk file, Guardian
standard security and Safeguard file-level protection govern access.
Using the chdir() Function
The chdir() function call has no implementation-defined behavior on OSS
directories, but it does exhibit some Guardian specific behavior. chdir() can point to
a nonexistent (empty) Guardian subvolume, but pointing to a Guardian subvolume with
a reserved name such as /G/zyq00001/z000002h results in an error.
Using the chmod() Function
The effect of the chmod() function call on open files is implementation-defined,
according to the POSIX.1 standard. A call to chmod() has no effect on the file
descriptor for a file that is open at the time of the call. New openers of the file are
authenticated using the new access permissions specified in the call. An attempt to set
the permission bits on a Guardian file results in an error because Guardian security
rules apply.