Open System Services Programmer's Guide

modules. See Chapter 1: Overview of the OSS Programming Environment (page 26) for a discussion
of when to write mixed-module applications.
Environment of the Module
The environment of a module is determined by the value of the SYSTYPE compiler pragma, which
directs the compiler to generate code appropriate for the specified target execution environment.
Environment of the Process
The environment of a process is determined by the environment of the module defining the main()
function.
Most functions and macros in the Guardian and OSS APIs can be called from a Guardian or OSS
module, which in turn can be part of a Guardian or OSS process. For example, the system()
function can be called only from a Guardian module in a Guardian process or from an OSS
module in an OSS process.
If you attempt to call the system() function in a module compiled for the Guardian environment,
and then link this module to a main() module compiled for the OSS environment (an OSS process),
you will get a run-time error. This is because the system resources and services required by the
Guardian variant function cannot be provided by the OSS process environment.
Some functions, such as fopen(), require environment-specific parameters. For example, if you
call the fopen() function with an OSS pathname in a Guardian process, the type of the parameter
does not match the type of the process, and a run-time error is generated.
Function and Macro Behavior
A function or macro that can be called in both the Guardian and OSS environments might behave
the same or differently in each environment. In general, behavior is identical when function
parameters are environment independent, and it is different when function parameters are
environment specific.
Functions With Environment-Specific Parameters
The fopen(), fopen64(), freopen(), freopen64(), remove(), rename(), tmpnam(),
and tmpfile() functions require that the type of the parameters match the type of the process.
For example, in an OSS process, the file to be operated on must be indicated by an OSS pathname.
(Remember that files in /G have OSS pathnames.) In a Guardian process, the file to be operated
on must be indicated by a Guardian filename.
Note that the parameter type need not match the process type in the environment-specific variants
of these functions. For example, the fopen_guardian() function opens a Guardian file from
within an OSS or Guardian process.
Functions With Environment-Independent Parameters
Most of the functions and macros available in both the Guardian and OSS environments behave
the same, regardless of the environment, because they take environment-independent parameters.
For example, string functions such as strcat() are identical in the Guardian and OSS
environments. The malloc() function can allocate a block of memory in a Guardian module and
the free() function can free the same block of memory in an OSS module.
Internationalization Functions
In Guardian processes, regardless of whether modules are compiled to run in the Guardian or
OSS environment, only the C/POSIX locale is available. In OSS processes, full internationalization
support is available if the required locales are purchased and installed on the system.
Using the API Interoperability Tables
Some functions and macros in the Guardian and OSS APIs can interoperate completely between
the Guardian and OSS environments: that is, they can be called from either a Guardian or OSS
module, can execute as part of a Guardian or OSS process, and can operate on Guardian or
Using the API Interoperability Tables 501