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

need to be rewritten to use a standard function, one close to the original functionality. This
requirement is particularly true for old Berkeley Software Development (BSD) and System V Release
4 UNIX (SVR4) programs that use nonstandard functions. See “Using Functional Equivalents”
(page 111) for further details.
Single-Processor Versus Multiprocessor Systems
Most UNIX programs today are written to run on a single-processor architecture. When porting to
the OSS environment, a program should first be ported to a single-processor environment. This
strategy should simplify the porting effort without requiring major design changes to the program;
all of the guidelines discussed earlier should be followed for this port.
After the program is ported to a single-processor configuration in the OSS environment, you can
make design changes to enhance the performance of the program for a loosely coupled,
multiprocessor environment. As discussed in Chapter 6 (page 85), significant performance
improvements can be achieved in redesigning a server to run as a super server. Each slave server
runs as a persistent process in a separate processor, thus avoiding process-creation and termination
overhead for each request handled by the server (super server).
HP Extensions
If you want the UNIX program being ported to the OSS environment to be portable back to the
UNIX environment, HP extensions to the standard functions and functions specific to HP should be
used only as a last resort. Some standard functions have been extended to take advantage of the
OSS environment and to access Guardian objects. Additionally, functions have been added to
provide OSS processes with attributes found only in the Guardian environment.
Further, OSS application programs have access to many of the Guardian procedure calls typically
used by programs running in the Guardian environment. All of these HP extensions are available
to OSS applications.
Programming for Portability
There are general guidelines in making programs portable. One good programming practice to
make it easier to port your program to other environments is to use a template that forces you to
structure your source code in a modular way. This template could consist of the elements described
in “You Should Use Portable Application Templates” (page 23), and further explained in Lewine’s
POSIX Programmer’s Guide (see “Related Information” (page 18)).
Other good guidelines to follow include:
• Avoid machine dependencies in the manipulation of internal data structures. For example, do
not use multicharacter char constants or code that makes assumptions about padding or byte
order internal to structure elements. Refer to “Resolving the Endian Problem” (page 168) for
examples and more specific guidelines about one such problem.
• Define the formats of program data transfers within the program in a hardware-independent
way. (The actual transfers can take place through intermediate disk files or through an
interprocess-communication mechanism.)
• Use a common subset of function calls, wherever possible.
• When using a nonportable feature is essential, use a generic function which in turn calls the
nonportable function available under each of the operating system environments supported.
A library of machine-dependent features can be used to create an operating system environment
that is a superset of the target operating system.
• System-dependent features should be isolated into a machine-dependent module that provides
a common interface in all implementations.
These practices are primarily applicable to new programs, but you may get an opportunity to
apply them when porting existing UNIX programs.
110 Porting UNIX Applications to the OSS Environment