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

is ignored. In the OSS implementation, when a child process exits and SIGCHLD is ignored, the
child process is transformed into a zombie process. This may not be the case in other
implementations of UNIX. For example, in SVR4 UNIX, zombies are not created if SIGCHLD is
ignored. To avoid wasting system resources when terminating child processes and ignoring
SIGCHLD, you should take specific action to avoid the creation of zombie processes.
The POSIX.1 standard recommends that portable applications that create child processes include
signal-catching routines that call the wait() or waitpid() function to receive notification of the
termination of child processes. This avoids the creation of a zombie process when a child process
terminates.
The Open System Services Programmer’s Guide contains an example of a programming technique
for preventing zombie processes when child processes terminate. In the example program, the
child process uses the fork() function to create a duplicate of itself as a grandchild process and
immediately terminates. Then, when the grandchild process terminates, it cannot become a zombie
process because its parent has already terminated. This technique is recommended for portable
programs, since it will work for any implementation of SIGCHLD.
Performing File Operations
This subsection discusses file operations such as opening and creating files and directories and
enabling file caching. Like process operations, there is associated system overhead involved with
these operations. If the code you are porting performs a great deal of opening and closing of small
files as a common manner of execution, you may want to modify some of your code, in line with
some of the performance considerations discussed in This chapter.
The OSS name server is key to all pathname-oriented functions (for example, the open(), creat(),
readdir(), and stat() function calls). The OSS name server creates and finds inodes
(identification nodes), and it translates a name to a file system ID. It keeps the names and the
directory hierarchy in a database and shares management of regular disk files with Disk Process
2 (DP2).
In addition, the OSS name server shares the management of /dev/tty with Telserv, shares the
management of /dev/null with the OSS file system, and shares the management of FIFOs with
the OSS pipe server.
For a detailed comparison of the Guardian and OSS file systems, including topics such as file
management, file system functions, and interfacing with Guardian and OSS APIs, refer to the
discussion on managing files in the Open System Services Programmer’s Guide.
Opening an OSS File
A file open operation for an OSS file involves a number of steps. If the file specified in the open
request does not exist, it is created (if the O_CREATE flag is set). The following steps are involved
in opening an OSS file:
1. An application uses an open() function call (such as open(), open64(), fopen() or
fopen64()) to open an OSS file named /a/b. The OSS file system sends an open request
to the OSS name server.
2. The OSS name server receives the open request and attempts to map the OSS pathname to
a Guardian filename. This mapping step involves a file lookup step with the catalog.
3. The OSS name server replies to the client with a filename in the Guardian filename format
($DATA.ZYQ00000.Z000002H). Accessing the catalog (involving a disk access) is not done
when opening a Guardian file. (Because of the caching in the OSS name server, catalog
access during open processing might not be needed.)
4. Now equipped with a Guardian filename, the OSS file system sends an OSS open message
to the appropriate DP2 disk process.
This process and the related closes can involve many resources when done for many files. See
“Performance Considerations for Files” (page 101) for conserving system resources.
100 OSS Porting Considerations