Open System Services Porting Guide (G06.29+, H06.06+, J06.03+)

For systems running AF_UNIX Release 2 software, calls to the OSS sockets functions for AF_UNIX
connections can use an alternate transport-provider name to specify the semantics to use:
• Using the $ZPLS transport-provider name specifies that compatibility mode be used.
Compatibility mode sockets have the same characteristics and behavior as AF_UNIX Release
1 software semantics. Using compatibility mode allows you to migrate applications to systems
running AF_UNIX Release 2 software without making changes to the application. $ZPLS is
the default transport-provider name and sockets are created in compatibility mode by default.
• Using the $ZAFN2 transport-provider name specifies that portability mode be used. Portability
mode socket have characteristics and behaviors similar to other AF_UNIX implementations,
such as Linux and HP-UX.
Sockets in compatibility mode can communicate only with other sockets in compatibility mode.
Sockets in portability mode can communicate only with other sockets in portability mode. After a
socket has been created, its mode cannot be changed.
You can set the transport-provider name by setting the Guardian MAP DEFINE
=_AFUNIX_PROCESS_NAME or by calling the socket_transport_name_set() function. The
current transport-provider name can be determined by calling the
socket_transport_name_get() function.
For more information about AF_UNIX Release 2 software, compatibility mode, and portability
mode, see the Open System Services Programmer's Guide.
For systems running AF_UNIX Release 1 software, $ZPLS is the only transport-provider name
supported.
Using the stat(), stat64(), fstat() and fstat64() Functions
For files other than regular OSS files, the stat() , stat64(), fstat(), and fstat64()
functions return zero as the value for the st_size field of the stat structure and 4096 as the
value for directories. For regular OSS files, the size of the file is returned.
For Guardian EDIT files, the st_size field specifies the actual (physical) end of a file, not the
number of bytes in the file. For Guardian files, the st_dev and st_ino fields of the stat structure
do not uniquely identify Guardian files. The st_dev field is unique for /G, for each disk volume,
and for each Telserv process. The st_ctime and st_atime fields for Guardian regular files are
updated by OSS function calls, not by Guardian procedure calls. There is a mapping for each
Guardian file type to one of directory, regular file, or character special file type in the st_mode
field. These mappings are listed in the stat(2) reference page either online or in the Open System
Services System Calls Reference Manual.
Using the unlink() Function
The unlink() function is not supported for Guardian directories, structured files, and OSS
directories.
See also “Special Considerations for Files in Restricted-Access Filesets” (page 122).
Using OSS Process Function Calls
Most process-related function calls that implement the POSIX.1 standard or XPG4 specifications
have no side effects or implementation-defined behavior when operating on OSS processes.
However, some function calls can also manipulate Guardian processes. Some operations on
Guardian processes behave differently from the same operations on OSS processes.
Operations on Guardian processes with OSS function calls are limited because Guardian processes
do not have process IDs. Access to processes is determined by the security model of the object;
Guardian processes are protected by the Guardian security model, and OSS processes are protected
by the POSIX.1 security model. The process-related function calls that exhibit implementation-defined
behavior or that behave differently when manipulating Guardian processes are discussed here.
OSS C Programming Considerations 127