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

• “Language or C Environment Type” (page 148)
• “API Interoperability” (page 148)
• “Side Effects” (page 149)
Memory and Data Models to Be Used
The C language supports three combinations of memory and data models (small, large, wide),
varying in the width of an integer, in the width of a pointer, and in various combinations thereof.
OSS functions support only the wide-data model (int is 32 bits). Thus, the use of OSS routines is
confined to Guardian programs that use the wide-data model, which is true for both C and TAL
programs. For more information about these memory and data models, see “Memory and Data
Models in TNS and Native Environments” (page 140).
Beginning with the H06.24 and J06.13 RVUs, both the ILP32 and LP64 data models are supported
and 64-bit addressable memory is available. For information about these data models and 64-bit
addressable memory, see the 64-Bit Support in OSS and Guardian chapter in the Open System
Services Programmer's Guide.
Process Target Type
The target of a module, chosen at compile time, determines the environment of the routines being
selected. The chosen target interacts with special toggles (feature test macros) in the header files
to select particular implementations appropriate for the target. Usually, all modules of a program
have the same environment and are bound together into a program that runs as a process of that
environment.
To include OSS functions in a Guardian program, separate compilation of modules containing
OSS functions may be necessary. Because the environment of the process is determined by the
environment of the module containing the main() function (Guardian in this case), the Guardian
program may consist of mixed environment modules. The target type defines the set of process
attributes a process has. Because Guardian processes have a subset of the attributes associated
with OSS processes, Guardian processes cannot use all of the OSS functions.
Guardian programs can include:
• Single-environment (Guardian) functions
• Per-environment functions
• Opposite-environment (OSS) functions
• Both-environment functions
In some cases, there is only one version of a function, and it is intended for use only within a single
environment. For example, waitpid() can be used only in an OSS program, and
fopen_std_file() can be used only in a Guardian program. Thus, OSS functions that fall into
this category cannot be used in Guardian programs.
Both targets also contain per-environment functions with the same name but with different
implementations in each environment. The versions are usually simply incompatible. For example,
for TNS processes, there are both OSS (G-series only) and Guardian versions of raise() and
setjmp(); Guardian programs must use the Guardian versions of these functions; otherwise
unpredictable results are possible. There is one version of the C run-time library for the native
environment, so there is more API interoperability. Refer to the API interoperability tables in the
Open System Services Programmer’s Guide.
Use of Environment-Specific Functions
Sometimes there are two different implementations of a function, one for each environment, but
either of these opposite-environment functions can be used within a single program. For example,
a Guardian process can call an OSS function such as fopen(). Users of such functions should
Using OSS Functions in a Guardian Program 147