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

In cases where the Guardian routines have no equivalents in the OSS environment, you have two
options. The first is to compile the module containing the Guardian C run-time routine as a Guardian
module; the second is to replace the module with an equivalent module. The second option will
make the program more portable to other open systems environments. You should refer to the
C/C++ Programmer’s Guide for more details on which C run-time routines work in which
environment. The API interoperability tables in the Open System Services Programmer’s Guide also
provide an overview of how and where each C run-time routine can be used.
In addition to the OSS C run-time routines, the XPG4 system calls, and most Guardian procedure
calls that can be used in an OSS program, some HP process-creation functions can also be used
in a program that is being migrated from the Guardian environment to the OSS environment. These
include tdm_fork() and the tdm_execve set of functions that can be used to create OSS
processes with specific Guardian attributes such as process name, processor number, process
priority, and home terminal. The tdm_spawn set of functions can be used to run an OSS program
with specific Guardian attributes in one automatic operation. These HP functions provide more
interoperability between the Guardian and OSS environments.
Use of Common Run-Time Environment (CRE) Functions
The Common Run-Time Environment (CRE) library functions provide a common set of services to
programs in both the OSS and Guardian environments. They can be used with the following
restrictions in the OSS environment:
• File sharing functions cannot be used.
• CRE mathematical functions do not trap if an invalid parameter is passed, but they do set the
errno variable.
• $RECEIVE processing functions cannot be used to access process startup sequence information,
including ASSIGNs and PARAMs. ($RECEIVE processing functions can continue to be used
for interprocess communication.)
These restrictions must be taken into consideration when migrating a Guardian program to the
OSS environment.
Replacing Guardian Procedure Calls With Equivalent OSS Functions
To make the program as open as possible and, therefore, portable to other UNIX environments,
you may want to replace some of the Guardian procedure calls with equivalent OSS C library
run-time calls or OSS system calls. There is no one-to-one replacement mechanism that can be
recommended for the Guardian procedure calls. The OSS file system routines are limited to dealing
with odd-unstructured files, EDIT files, and terminals. Thus, programs which need to deal with other
kinds of files will need to continue to use the Guardian procedures.
The OSS process-management routines deal with process IDs rather than with process handles.
Thus, programs which use Guardian process-management routines will need modifications to use
the equivalent OSS process-management routines. Because process termination is done with system
messages in the Guardian environment, and with exit() status and SIGCHLD signal in the OSS
environment, the logic of the Guardian program will need to be modified accordingly to work in
the OSS environment. Because most Guardian system procedure calls will continue to work in the
OSS environment as they did in the Guardian environment, a complete replacement of Guardian
system procedure calls with equivalent OSS system calls and run-time routines is not necessary.
Which IPC Mechanisms Can Be Used
The IPC mechanisms available to a Guardian program for communicating with other Guardian
programs and with OSS programs are generally available to an OSS program as well. The use
of $RECEIVE still requires using Guardian procedure calls, but Guardian sockets can be used in
OSS programs in the same way they are used in Guardian programs. Pipes can be used between
two related OSS processes, whereas they cannot be used in the Guardian environment. Files and
160 Migrating Guardian Applications to the OSS Environment