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-5
Using Sockets
For a discussion of interprocess communication between Guardian and OSS
processes, refer to the Open System Services Programmer’s Guide. It includes
interoperability tables, listing Guardian procedures and OSS functions that support
interoperability between the Guardian and OSS environments.
Traditional UNIX applications on shared memory systems are often written using the
assumption that process creation and interprocess communication (IPC) are relatively
cheap operations. These applications commonly have a server process that uses
fork() to create a child process for each work request; the parent and child
processes communicate using an IPC mechanism. Given the shared-nothing
architecture of the NonStop system, operations such as process creation and IPC
might use significantly more processor resources when a UNIX application is ported
without change. Refer to Porting Servers and Demons on page 6-23 for a discussion of
this situation.
Using Sockets
A socket is an end-point for communication between two processes. A socket is similar
to a file in that a process can create a socket, write data to it, read data from it, and
close it without regard to its underlying operations. Sockets are the most widely used
application program interface (API) for communication between processes running on
different systems.
The Guardian version of sockets was implemented for the versions of UNIX systems
developed at the University of California, Berkeley, by the Berkeley Software
Distribution (BSD) group. These sockets are often referred to as “Berkeley sockets” or
“BSD sockets.”
OSS sockets are based on BSD sockets (the OSS sockets interface is based on BSD
4.3 for AF_INET and AF_INET6, and BSD 4.3+ for AF_UNIX), but OSS sockets also
include limited extensions based on the X/Open XPG4 specification. The differences
between OSS sockets and BSD and Guardian sockets are discussed in Section 11,
Porting or Migrating Sockets Applications.
OSS sockets involve multiple system processes in the data path for each message,
even if both ends of the connection are on the same processor; as a result, the socket
OSS shared memory
(with OSS processes only)
Yes No No No
OSS semaphores
(with OSS processes only)
Yes No No No
$RECEIVE Yes Yes Yes No
Table 6-3. Interprocess Communication using OSS and Guardian
APIs (page2of2)
IPC method
Within a
processor
Between
processors
Between
Expand nodes
With other
systems