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
Porting or Migrating Sockets Applications
Open System Services Porting Guide—520573-006
11-2
Differences Between OSS Sockets and Berkeley
Software Distribution Sockets
be named by setting the Guardian MAP DEFINE =TCPIP^PROCESS^NAME for
the sockets application before starting the application or by calling the
socket_transport_name_set() function while the application is running. The
current transport provider process name can be determined by calling the
socket_transport_name_get() function. If you want to use Parallel Library
TCP/IP or NonStop TCP/IPv6, use one of these methods to specify a TCPSAM or
TCP6SAM process name for the transport service provider. For information about
how to determine the name of a TCPSAM or TCP6SAM process, refer to the
TCP/IP (Parallel Library) Configuration and Management Manual or the TCP/IPv6
Configuration and Management Manual.
HP does not support changing the transport provider process for AF_UNIX
sockets. The default transport provider process for AF_UNIX sockets is $ZPLS.
•
The OSS ioctl() function does not conform to a published standard. Refer to
the ioctl(2) reference page either online or in the Open System Services
System Calls Reference Manual for a description of its capabilities.
Differences Between OSS Sockets and Berkeley Software
Distribution Sockets
The differences between OSS sockets and Berkeley Software Distribution (BSD)
sockets are:
•
The OSS sockets application program interface (API) is based on BSD 4.3 for
AF_INET and AF_INET6, and BSD 4.3+ for AF_UNIX, with extensions for
AF_INET and AF_UNIX based on the X/Open XPG4 standard. AF_INET6
extensions are based on RFC 2553 Basic Sockets Interface Extensions for IPv6.
•
On UNIX systems older than System V release 4 (SVR4), the sockets functions
are normally found in the library named /usr/lib/libinet.a. On SVR4 and
newer UNIX systems, the functions are found in the library named
/usr/lib/libsocket.a.
Two OSS libraries contain additional support functions for AF_INET and
AF_INET6 sockets, as listed in Table 11-3 on page 11-8: a shared run-time library
(SRL) intended for use by TNS/R native applications and a static library for use by
TNS applications. The SRL is located in /G/SYSTEM/SYSnn/zinetsrl, and the
static library is located in /usr/lib/libinet.a.
•
Open System Services provides the following sockets-related functions that are not
found on UNIX systems:
°
sockatmark(), which determines when a socket is at an out-of-band mark
with respect to its data. Processes can call this function instead of calling the
ioctl() function to set the SIOCATMARK flag.
OSS AF_UNIX sockets do not currently support sockatmark().
°
socket_transport_name_set(), which an application can call to specify
the name of the transport provider process to use.