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
Native Migration Overview
Open System Services Porting Guide—520573-006
10-4
Signal Handling for Guardian Processes
processes. This allows multiple versions of a DLL to be executed. One copy of a DLL
can serve multiple programs and processes.
To create a DLL or create a program that uses DLLs in the TNS/R native environment,
you must specify a compiler option to create a PIC linkfile, then use the ld linker to
produce a PIC program or loadfile. In the TNS/E native environment, all code is PIC;
therefore there is no need to specify a compiler option to create a linkfile; you simply
compile the program to create a linkfile, then use the eld linker to produce a PIC
program or loadfile.
Signal Handling for Guardian Processes
Signal handling replaces the TNS form of “trap handling” for native Guardian
processes. The existing OSS signal-related functions, such as sigaction(), are
available for native Guardian processes, replacing the TNS trap-handling procedures,
such as ARMTRAP. All signal-related functions are supported in native Guardian
processes except for kill(), because Guardian processes do not have an OSS
process ID. Signal handling for the TNS environment is unchanged. The Guardian
Programmer’s Guide discusses the signal-related functions available for Guardian
processes.
OSS and Guardian API Interoperability
Guardian and OSS API interoperability is provided by having similar OSS C and
Guardian C APIs. The C run-time library supports two variants of some functions that
support different semantics in the OSS environment than in the Guardian environment.
These include fopen(), freopen(), remove(), rename(), tmpfile(), and
tmpnam(). Explicit calls to the rename_oss() and rename_guardian() variants
can be made in the source code when the behavior of one environment is desired from
the other environment. For details on using these calls, refer to the reference pages
either online or in the Open System Services Library Calls Reference Manual and
Open System Services System Calls Reference Manual.
C Development Tools
The native compilers for C and C++ produce native object files in the executable and
linking format (ELF). ELF is commonly used on UNIX systems and is an open standard
that allows extensions.
There are fewer steps involved in compiling code using the native development tools
than using the TNS development tools. With the native tools, the programmer can
compile source files using the c89 utility, link object files using the nld, ld, or eld
utility, and use the SQL/MP compiler on the resulting object file or the SQL/MX
compiler on the resulting module definition file (if necessary). The native C compilers
accept ISO/ANSI C as well as Common C. The native C++ compilers have more
features than the TNS C++ preprocessor, such as forward declarations of class
specializations and nested templates, and make it easier to debug code.