Open System Services Programmer's Guide

Process Ancestors
The creator process of an OSS process is the “parent” process of the newly created “child” process.
The child process inherits many OSS and Guardian attributes of the parent process.
The creator process of a Guardian process is the “MOM” process of the newly created process if
the new process is unnamed. If the new process is named, the creator process is its “ancestor.” A
Guardian process inherits some attributes from its ancestor or MOM if the attributes are not specified
in the call to the PROCESS_LAUNCH_ procedure. For more information about relationships between
Guardian processes, see the Guardian Programmer’s Guide.
Process Attributes
All processes, OSS and Guardian, have Guardian attributes and some OSS attributes. OSS
processes have additional OSS-specific attributes, such as an OSS process ID. Open System
Services includes standard UNIX functions such as the fork() function and the exec set of functions
as well as HP extension functions, which are tdm_fork(), tdm_execve(), tdm_execvep(),
tdm_spawn(), and tdm_spawnp(). The HP extension functions allow you to set attributes when
a process is created that you cannot set with standard UNIX functions.
For example, when you create a new OSS process image with the execve() function, the new
process retains many attributes of the calling process, and you cannot overwrite them in the call
to execve(). The tdm_execve() function allows you to either retain the caller’s attributes or
specify other values. For example, you can change the attribute specifying the processor in which
a process executes.
Beginning with the H06.24 and J06.13 RVUs, you can determine if a process is a 32-bit or 64-bit
OSS process and if a system (local or remote) can run 64-bit OSS processes. See “Process Type
Attribute” (page 287) for details.
Process Environment
The run-time environment of an OSS process is defined using environment variables. A Guardian
process uses PARAMs, ASSIGNs, and DEFINEs to define its environment, but a Guardian process
also has environment variables if it is created using Guardian C functions.
Process Pairs
A Guardian process can belong to a process pair, which consists of a primary process that performs
the application and a secondary (backup) process in another processor that is ready to take over
if the primary process fails. Process pairs provide one way in which you can create fault-tolerant
applications. You implement process pairs using Guardian checkpointing procedures (passive
checkpointing) or by sending explicit messages from the primary to the backup process (active
checkpointing).
Prior to the J06.14 and H06.25 RVUs, an OSS process cannot belong to a process pair.
Beginning with the J06.14 and H06.25 RVUs, OSS process pairs are supported. For details of
OSS process pairs, see “OSS Process Pairs” (page 158).
Native and TNS Processes
A TNS/R native process is initiated by executing a TNS/R native object file; TNS/R native object
code executes only on TNS/R systems. A TNS/E native process is initiated by executing a TNS/E
native object file; TNS/E native object code executes only on TNS/E systems. A TNS process is
initiated by executing a TNS interpreted or accelerated object file; TNS object code executes on
TNS, TNS/R, and TNS/E systems.
On TNS/R systems, OSS and Guardian processes can be either TNS/R native or TNS processes.
On TNS/E systems, Guardian processes can be either TNS/E native or TNS processes, but OSS
processes can only be TNS/E native processes; the TNS/E OSS environment does not support
TNS processes.
36 Overview of the OSS Programming Environment