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 UNIX Applications to the OSS Environment
Open System Services Porting Guide—520573-006
7-18
OSS C Run-Time Library
The values of the following file-implementation characteristics are not available at
compile time but by using the fpathconf() and pathconf() functions:
Device Interfaces
The commonly used device interfaces, /dev/null and /dev/tty, are supported in
the OSS environment. There is no direct API to the tape or line printer through the
standard OSS functions. These devices must be accessed using Guardian procedure
calls. The OSS pax utility can be used to access Guardian tape devices using the
/G/tape file, and the OSS lp utility can be used to access the Guardian SPOOLCOM
printing utility. Refer to the pax(1) and lp(1) reference pages either online or in the
Open System Services Shell and Utilities Reference Manual.
Even though the /etc/passwd and /etc/group data files are not provided in the
OSS environment, the data normally kept in these files is accessible by standard
function calls provided in the OSS C run-time library: for example, getgrgid() and
getgrname().
OSS Programs and CRE
The Common Run-Time Environment (CRE) library functions provide a common set of
services to programs, supporting many programming languages. Your programs might
implicitly call CRE library functions because the C run-time library calls the CRE
functions to implement many features.
OSS programs are CRE-compliant. You can call explicitly many CRE library functions
from both OSS and Guardian modules. Services provided for the OSS environment
include:
•
Process initialization and termination routines
•
Management of user and run-time heaps
•
Math and string functions
•
Access to standard functions
•
Direct interface to Guardian procedures
Further information on CRE library functions can be found in Section 8, Migrating
Guardian Applications to the OSS Environment, and in the Common Run-Time
Environment (CRE) Programmer’s Guide.
LINK_MAX Maximum number of links to the file
MAX_CANON Maximum number of bytes in a canonical input line
MAX_INPUT Maximum number of bytes an application can require as input before
that input is read
NAME_MAX Maximum number of bytes in a filename (not including a terminating
null)
PIPE_BUF Maximum number of bytes guaranteed to be written atomically when
writing to a pipe or FIFO file