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-11
Guardian File System Procedures
The USER_AUTHENTICATE_ procedure is used to verify that a user exists and
optionally to log a user on. Also, USER_AUTHENTICATE_ can get the initial working
directory and the initial program in the OSS environment for the specified user.
The USER_GETINFO_ procedure returns the default attributes of a user specified by
user name, Guardian user ID, or alias. Also, USER_GETINFO_ can get the initial
working directory and the initial program in the OSS environment for the specified user.
The USER_GETNEXT_ procedure obtains the next user name or alias following the
specified name, in the order in which they are stored by the security mechanism in
effect.
Guardian File System Procedures
OSS files can be manipulated using Guardian procedures as well as OSS functions.
This makes OSS files accessible from the Guardian environment using Guardian
procedures, although file access is limited to odd-unstructured files. One reason to use
the Guardian procedures on OSS files is to perform asynchronous (nowait) I/O on OSS
files, an operation that cannot be done using OSS functions. Another reason is to
obtain more detailed information about OSS files than is available using OSS
functions.
Two Guardian procedures map OSS pathnames and Guardian filenames:
•
The PATHNAME_TO_FILENAME_ procedure maps an OSS pathname to the ZYQ
filename of the corresponding regular file. As a special case, if the pathname is in
the Guardian name space (/G), then the pathname is syntactically changed to
Guardian format.
•
The FILENAME_TO_PATHNAME_ procedure maps a Guardian filename to the
corresponding OSS pathname. The pathname returned is the first one found that
the caller has access to. If the resulting pathname represents a file in /G, the
transformation is only syntactic.
For more information on ZYQ names, refer to the Open System Services
Programmer’s Guide.
Access to OSS files using Guardian procedures is limited. In all cases, the filename
parameter (if appropriate) of the underlying object is a Guardian filename, not an OSS
pathname. The only exception to this rule is FILE_OPEN_. Most Guardian procedures
fail with an error code when the file is referenced as an OSS file.