Open System Services Porting Guide (G06.24+, H06.03+)
Table Of Contents
- What’s New in This Manual
- About This Manual
- 1 Introduction to Porting
- 2 The Development Environment
- 3 Useful Porting Tools
- 4 Interoperating Between User Environments
- Purpose of Interoperability
- The OSS User Environment
- OSS Commands for the Guardian User
- Guardian Commands for the UNIX User
- OSS Pathname and Guardian Filename Conversions
- Running the OSS Shell and Commands From TACL
- Running Guardian Commands From the OSS Shell
- Running OSS Processes With Guardian Attributes
- Using OSS Commands to Manage Guardian Objects
- 5 Interoperating Between Programming Environments
- 6 OSS Porting Considerations
- 7 Porting UNIX Applications to the OSS Environment
- 8 Migrating Guardian Applications to the OSS Environment
- General Migration Guidelines
- C Compiler Issues for Guardian Programs
- Using New and Extended Guardian Procedures
- Using OSS Functions in a Guardian Program
- Interoperating With OSS Programs
- Starting an OSS Program From the Guardian Environment
- C Compiler Considerations for OSS Programs
- Porting a Guardian Program to the OSS Environment
- How Arguments Are Passed to the C or C++ Program
- Differences in the Two Run-Time Environments
- Which Run-Time Routines Are Available
- Use of Common Run-Time Environment (CRE) Functions
- Replacing Guardian Procedure Calls With Equivalent OSS Functions
- Which IPC Mechanisms Can Be Used
- Interactions Between Guardian and OSS Functions
- 9 Porting From Specific UNIX Systems
- 10 Native Migration Overview
- 11 Porting or Migrating Sockets Applications
- 12 Porting Threaded Applications
- A Equivalent OSS and UNIX Commands for Guardian Users
- B Equivalent Guardian Commands for OSS and UNIX Users
- C Equivalent Inspect Debugging Commands for dbx Commands
- D Equivalent Native Inspect Debugging Commands for dbx Commands
- E Standard POSIX Threads Functions: Differences Between the Previous and Current Standards
- Glossary
- Index
OSS Porting Considerations
Open System Services Porting Guide—520573-006
6-15
Using the tdm_spawn Set of Functions for Load
Leveling
the tdm_spawn Set of Functions for Load Leveling on page 15 for more information on
creating a process in another processor.
Using the tdm_spawn Set of Functions for Load Leveling
Like fork() and the exec set of functions, the tdm_spawn set of functions creates a
child process. It performs generally the same operations as fork() and the exec set
of functions, but in one step. The tdm_spawn set of functions has the same extra input
and output parameters (pe_parms 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_.