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
Migrating Guardian Applications to the OSS
Environment
Open System Services Porting Guide—520573-006
8-6
Memory Models
•
On H-series systems, the Visual Inspect debugger can be used to debug programs
compiled with the Guardian TNS or TNS/E native compilation components and
with the OSS TNS/E native compilation components.
•
On H-series systems, the Visual Inspect debugger can be used to debug TNS/R
snapshot files that were generated on a G-series system and transferred to an
H-series system.
In addition to these debuggers, the noft utility can be used to view TNS/R native
object files. The enoft utility can be used to view TNS/E native object files. See
Section 2, The Development Environment, and the noft Manual and enoft Manual for
more information about using noft and enoft.
Memory Models
Table 8-1 shows the memory models available in the Guardian environment. Guardian
native programs use only the wide memory model.
If you are porting Guardian programs that use the small-memory or large-memory
model, you will have to convert your code to use large-memory model and the 32-bit
(or wide) data model. General guidelines for doing this conversion are discussed in:
•
Section 10, Native Migration Overview
•
TNS/R Native Application Migration Guide.
•
TNS/E Native Application Conversion Guide
Header Files
A single set of C library header files supports both the Guardian and OSS
environments. In the Guardian environment, header files are in $SYSTEM.SYSTEM by
default. In the OSS environment, header files are in /usr/include and its
subdirectories by default. Because the OSS C compiler requires that header files use
the OSS pathname syntax, all header files must be specified in this syntax. All uses of
#include preprocessor directives in the Guardian C source program must be
modified to use the OSS pathname syntax.
Table 8-1. Memory Models Supported by the TNS Guardian System
Memory Model Address Pointer int Size Stack Segment Data Heap Segment
Small 16 bits 16 bits 64 KB -
Large 32 bits 16 bits 64 KB 128 MB
Wide 32 bits 32 bits 1 MB 128 MB
Note. You do not need to convert existing OSS C and C++ programs because OSS supports
only the large-memory model and the 32-bit (or wide) data model.