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

POSIX standards as much as possible. If your program can use a standard set of interfaces, follow
the XPG4 specifications because most UNIX platforms conform to them.
If performance is a priority, consider the changes discussed under “Using Interprocess
Communication (IPC) Mechanisms” (page 88). Then consider using some of the HP extensions,
which take advantage of the NonStop system architecture. For example, you can use almost all
the Guardian procedure calls in your C program in the OSS environment. However, the more you
use the HP extensions and Guardian procedures, the less portable your program becomes to other
UNIX environments.
If you use the HP extensions, do one of the following:
• Put the system-dependent code in isolated modules where possible. This practice allows you
to replace the isolated code in future porting. You can use the make utility to build and link
in the correct modules for the environment in which your program will run. See “Using HP
Extensions” (page 129), which discusses placing extensions in separate modules to get both
portable code and high performance.
• Use the conditional compilation feature (#ifdef and related feature test macros) of the HP
C compiler for NonStop systems to create a program that contains the system-dependent code
only when the program is compiled for execution on a NonStop system. This practice allows
you to write and maintain portable cross-platform code when your site has the same application
on systems running versions of the UNIX operating system in addition to the OSS environment.
See “Predefined Preprocessor Symbols” (page 157), which discusses conditional compilation
of system-dependent code.
Using Process-Creation Calls
This subsection discusses the OSS process-creation functions: fork(), tdm_fork(), and the
exec, tdm_execve, and tdm_spawn sets of functions. It compares process-creation functions
between UNIX and OSS environments and discusses methods to improve performance. For detailed
descriptions of each OSS process-creation function, refer to the online reference pages or to the
Open System Services System Calls Reference Manual.
If your program uses a lot of process-creation function calls (or script files which contain a lot of
of short commands, each requiring a process creation), your program will experience more
overhead than it might experience on other UNIX systems. This is because the process-creation
overhead is higher on Open System Services than it is on most UNIX systems. You might wish to
consider redesigning your program to make it run more efficiently.
Beginning with the H06.24 and J06.13 RVUs, 64-bit OSS processes are supported. For information
about 64-bit OSS processes, see the 64-Bit Support in OSS and Guardian chapter in the Open
System Services Programmer's Guide.
Using fork() and the exec Set of Functions in UNIX
In UNIX environments, a process uses the fork() function call to create another process. The
process that issues fork() is known as the “parent process”; the process created by fork() is
known as the “child process.”
When you use the fork() function call, you usually call one of the exec set of functions
immediately after it. Creating processes this way is somewhat inefficient. First, the existing process
(the parent) calls the fork() function, producing a new process (the child), which is a copy of
the parent process. One of these processes (normally, the child) then calls one of the exec set of
functions. Calling one of the exec set of functions determines what you want to run within that
process and overlays the new process with a copy of the new process image—note the redundancy
of new process creations. This redundancy is more apparent in the OSS environment, because
there is more processor cross-checking performed than done in a UNIX environment and because
calling one of the exec set of functions in the UNIX environment does not create a new process.
96 OSS Porting Considerations