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

and pr_results) for modifying Guardian attributes as described for tdm_fork() and the
tdm_exec set of functions.
You can use the tdm_spawn set of functions to create a process in another processor, and it is
generally more efficient than the combined use of tdm_fork() and the tdm_execve set of
functions. The behavior of the tdm_spawn set of functions differs from that of tdm_fork() and
the tdm_exec set of functions in that the tdm_spawn set has more control over which files are
kept open and which attributes are inherited in the child process. Overall, the tdm_spawn set of
functions is a more efficient method of creating a process in the same or another processor, and
it helps balance system processing across available processors. The Open System Services
Programmer’s Guide includes an example of creating an OSS process with tdm_spawnp().
Using PROCESS_SPAWN_
If you need to create an OSS process from the Guardian environment, use the Guardian
PROCESS_SPAWN_ procedure call. This procedure is mainly used by Guardian programs that
need to run OSS processes, thereby supporting interoperability between the Guardian and OSS
environments. PROCESS_SPAWN_ creates an OSS process, which can then be manipulated by
both Guardian and OSS processes. However, it is usually manipulated by Guardian processes,
such as monitor programs that must manage both Guardian and OSS processes.
Persistent OSS processes can be created by calling PROCESS_SPAWN_ from a Guardian monitor
process pair. With the PROCESS_SPAWN_ procedure, you can specify that the new process be
created in either a waited or nowait manner. When it is created in a waited manner, identification
for the new process is returned directly to the caller. When it is created in a nowait manner, its
identification is returned in a system message sent to the caller’s $RECEIVE file, which is a special
file through which a process receives system messages or messages from other processes.
The process that calls PROCESS_SPAWN_ receives process termination notification through
Guardian system messages by reading $RECEIVE.
The caller of the PROCESS_SPAWN_ procedure becomes the Guardian parent of the new OSS
process, regardless of whether it is an OSS or Guardian process. Files are opened in the child
process, but they are not propagated or shared.
Refer to the Guardian Procedure Calls Reference Manual for a detailed description of
PROCESS_SPAWN_. The Open System Services Programmer’s Guide contains a sample program
that creates an OSS process using PROCESS_SPAWN_.
Which Call to Use for Process Creation
Of the various process-create functions in the OSS and Guardian environments, you will need to
consider the features of each and match the feature to whether you need more performance or
more portability. The advantages and disadvantages of each call follow:
• fork() function and exec set of functions
More portable code without the HP extensions◦
◦ More features than a spawning operation: see online reference pages
◦ More system overhead than a spawning operation
◦ Less flexible than the tdm_fork() function and the tdm_exec set with regard to the
NonStop architecture and modification of Guardian attributes
◦ File opens are propagated to the child process
• tdm_fork() function and tdm_exec set of functions
Less portable than the fork() function and the exec set because of HP extensions◦
◦ tdm_exec set of functions can be used to run a program image in another processor,
thereby providing load balancing
98 OSS Porting Considerations