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-14
Using fork() and the exec Set of Functions in OSS
When you create OSS processes with fork() and the exec set of functions, the
attributes of the parent process are propagated to the child process, but the child
process has an OSS process ID that uniquely identifies it. An OSS process can send
signals to and receive signals from other OSS processes. In both UNIX and Open
System Services, you can query and modify the process environment using functions
such as getpid() and putenv(). As in UNIX, OSS processes receive notification
when a child process terminates, with the SIGCHLD signal and using the wait() and
waitpid() functions.
The HP extension functions, tdm_fork() and the tdm_execve set, perform the
same functions as the OSS fork() function and the exec set of functions, except the
HP extension functions use these additional parameters:
•
The pe_parms parameter points to an input structure, containing Guardian
process attributes to assign to the new process. The input structure is defined in
the tdmext.h header file, including default initialization values for this structure.
The initialized values can then be modified as appropriate for the call. Another
argument is a pointer to an output structure, which is defined along with its default
initialization values in the tdmext.h header file.
•
The pr_results parameter points to the output structure containing optional
process identification and error information. In case of an error, pr_results
provides additional information, including the PROCESS_LAUNCH_ error and
error detail needed by some Guardian management programs and procedures.
These additional parameters bring more interoperability and Guardian features to
your programs.
With the HP extension functions, you can set or modify inherited Guardian attributes by
specifying values for the fields in the input structure that contains Guardian attributes.
This modification cannot be done with fork() and the exec set of functions in the
UNIX environment or OSS environment.
For example, when creating a process with the tdm_fork() and tdm_execve()
functions, you can specify, with the tdm_execve() function call, the processor on
which a process executes. This capability allows you to distribute an application
program across processors. You can also specify the debug options to create a
saveabend (or core or snapshot) file if the process terminates abnormally.
You can create a child process across processors with a tdm_fork() function call by
following it with a call of one of the tdm_execve set of functions to another processor.
The call to one of the tdm_execve set of functions causes a child process to migrate
to the second processor. (The process making the tdm_fork() call and the process
making the call to one of the tdm_execve set of functions reside in the same program
and processor.) The Open System Services Programmer’s Guide includes an example
of creating an OSS process with tdm_fork() and the tdm_execve set of functions
and details on managing OSS and Guardian processes.
However, to avoid the overhead of copying memory buffers across processors and
initializing extra processes, use the tdm_spawn set of functions instead. See Using