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-7
Compiling Native and TNS OSS Programs
•
Marking existing sockets as nonblocking using the fcntl() function
•
Performing reads or writes on any sockets that are ready
•
Handling the errno value EWOULDBLOCK and retrying the input or output
later when necessary
Table 11-2 summarizes the differences between nonblocking (OSS) and nowait
(Guardian) sockets I/O.
Compiling Native and TNS OSS Programs
To compile native OSS applications, you must use the TNS/R or TNS/E native mode
c89 compiler. The following OSS shell command compiles and links the native sockets
program nsock.c:
c89 -o nsock nsock.c -l c -D _XOPEN_SOURCE_EXTENDED = 1
-D _TANDEM_SOURCE
To compile G-series TNS OSS applications, you must use the TNS c89 compiler. TNS
AF_INET sockets applications must be linked with the shared sockets library
libinet.a, which resides in /usr/lib. The following OSS shell command compiles
the TNS sockets program nnsock.c:
/nonnative/usr/c89 -o nnsock nnsock.c -l inet -l c
-D _XOPEN_SOURCE_EXTENDED = 1 -D _TANDEM_SOURCE
See the C/C++ Programmer’s Guide and the nld Manual, the ld Manual, or the eld
Manual for more information on compiling and linking native C and C++ programs.
Table 11-2. Major Differences Between OSS and Guardian Sockets Input/Output
OSS Nonblocking I/O Guardian Nowait I/O
A socket is created with socket() and
fcntl(fd, F_SETFL,O_NONBLOCK)
makes the socket nonblocking.
A socket is created as waited with
socket()
or as a nowait socket with socket_nw().
When a socket I/O call is made, control is
returned immediately to the application.
Either the operation is performed or the
error
EWOULDBLOCK is returned.
When a socket I/O call is made, control is
returned immediately to the application. The
operation is performed concurrently with the
application execution. The status of the I/O
completion must be checked with a Guardian
procedure call.
A socket operation requires a single buffer.
For example, four recv() calls require one
buffer.
Every socket operation requires a separate
preallocated buffer. For example, four recv()
calls require four buffers.
The
select() function waits for
specified file descriptors for the next
opportunity to issue a nonblocking I/O call.
AWAITIOX operates on file numbers rather
than file descriptors. FILE_COMPLETE_ allows
waiting for completion on file numbers and on
the readiness of file descriptors;
FILE_COMPLETE_ therefore acts like a
combination of AWAITIOX and select().