Open System Services Porting Guide Abstract This guide describes the techniques for porting C and C++ programs to the HP NonStop™ Open System Services (OSS) environment from other UNIX environments or from the Guardian environment. It discusses differences in the environments, considerations in porting to the OSS environment, and how to take advantage of the OSS environment. Product Version N.A. Supported Release Version Updates (RVUs) This manual supports G06.25 and all subsequent G-series RVUs and H06.
Document History Part Number Product Version Published 520573-002 N.A. December 2002 520573-003 N.A. May 2003 520573-004 N.A. December 2003 520573-005 N.A. February 2005 520573-006 N.A.
Open System Services Porting Guide Glossary Index Examples What’s New in This Manual xi Manual Information xi New and Changed Information About This Manual xiii Audience xiii Disclaimer xiii Organization of This Guide Related Reading xv Notation Conventions xxi Figures Tables xi xiii 1.
3. Useful Porting Tools Contents Working on the NonStop System (continued) Editing OSS Files 2-17 Using the Debuggers With OSS Files 2-18 Using the noft and enoft Utilities on Native Program Files 2-21 3. Useful Porting Tools lint Tool 3-1 findcalls Tool 3-2 CodeCheck Tool 3-3 Open Systems Portability Checker (OSPC) Tool 3-4 4.
4. Interoperating Between User Environments (continued) Contents 4. Interoperating Between User Environments (continued) Using OSS Commands to Manage Guardian Objects 4-23 Managing Guardian Processes From the OSS Shell 4-23 Manipulating Guardian Files From the OSS Shell 4-23 5.
. OSS Porting Considerations (continued) Contents 6.
Contents 8.
Contents 8. Migrating Guardian Applications to the OSS Environment (continued) 8.
. Porting From Specific UNIX Systems Contents Starting an OSS Program From the Guardian Environment (continued) Using PROCESS_SPAWN_ in a Guardian Program 8-22 Using the Guardian LISTNER Program 8-23 C Compiler Considerations for OSS Programs 8-24 Compiler Tools 8-25 Memory Models 8-25 Header Files 8-25 Include File Search Order 8-26 New Pragmas 8-26 Feature-Test Macros 8-26 Predefined Preprocessor Symbols 8-27 Linking 8-27 Porting a Guardian Program to the OSS Environment 8-28 How Arguments Are Passed t
11.
A. Equivalent OSS and UNIX Commands for Guardian Users Contents 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 Reference Pages for Thread Functions Changed Thread Functions E-2 E-1 Glossary Index Examples Example 8-1. runossp.
Tables (continued) Contents Tables (continued) Table 8-2. Table 11-1. Table 11-2. Table 11-3. Table A-1. Table B-1. Table C-1. Table C-2. Table D-1. Table E-1. Table E-2. Table E-3. Table E-4. Table E-5. Table E-6. Table E-7. Table E-8. Table E-9. Table E-10.
What’s New in This Manual Manual Information Open System Services Porting Guide Abstract This guide describes the techniques for porting C and C++ programs to the HP NonStop™ Open System Services (OSS) environment from other UNIX environments or from the Guardian environment. It discusses differences in the environments, considerations in porting to the OSS environment, and how to take advantage of the OSS environment. Product Version N.A. Supported Release Version Updates (RVUs) This manual supports G06.
New and Changed Information What’s New in This Manual • • • DLLs are added to the discussions of SRLs. Several thread functions, no longer supported, have been removed from Appendix E, Standard POSIX Threads Functions: Differences Between the Previous and Current Standards. A new appendix, Appendix D, Equivalent Native Inspect Debugging Commands for dbx Commands, has been added.
About This Manual The Open System Services Porting Guide describes how to port applications written in the C and C++ languages to the Open System Services (OSS) environment. The emphasis is on moving applications from the UNIX environment to the OSS environment. Migrating applications from the Guardian environment to the OSS environment is also covered.
Organization of This Guide About This Manual • • • • • • • • • • • • Section 3, Useful Porting Tools, provides an overview of some useful porting tools to promote planning the porting task, which enhances the efficiency of porting code. Section 4, Interoperating Between User Environments, introduces interoperability between the Guardian and OSS environments.
Related Reading About This Manual appendix can help you decide whether you can rewrite shell scripts as TACL macros or command files. • • • • Appendix C, Equivalent Inspect Debugging Commands for dbx Commands, provides a mapping of dbx commands to Inspect commands for users familiar with the dbx tool. This appendix can help you decide whether you can rewrite shell scripts a command files for program maintenance.
Related Reading About This Manual • • • • • • • • • • • Kernighan, Brian W. and Dennis M. Ritchie. The C Programming Language, Second Edition. Englewood Cliffs, NJ: Prentice Hall, 1989. Lapin, J. E. Portable C and UNIX System Programming. Englewood Cliffs, NJ: Prentice Hall, 1987. Lewine, Donald. POSIX Programmer's Guide. Sebastopol, CA: O'Reilly & Associates, 1991. Nichols, Bradford, Dick Buttlar and Jacqueline Proulx Farrell, Pthreads Programming, O'Reilly & Associates, 1998, 270 pp. Perley, Daniel.
Related Reading About This Manual programmers who are embedding SQL statements and directives in a COBOL program. It provides the information needed for use of an SQL/MP application from the OSS environment • • • • • • • • • • • SQL/MX Programming Manual for C and COBOL. This manual documents the programming interface to HP NonStop SQL/MX for C and COBOL. It is intended for application programmers who are embedding SQL statements and directives in a C or COBOL program.
Related Reading About This Manual • • • • pTAL Guidelines for TAL Programmers. This manual gives guidelines for writing TAL code that you can migrate later to pTAL with as few changes as possible. Software Internationalization Guide. This guide describes use of the OSS internationalization features. It is written for application and system programmers. H-Series Application Migration Guide.
Related Reading About This Manual • • Guardian User’s Guide. This guide provides basic information about the programs and utilities used most often by general system and application users. It is focused on beginning users of the Guardian environment. Open System Services User’s Guide. This guide provides basic orientation, tutorial, and task information for using the OSS shell and utilities.
Related Reading About This Manual Figure i.
Notation Conventions About This Manual Notation Conventions Hypertext Links Blue underline is used to indicate a hypertext link within text. By clicking a passage of text with a blue underline, you are taken to the location described. For example: This requirement is described under Backup DAM Volumes and Physical Disk Drives on page 3-2. General Syntax Notation This list summarizes the notation conventions for syntax presentation in this manual. UPPERCASE LETTERS.
General Syntax Notation About This Manual { } Braces. A group of items enclosed in braces is a list from which you are required to choose one item. The items in the list can be arranged either vertically, with aligned braces on each side of the list, or horizontally, enclosed in a pair of braces and separated by vertical lines. For example: LISTOPENS PROCESS { $appl-mgr-name } { $process-name } ALLOWSU { ON | OFF } | Vertical Line.
Notation for Messages About This Manual a blank line. This spacing distinguishes items in a continuation line from items in a vertical list of selections. For example: ALTER [ / OUT file-spec / ] LINE [ , attribute-spec ]… !i and !o. In procedure calls, the !i notation follows an input parameter (one that passes data to the called procedure); the !o notation follows an output parameter (one that returns data to the calling program).
Change Bar Notation About This Manual lowercase italic letters. Lowercase italic letters indicate variable items whose values are displayed or returned. For example: p-register process-name [ ] Brackets. Brackets enclose items that are sometimes, but not always, displayed. For example: Event number = number [ Subject = first-subject-value ] A group of items enclosed in brackets is a list of all possible items that can be displayed, of which one or none might actually be displayed.
Change Bar Notation About This Manual The message types specified in the REPORT clause are different in the COBOL environment and the Common Run-Time Environment (CRE). The CRE has many new message types and some new message type codes for old message types. In the CRE, the message type SYSTEM includes all messages except LOGICAL-CLOSE and LOGICAL-OPEN.
Change Bar Notation About This Manual Open System Services Porting Guide —520573-006 xxvi
1 Introduction to Porting This section provides an introduction to porting applications to the HP NonStop Open System Services (OSS) environment and contains these topics: • • Overview of Porting on page 1-1 Overview of the OSS Environment on page 1-7 Overview of Porting The porting process is simple: 1. Clean up code; remove architectural dependencies and nonstandard practices. 2. Compile code. 3. Fix problems found at compile time. 4. Fix segment faults and unaligned accesses.
Porting Is Easier When Standards Are Used Introduction to Porting programming practice is to write your C or C++ programs using a template with items included in the source file in the following order: • • • • • • • • • • • Feature test switches: define the _POSIX_SOURCE macro. System headers: those that must be included to define symbols used by a function. Local headers: define common data structures and symbols Macros: defined here with comments to describe the macros.
Porting Is Easier When Standards Are Used Introduction to Porting The following provides an overview of the contents of the POSIX.
Introduction to Porting Porting Is Easier When Standards Are Used XPG4 Specifications and OSS Compliance The XPG4 specifications, sometimes referred to as the X/Open CAE Specifications, are commonly used in the industry but were not defined by an accredited standards committee. They were defined by X/Open, an international vendor consortium based in Reading, England, that defined specifications for open systems.
Porting Is Easier When Standards Are Used Introduction to Porting ISO/ANSI C Features Some ISO/ANSI C standard features are implementation-defined. The vendor can choose what values to give to those features. Table 1-1 lists new ISO/ANSI C features, not supported in Common C. New ISO/ANSI C features are important only if your program is written in Common C. Table 1-1.
Porting Is Easier When Standards Are Used Introduction to Porting Table 1-1. ISO/ANSI C Features Not Supported in Common C (page 2 of 2) Feature Type ISO/ANSI C Feature Headers , , and added
Introduction to Porting Overview of the OSS Environment Overview of the OSS Environment Open System Services is an interface through which users and programs interact with the HP NonStop operating system. The OSS environment provides an open interface to the operating system for supporting portable applications—applications that can run on a wide range of platforms from multiple manufacturers.
Comparison With UNIX Introduction to Porting Comparison With UNIX Open System Services complies with several standards developed by public organizations with widespread industrial recognition—organizations like the X/Open Company Limited, the International Organization for Standards (ISO), the Institute of Electrical and Electronics Engineers (IEEE), and the National Institute for Standards and Technology (NIST).
Relationship of the OSS Environment to the Guardian Environment Introduction to Porting Both the G-series OSS environment and the G-series Guardian environment support programs that use the TNS/R native run-time environment. The G-series OSS and Guardian environments also support programs that use the legacy TNS run-time environment. However, newly written or newly ported programs for the G-series OSS environment are expected to use the TNS/R native run-time environment.
Introduction to Porting • • • Comparing Commands Between Environments Typical source and target execution environment and exceptions to the typical pairs How to call OSS and Guardian functions and procedures and when to use them Available editors, development and initial debugging on a workstation, and transferring the code to a NonStop system The remainder of this guide discusses most of the topics listed here, but usually without the detail in the Open System Services Programmer’s Guide, because this
2 The Development Environment This section discusses different environments for developing or compiling C and C++ programs to run in the OSS environment. These environments include using development tools in the HP Enterprise Toolkit-—NonStop Edition (ETK) on a PC and using development tools directly in the OSS environment.
The Development Environment TNS/R Development Tools on TNS/E Systems HP provides a complete set of C and C++ compilation tools with each native environment. The TNS/R native compilers generate RISC code, which can run only on a TNS/R system. The TNS/E native compilers generate Itanium code, which can run only on a TNS/E system. The TNS/R and TNS/E native C compilers and the TNS C compiler implement the ISO/ANSI C, POSIX.1, and POSIX.
The Development Environment File Compatibility File Compatibility The native processing environments can execute native executable files; TNS/R native object files execute in the TNS/R native environment, and TNS/E native object files execute in the TNS/E native environment. The G-series TNS/R native processing environment can also execute TNS interpreted files and TNS accelerated files in both the Guardian and OSS environments.
The Development Environment Compilation Options for C and C++ Programs TNS/R native object files to a TNS/R system for execution. The TNS/E native compilation tools are supported only on TNS/E systems. Cross-compilation is supported for the TNS/R and TNS/E native development tools, allowing you to compile your C or C++ source code in one development environment (Guardian or OSS on a NonStop system or ETK on a PC).
Compilation Options for C and C++ Programs The Development Environment environments. For TNS/R and TNS/E systems, it is the version of the c89 utility and C run-time code that determine whether the program runs as a TNS or a native process. Table 2-1. Cross-Compilation Options for Generating OSS and Guardian Executable Files Compiler Available on PC c89 Flag to Generate OSS Executable File c89 Flag to Generate Guardian Executable File Executable File (And Where It Runs) Vendor C Yes N.A. N.A.
The Development Environment • • • Moving or Accessing Source Files D40 and later TNS/R native environment (OSS and Guardian) G-series TNS/R native environment (OSS and Guardian) H-series TNS/E environment (Guardian only) The TNS/R native C compilation tools are available in the TNS/R and TNS/E native environments. The TNS/E native C compilation tools are available only in the TNS/E native environment.
The Development Environment Moving Source Code page either online or in the Open System Services Shell and Utilities Reference Manual. Moving Code to the OSS Environment The following example shows how to move source code from a UNIX workstation to the OSS environment. (Commercial software, freeware, and shareware utilities are available for Telnet terminal emulation and file transfer protocol, or FTP, use from a PC running the Microsoft Windows operating system.
The Development Environment Using Archiving Utilities Use the ftp utility to access the OSS host system: $ ftp oss_host ... After the FTP prompt, change directory to your samples directory: ftp> cd /home/nih00/samples Still from the FTP prompt, copy the printargs.c file: ftp> put printargs.c printargs.c Quit FTP by entering the following at the FTP prompt: ftp> quit From your OSS window, compile the program as follows: $ c89 -o printargs printargs.
The Development Environment Using Archiving Utilities The tar Utility The tar utility saves and restores data from traditional tar format archives. The actions of the tar utility are controlled by one required flag and one or more optional flags. Other arguments for the tar utility are file or directory names, specifying the files to archive or restore. In all cases, appearance of a directory name refers to the files and (recursively) subdirectories of that directory.
The Development Environment • Working on the NonStop System To extract only the C source files from an archive file stored on the magnetic tape: $ pax -r -f /G/tape *.c In this example, existing files will be not be overwritten. To overwrite existing files, include the -Wclobber flag on the pax command. • The pax utility can also take its input from the standard input file and write to an archive file.
The Development Environment C and C++ Compilation Using the c89 Utility you run c89 in the OSS environment; it will produce executables for the OSS environment. Input to the c89 utility can include C or C++ source files; the object files generated by the -c flag; libraries built with the archive utility; all of the files in /usr/lib, which are the standard UNIX run-time routines; and any library files that were produced by the linker.
The Development Environment C and C++ Compilation Using the c89 Utility utility. The H-series TNS C and C++ compilation tools run in the Guardian environment only. The TNS C and C++ compilation tools are not supported on PCs or in the H-series OSS environment. The code files and reference pages for the TNS C and C++ tools are located in the OSS /nonnative directory.
The Development Environment C and C++ Compilation Using the c89 Utility Differences in Handling Input Files When compiling source code with the G-series TNS C compiler, the compiler assumes the filename starting with /G/ is a Guardian file and reads its contents to determine its type instead of checking for a suffix. The TNS/R and TNS/E native C compilers do not read any file in this manner; they require a suffix for the input file. The G-series TNS C compiler accepts filenames with and without the dot (.
The Development Environment C and C++ Compilation Using the c89 Utility Using ld or eld to Link Native Linkfiles If you intend to create dynamic-link libraries (DLLs) or create a program that uses DLLs, you must use the ld or eld linker to create a file consisting of positionindependent code (PIC). ld is the TNS/R native PIC linker; it runs on G-series and H-series systems, but its output can be executed only on G-series systems. eld is the TNS/E native PIC linker, and runs on H-series systems.
The Development Environment C and C++ Compilation Using the c89 Utility Native c89 Standard Include Directories The standard C and C++ header files for the native C compilers are in the /usr/include directory for the OSS environment; for UNIX workstations, they are in the /usr/vendor/tndm_complrs/usr/include directory. Native c89 Standard Library Directories For native environments, the linker searches a list of standard library directories.
The Development Environment C and C++ Compilation Using the c89 Utility By default on a TNS/R platform, nld performs dynamic linking by searching first for the file libc.srl and then libc.a. nld then performs static linking by searching for the file libarchive.a. nld then performs dynamic linking by searching first for the file libnative.srl and then libnative.a. On a TNS/E platform, eld performs dynamic linking by searching first for the file libc.so and then libc.a.
The Development Environment Editing OSS Files Editing OSS Files The following subsections introduce the vi editor, which is available in the OSS environment, and the emacs editor, which can be obtained for the OSS environment. Editing OSS Files Using vi For tasks such as writing memos and modifying C or C++ programs, editing text files is one of the most common uses of any computer system. The vi text editor is particularly well-suited for the day-to-day tasks of most computer users.
Using the Debuggers With OSS Files The Development Environment Using the Debuggers With OSS Files Three interactive symbolic debuggers are provided to enable you to isolate programming bugs quickly. They all provide features that help you shorten the debugging phase of a project. The debuggers are Inspect, Native Inspect, and Visual Inspect.
The Development Environment Using the Debuggers With OSS Files Refer to the Inspect Manual, Native Inspect Manual, or the Visual Inspect online help for command details. When an Inspect session begins, Inspect looks for an EDIT file named INSPLOCL in the Guardian volume and subvolume containing the Inspect program file. The Inspect program reads and executes Inspect commands contained in the INSPLOCL file.
Using the Debuggers With OSS Files The Development Environment Running the Debuggers You can start each debugger by itself and then run programs within it, or you can start both a debugger and your program at the same time.
The Development Environment • • • Using the noft and enoft Utilities on Native Program Files A single Inspect or Native Inspect command cannot accept both Guardian and OSS filenames, with the exception of the Inspect SOURCE ASSIGN. Core files, known as save or saveabend files in Inspect and as snapshot files in Native Inspect, are named ZZSAnnnn. You cannot use a Guardian filename while the Inspect systype is OSS.
The Development Environment Using the noft and enoft Utilities on Native Program Files Open System Services Porting Guide —520573-006 2- 22
3 Useful Porting Tools By using the proper tools, you can significantly reduce the time and cost of porting programs written in the C or C++ language from one computing platform to another. Some tools check for the compatibility of C language source statements with the ISO/ANSI C standard, while others are useful for determining which routines used by the program are not available on the platform to which the program is being ported.
findcalls Tool Useful Porting Tools compilers. Refer to the C/C++ Programmer’s Guide for more information on using the HP C compiler. The lint tool detects wasteful or error-prone constructions, which in some cases are actually valid coding practices. By default, lint checks your programs against a standard library file that contains descriptions of the programs normally loaded when a C program is run.
CodeCheck Tool Useful Porting Tools findcalls performs a simple but fast lexical analysis of your C source code by searching for occurrences of system calls. By using the UNIX comm utility to compare the list of system calls used by the application with the list provided in the OSS environment, you can approximate the task of porting the application to the OSS environment. (A shell script for the UNIX comm tasks is provided with findcalls.
Useful Porting Tools Open Systems Portability Checker (OSPC) Tool GNU, and Zortech compilers. It supports the Windows, OS/2 2.1, HP-UX, SunOS, Solaris, and VAX/VMS operating systems, and many other UNIX variants. Its capabilities and features are comprehensive, and it is easy to use. Open Systems Portability Checker (OSPC) Tool Open Systems Portability Checker (OSPC) is a programming tool developed by Knowledge Software.
Useful Porting Tools Open Systems Portability Checker (OSPC) Tool With the dynamic checker, you can monitor your application while it is running. All calls to system services are monitored to ensure they are portable within the bounds specified by standards. Pointer use is also checked by the dynamic checker.
Useful Porting Tools Open Systems Portability Checker (OSPC) Tool Open System Services Porting Guide —520573-006 3 -6
4 Interoperating Between User Environments The Open System Services (OSS) shell and utilities provide you with the ability to manipulate Guardian objects such as files and processes. Several commands and utilities have been implemented to enhance the interoperability between the OSS and Guardian environments.
Interoperating Between User Environments • • • Purpose of Interoperability The ability of an application to use the application program interface (API) of either the OSS or Guardian environment The ability of one API to access or manipulate objects of both environments The ability of utilities to access or manipulate objects of both environments The primary objective of interoperability is to support and encourage the development of new applications for the OSS environment and the porting of existing UN
Interoperating Between User Environments C Programming and Interoperability Figure 4-1. OSS and Guardian Interoperability Guardian Process OSS Process Guardian API OSS API Guardian Objects OSS Objects VST 006 .VSD C Programming and Interoperability Writing C programs for the Open System Services (OSS) environment is nearly identical to writing C programs for a UNIX environment. Programs must comply with the ISO/ANSI C standard and can call most of the function calls specified by the POSIX.
Interoperating Between User Environments Scopes of Interoperability Scopes of Interoperability There are a number of views of interoperability between the OSS and Guardian environments. They can be divided into three job responsibilities or audiences: • • • Those who develop application program interfaces (APIs), applications, and other programs.
Interoperating Between User Environments Factors Affecting Shell Operation Factors Affecting Shell Operation The factors described in the following subsections affect shell operation for the interactive OSS user: • • • • • • Shell Start-Up Files on page 4-5 Option Values on page 4-5 Variable Values on page 4-6 Aliases and Functions on page 4-6 stty Settings on page 4-7 Line and History Editing on page 4-7 Shell Start-Up Files The start-up procedure for the OSS shell is the same as the procedure for a U
Interoperating Between User Environments Factors Affecting Shell Operation to ON, the file is overwritten. The following table lists the more frequently used -o option settings: -o Option Setting Description set -o Displays values of all option settings. set -o noclobber Turns on noclobber mode; output redirection to an existing file causes command to abort. set +o emacs Turns off emacs editing mode.
Factors Affecting Shell Operation Interoperating Between User Environments Functions are similar to scripts, but without the overhead of searching the file system for the script file. A function provides the ability to use the command-line parameters from its invocation and to use any built-in or program. The currently defined functions can be listed using the typeset -f command.
Interoperating Between User Environments Guardian Environment Variables and the OSS Shell The following commands set options and variables for using the vi editing mode: Editing Command Setting Description set +o emacs Ensures emacs mode is off. set +o gmacs Ensures gmacs mode is off. set -o vi Turns on vi editing mode. export EDITOR=$(whence vi) Sets editing mode to vi. The whence command returns the full pathname for the program vi. The value is exported to subshells.
Interoperating Between User Environments Guardian Environment Variables and the OSS Shell specified filenames used by the process and other user-specified information in the form of the ASSIGN and PARAM environment variables. This start-up sequence usually occurs whenever one process creates another; the creating process sends the information to the new process, but it is up to the new process to somehow use the information.
OSS Commands for the Guardian User Interoperating Between User Environments Guardian DEFINE OSS Shell Command RESET DEFINE reset_define Restores DEFINE attributes to their initial settings. SET DEFINE set_define Sets DEFINE attribute values. SHOW DEFINE show_define Displays DEFINE attributes and values. DEFINE Command Purpose Note. The names of Guardian DEFINEs begin with an equal sign (=) and must be followed by a letter.
Interoperating Between User Environments Managing Processes From OSS OSS shell commands is contained in the Open System Services User’s Guide and the online reference pages. Managing Processes From OSS To obtain the status of OSS processes, use the OSS ps utility. This utility is equivalent to the Guardian STATUS command. Examples To list all your OSS processes, use: ps To list all OSS processes except kernel processes, use: ps -e The -u parameter limits the output of ps to specific users.
Editing Files From OSS Interoperating Between User Environments following table shows some common file operations, the OSS shell utility for those operations, and examples of the same operations using a FUP command: Operation OSS Shell Utility FUP Command Copies a file. cp report reprtsav FUP DUP REPORT, REPRTSAV Displays filenames. ls FUP FILES Displays file attributes. ls -l oldfile FUP INFO OLDFILE Deletes file. rm oldfile FUP PURGE OLDFILE Renames file.
Interoperating Between User Environments Compiling and Linking Programs From OSS In the following example, the -o parameter limits the output to those spool jobs queued to a specific printer location (in this case, $S.#LASER): lpstat -o laser These examples specify the spool destination using an alias; this is true for both lp and lpstat utilities. The definitions of the spool location abbreviations are specified in the /etc/printcap file.
Interoperating Between User Environments Guardian Commands for the UNIX User In the following example, the first and second command lines compile the C source code files test1.c and test2.c. The -c flag specifies the creation of only object files: test1.o and test2.o. The third command line binds the two object files together to create an executable file. The -o flag specifies the name of the executable file (tester) to produce: c89 -c test1.c c89 -c test2.c c89 -o tester test1.o test2.
Managing Processes From TACL Interoperating Between User Environments Managing Processes From TACL Within a Guardian environment, you can use the Guardian STATUS command to obtain the status of Guardian processes. This is equivalent to the OSS ps utility.
Managing Files From TACL Interoperating Between User Environments OSS utilities enhanced to access a Guardian process would specify /G/srvr or /G/5,48 for the previous commands. The OSS command line would look like one of the following: kill -s GUARDIAN /G/SRVR kill -s GUARDIAN /G/5,48 Managing Files From TACL Within TACL, you use the FUP command to manipulate files.
Interoperating Between User Environments Editing Files From TACL Moving Files From the Guardian Environment to the OSS Environment You may access EDIT-format files directly from the /G file system with an OSS utility. Three options for moving files to the OSS environment are provided: • The following command copies and converts the EDIT file (type 101) called $DATA01.REPORTS.
Interoperating Between User Environments Printing Files From TACL After moving an OSS format file to the Guardian environment, converting a file to EDIT format is done with the Guardian utility CTOEDIT, as follows: CTOEDIT fromfile, tofile Printing Files From TACL ASCII text files or EDIT-format files are printed by copying the file to a spool location. A spool location normally is named $S, followed by a printer name: for example, $S.#LASER. The command to print the file $DATA01.REPORTS.
Interoperating Between User Environments Running the OSS Shell and Commands From TACL from a name in a Guardian filename to an OSS pathname using the pname utility, as shown earlier. A Guardian filename associated with Guardian processes can be translated to an OSS pathname with the gname utility. Note. The ZYQ subvolumes have special restrictions. They are not accessible from the OSS environment. From the Guardian environment, access is restricted to privileged users and the super ID.
Interoperating Between User Environments Starting an OSS Shell Script Starting an OSS Shell Script You can start an OSS shell script in either of the ways shown in the previous two examples. The results produced by the script can differ depending on the login initialization. A script that depends on any login initialization such as aliases or functions can only execute correctly with the -c option specified.
Interoperating Between User Environments Interactively Using TACL and the OSS Shell The following example illustrates the execution of an interactive shell using OSSTTY instead of Telserv. An OSS application (testprog) receives input interactively from a Guardian process ($vhs, the Guardian virtual hometerm subsystem). TACL> run osstty /name $tty, in $vhs, nowait/ TACL> osh -p /home/stu01/testprog < /G/tty/#stdin OSSTTY is started with $vhs as its standard input.
Interoperating Between User Environments • Running OSS Processes With Guardian Attributes The following command line executes the Guardian STATUS command and directs the output to the grep utility by using a pipe character (|).
Interoperating Between User Environments Using OSS Commands to Manage Guardian Objects Services User’s Guide provides examples of using the run utility and descriptions of the run options. Using OSS Commands to Manage Guardian Objects You can use some OSS utilities to manage Guardian processes and files as well as to manage OSS objects. To manage Guardian objects, frequently requires that you use the -W parameter, described following.
Interoperating Between User Environments Manipulating Guardian Files From the OSS Shell The OSS file system is responsible for enabling the transparent read access of EDIT files for all programs executing in the OSS environment. Thus, all the standard OSS utilities—such as cat, more, and grep, and programs that you write—are able to access EDIT files (type 101) and odd-unstructured files (types 0, 100, and 180).
Interoperating Between User Environments Manipulating Guardian Files From the OSS Shell Normally, when files are copied to /G, the file has the date and timestamp of when the copy occurred. If the -Wclobber parameter is specified, cp sets the date and timestamp to that of the from file. The file Utility You can use the OSS file utility to detect Guardian file types. File types in /G are based on the Guardian file codes (types).
Interoperating Between User Environments Manipulating Guardian Files From the OSS Shell specified, pax displays a prompt for the tape to be mounted. If -W nowait is specified, pax exits immediately when the tape drive is offline or no tape is mounted. The rm Utility The rm utility removes specified files from a directory. It also removes directories, if they are empty of both files and other directories.
5 Interoperating Between Programming Environments This section is intended for users of the OSS and Guardian environments who need to understand interoperating between the two.
Interoperating Between Programming Environments Major Differences Between Programming Environments Major Differences Between Programming Environments When using Guardian procedures in the OSS environment, you need to realize that the characteristics of the Guardian environment are different from those of the OSS environment: • • • • • Guardian processes are identified by their process handles; OSS processes are identified by their process IDs and process handles.
Header Files Interoperating Between Programming Environments Table 5-1.
Interoperating Between Programming Environments Function Entry Points Defined in Header Files Function Entry Points Defined in Header Files 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. For TNS processing environments, these files support three different memory models in the Guardian environment and the WIDE data model in the OSS environment.
Interoperating Between Programming Environments API Interoperability Tables An application program interface (API) is a set of functions or procedure declarations that permits user programs to communicate with the operating system or subsystem. The OSS API coexists on NonStop systems with the Guardian API.
Process Interoperability Interoperating Between Programming Environments remove(), rename(), tmpfile(), and tmpnam(). Guardian-specific and OSSspecific versions of these functions are provided for use from the opposite environment. Process Interoperability You create, control, and terminate OSS processes in the OSS environment as you would in a standard UNIX environment.
Interoperating Between Programming Environments Process-Management Interoperability using HP extension functions such as tdm_fork() and tdm_spawn(), discussed in the next subsection. tdm_fork(), tdm_execve set, and tdm_spawn() Functions A number of process-creation functions specific to HP are available in the OSS environment to pass Guardian attributes from the parent process to the child process: tdm_fork(), tdm_execve(), tdm_execvep(), and tdm_spawn().
Interoperating Between Programming Environments Process-Management Interoperability Guardian processes. For example, if you want to use a product or subsystem that runs only in the Guardian environment, you might need to manage a process from the opposite environment. The process handle of an OSS process allows most Guardian process-management procedures to access it. On the other hand, a Guardian process does not have an OSS process ID, which is required by most OSS process-management functions.
Interoperating Between Programming Environments Process-Termination Interoperability Process-Termination Interoperability When a process calls PROCESS_SPAWN_ to create a process, the parent process is treated as a Guardian process, regardless of whether the caller is an OSS or Guardian process. In this case, the parent process receives process-termination notification through Guardian system messages (instead of the SIGCHLD signal, which is normal notification for OSS processes).
Interoperating Between Programming Environments Accessing Files From the Guardian API Odd-unstructured files and EDIT files are opened as OSS regular files. If you want your application to modify odd-unstructured Guardian files, or if your application uses data stored in odd-unstructured Guardian files or EDIT files, you can use the interoperability capabilities of the OSS environment and access these files with OSS functions.
Interoperating Between Programming Environments Guardian Procedures Extended for OSS Files Guardian Procedures Extended for OSS Files Some Guardian file system procedure calls are extended to manipulate OSS files: • • • • • • • FILE_GETINFO_ FILE_GETINFOBYNAME_ FILE_GETINFOLIST_ FILE_GETINFOLISTBYNAME_ FILE_OPEN_ FILE_OPEN_CHKPT_ SETMODE The FILE_GET* procedures determine whether a file is an OSS file or a Guardian file. Additionally, each provides slightly more specialized information.
Interoperating Between Programming Environments I/O Interoperability over itself. Guardian native process cannot send a signal to or receive a signal from another Guardian or OSS process using the kill() function. • • • • Signals in native and TNS processes: any OSS process (native or G-series TNS) can use OSS signal functions. Only a native Guardian process can use OSS signal functions.
Interoperating Between Programming Environments Terminal I/O Terminal I/O The only terminals supported in the OSS environment are a Telserv window and the three OSSTTY windows: #stdin, #stdout, and #stderr. Terminal I/O through a Telserv window is the same as that for a UNIX network terminal. OSS also supports local terminals through OSSTTY, although OSSTTY has the look and feel of a remote terminal. OSS terminal I/O functions operate only on the terminal device /dev/tty.
Mixed-Module Programming Interoperating Between Programming Environments modules). A mixed-module program is composed of at least one OSS module and at least one Guardian module and runs as either an OSS process or a Guardian process; it cannot run as a process in both environments. The environment of the module containing the main() function determines the environment in which a process runs.
Interoperating Between Programming Environments Design Considerations and Steps the SYSTYPE pragma to direct the compiler to generate code appropriate for each environment. Specify SYSTYPE OSS for OSS modules and SYSTYPE GUARDIAN for Guardian modules. Using mixed-module programming should be minimized because of the knowledge required to keep code easier to maintain. Note. You must compile Guardian and OSS modules separately (on the command line, not in source code).
Interoperating Between Programming Environments Mixed-Language Programming User routines running in the CRE continue to use their language-specific run-time libraries, but many of the functions in the language-specific run-time libraries simply recognize calls from user routines and invoke CRE library functions to process the requests.
6 OSS Porting Considerations Most of the major features supported in UNIX systems are supported in Open System Services, but some are provided in different ways. This section discusses what to do about certain features that are not present in Open System Services and how to use features equivalent to those provided in other UNIX systems.
Memory Mapped Files OSS Porting Considerations If you must recode your program to achieve feature equivalence in the OSS environment, always try to conform to the POSIX standards and XPG4 specifications; see Porting Is Easier When Standards Are Used on page 1-2. When porting code that uses extensions, use functional equivalents from the POSIX standards to avoid propagating extensions to the OSS environment.
The poll() Function OSS Porting Considerations The poll() Function On a UNIX system, the poll() function provides applications with a mechanism for multiplexing input and output (blocking I/O) over a set of file descriptors. It identifies those file descriptors on which an application can read or write data, or on which certain events have occurred. poll() supports regular files, terminal devices, sockets, STREAMS-based files, FIFOs, and pipes.
Using Interprocess Communication (IPC) Mechanisms OSS Porting Considerations Table 6-2.
Using Sockets OSS Porting Considerations Table 6-3. Interprocess Communication using OSS and Guardian APIs (page 2 of 2) Within a processor Between processors Between Expand nodes With other systems OSS shared memory (with OSS processes only) Yes No No No OSS semaphores (with OSS processes only) Yes No No No $RECEIVE Yes Yes Yes No IPC method For a discussion of interprocess communication between Guardian and OSS processes, refer to the Open System Services Programmer’s Guide.
Using Message Queues OSS Porting Considerations overhead is much higher than for other IPC mechanisms. The following tradeoffs exist for the use of sockets: • • • • If you must have source compatibility with portability and POSIX standard socket semantics, use OSS sockets. If you require improved performance with socket-like semantics but portability is not a primary consideration, consider making minor code changes to your program to use Guardian sockets.
Using Pipes and FIFO Files OSS Porting Considerations Refer to the corresponding reference pages, either online or in the Open System Services System Calls Reference Manual, for details on using OSS message-queue functions. Message Queues and Process Creation Functions The message-queue identifiers returned by the msgget() function are not associated with any process, and information about the identifiers is not maintained in the context of any user process.
Using Pipes and FIFO Files OSS Porting Considerations Using a Pipe Across Processors In the OSS environment, there is one OSS pipe server for each processor. The OSS pipe server process is started at reload time and handles all pipe-creation tasks per processor; it is the destination for all cross-processor pipe and FIFO I/O traffic. When you create a pipe across processors, you have to communicate with the OSS pipe server in the processor that owns that pipe.
Using Signals OSS Porting Considerations FIFO files cannot be created in the /G file system. However, Guardian processes can access FIFOs using OSS API functions. Refer to the Open System Services Programmer’s Guide for information on interoperability between Guardian and OSS processes using OSS API functions.
Using Semaphores OSS Porting Considerations In the OSS environment, you usually do not have to be aware of the type of memory a program is using, unless your programs use Guardian procedures to share memory with other processes. OSS processes can use OSS functions and Guardian procedures to share memory with other OSS processes. To share memory with Guardian processes, OSS processes must use Guardian procedures. OSS functions allow OSS processes to share flat extended data segments.
Memory Allocation and Deallocation OSS Porting Considerations Also, see Section 8, Migrating Guardian Applications to the OSS Environment, for memory-model incompatibilities that require conversion when porting Guardian applications that use a memory-model not supported by OSS programs. The large-memory model stores the heap and the global and static aggregates in a single extended memory segment. (Static aggregate refers to an aggregate that is declared with the static storage class specifier.
Virtual Memory Management OSS Porting Considerations • An attempt is made to use memory that has already been freed. Virtual Memory Management The Kernel-Managed Swap Facility (KMSF) manages virtual memory for TNS/R and TNS/E native processes. Native processes use kernel-managed swap space rather than a user-specified swap file. The global data, heap, main stack, and SRL or DLL instance data are swapped to system-managed swap files for native processes.
Using Process-Creation Calls OSS Porting Considerations versions of the UNIX operating system in addition to the OSS environment. See Predefined Preprocessor Symbols on page 7-15, which discusses conditional compilation of system-dependent code. Using Process-Creation Calls This subsection discusses the OSS process-creation functions: fork(), tdm_fork(), and the exec, tdm_execve, and tdm_spawn sets of functions.
OSS Porting Considerations Using fork() and the exec Set of Functions in OSS When you create OSS processes with fork() and the exec set of functions, the attributes of the parent process are propagated to the child process, but the child process has an OSS process ID that uniquely identifies it. An OSS process can send signals to and receive signals from other OSS processes.
Using the tdm_spawn Set of Functions for Load Leveling OSS Porting Considerations the tdm_spawn Set of Functions for Load Leveling on page 15 for more information on creating a process in another processor. Using the tdm_spawn Set of Functions for Load Leveling Like fork() and the exec set of functions, the tdm_spawn set of functions creates a child process. It performs generally the same operations as fork() and the exec set of functions, but in one step.
Which Call to Use for Process Creation OSS Porting Considerations Which Call to Use for Process Creation Of the various process-create functions in the OSS and Guardian environments, you will need to consider the features of each and match the feature to whether you need more performance or more portability.
The SIGCHLD Signal and the Creation of Zombie Processes OSS Porting Considerations • • ° ° ° High interoperability with Guardian processes and subsystems ° OSS processes can be persistent when PROCESS_SPAWN_ is used in a Guardian process pair monitor ° File opens are not propagated to the child process Can be called from either a Guardian or OSS process Creates a process on another processor efficiently, thereby providing load balancing PROCESS_LAUNCH_ procedure call (supersedes PROCESS_CREATE_)
Performing File Operations OSS Porting Considerations into a zombie process. This may not be the case in other implementations of UNIX. For example, in SVR4 UNIX, zombies are not created if SIGCHLD is ignored. To avoid wasting system resources when terminating child processes and ignoring SIGCHLD, you should take specific action to avoid the creation of zombie processes. The POSIX.
Opening an OSS File OSS Porting Considerations Opening an OSS File A file open operation for an OSS file involves a number of steps. If the file specified in the open request does not exist, it is created (if the O_CREATE flag is set). The following steps are involved in opening an OSS file: 1. An application uses the open() function call to open an OSS file named /a/b. The OSS file system sends an open request to the OSS name server. 2.
Directory Operations OSS Porting Considerations Performance Considerations for Files Because these OSS file operations consume more resources than the same operations on other UNIX systems, note these recommendations: • • • • Avoid performing numerous opens and closes of files and performing numerous short reads and writes. Consolidate operations when possible. Avoid working with a great number of small files. (You will use the same amount of resources to open a small file as a large file.
File Caching for Regular Disk Files OSS Porting Considerations OSS Name Server Caching The OSS name server caches both inodes and name entries and maintains a catalog for each OSS fileset. With the OSS name server cache, previously found entries remain in cache; thus no disk access is required for these items. Further, repeated requests for nonexistent files do not require repeated access to the catalog; the cache stores in memory that these entries do not exist.
Using Symbolic Links OSS Porting Considerations • For multiple readers and one writer in multiple processors, there can still be significant performance improvement over using one processor, depending on the mix of read versus write traffic. When an application program calls one of the tdm_spawn or tdm_execve set of function and specifies a processor different from the caller’s processor, this activity is called open migration.
Porting Servers and Demons OSS Porting Considerations The Guardian procedures that map OSS pathnames and Guardian filenames, FILENAME_TO_PATHNAME_ and PATHNAME_TO_FILENAME_, support symbolic links. Detailed information on using these Guardian procedures is located in the Guardian Procedure Calls Reference Manual.
Careful Programming With Static Servers OSS Porting Considerations For example, the World Wide Web (WWW) server program httpd is implemented in UNIX systems as a dynamic server. Each time a new request is received by the WWW server, a new process is created by the fork() function to handle the incoming request. When the handling of the request is complete, the process terminates. The WWW server handles multiple requests in parallel by creating a new process to handle each request to completion.
OSS Porting Considerations Guardian LISTNER Versus UNIX and OSS inetd without interfering with each other. A super server handles all requests and passes requests to the other servers. When necessary, the NonStop operating system can activate a static server process in an additional processor, thus spreading the load throughout the system. Guardian LISTNER Versus UNIX and OSS inetd A listener server acts as a handler process when network activity is detected on ports under its domain of management.
Starting a Guardian Server Process OSS Porting Considerations procedure PROCESS_SPAWN_ to start OSS processes; see Starting an OSS Server Process on page 6-26. Starting a Guardian Server Process Typically, a client program is started by an application user at a terminal. A Guardian server can be started by an operator or system manager, or by the Guardian LISTNER process, depending on the way you design the server.
OSS Porting Considerations Starting an OSS Server Process Refer to the Open System Services Programmer’s Guide for a programming example of creating an OSS process using PROCESS_SPAWN_; additionally, that guide has a programming example of using $RECEIVE in an OSS server process. If you plan to port programs activated by the inetd program from a UNIX environment to the OSS environment, you will need to supply an interface program to communicate with the Guardian LISTNER program.
OSS Porting Considerations Starting an OSS Server Process Open System Services Porting Guide —520573-006 6- 28
7 Porting UNIX Applications to the OSS Environment Many application programs have been written for the UNIX environment. As UNIX standards have developed, popular UNIX environments have been brought into conformance with these standards. UNIX programs that use these standard interfaces should be easy to port to the OSS environment. However, many UNIX environments still support old system interfaces for backward compatibility, and have added proprietary extensions of their own.
Porting UNIX Applications to the OSS Environment • • • • • • • • Scope of Portability Porting Analysis on page 7-3 Design Trade-Offs on page 7-3 Equivalent Features on page 7-4 Standard Functions on page 7-4 Equivalent Functions on page 7-4 Single-Processor Versus Multiprocessor Systems on page 7-4 HP Extensions on page 7-5 Programming for Portability on page 7-5 Scope of Portability Scope of portability refers to the number of target platforms on which the program currently runs or will run.
Porting UNIX Applications to the OSS Environment Porting Analysis Compatibility can be achieved between systems using similar processors and standard transport media formats, but is rarely achieved between two dissimilar hardware architectures (except with much care). Portability Through Operating Environment Compatibility Operating environment compatibility exists when two operating systems support or can emulate a sufficiently complete mutual subset of operating system and support function calls.
Porting UNIX Applications to the OSS Environment Equivalent Features trade-offs associated with process-creation and other major functions are discussed in Section 6, OSS Porting Considerations. Equivalent Features Some features found in UNIX environments are not provided in the OSS programming environment, are implemented differently, or are provided with slightly different functions.
Porting UNIX Applications to the OSS Environment HP Extensions program for a loosely coupled, multiprocessor environment. As discussed in Section 6, OSS Porting Considerations, significant performance improvements can be achieved in redesigning a server to run as a super server. Each slave server runs as a persistent process in a separate processor, thus avoiding process-creation and termination overhead for each request handled by the server (super server).
Porting UNIX Applications to the OSS Environment Using Functional Equivalents These practices are primarily applicable to new programs, but you may get an opportunity to apply them when porting existing UNIX programs. Using Functional Equivalents The fewer nonstandard functions used by a program, the more portable it is.
Porting UNIX Applications to the OSS Environment Differences Between OSS and UNIX Environments Table 7-1. Functions Currently Not in the OSS Environment (page 2 of 2) Function Replacement Recommendation setitimer() Use alarm(). setlinebuf() Use setvbuf(). sigblock() Use sigprocmask(). sigpause() Use sigsuspend(). sigsetmask() Use sigprocmask(). sigvec() Use sigpending(). timezone() Use localtime(). utimes() Use utime(). vfork() Use fork(). vhangup() Use tcsetattr().
Porting UNIX Applications to the OSS Environment Process Characteristics information on using the mknod() function, refer to the mknod(2) reference page either online or in the Open System Services System Calls Reference Manual. Local Guardian files can also be accessed by OSS functions through the /G directory in the OSS file system. Pathnames in the /G directory have the form: /G/volume/subvolume/file_identifier where the $ and periods of the Guardian filename are replaced by slashes (/).
Porting UNIX Applications to the OSS Environment Security Model Security Model A common security model is implemented across the OSS and Guardian environments. An object-oriented, access control mechanism is used in which the attributes of the object, rather than the function used to access the object, determine who can access the object; the security model of the target object applies.
Porting UNIX Applications to the OSS Environment OSS C Programming Considerations You cannot use ACLs to protect individual OSS files. However, you can “protect” the disk volume in which OSS files reside with respect to users’ ability to create files in that volume. To determine whether there is an ACL on a Guardian file, use the Guardian FILE_GETINFOLISTBYNAME_ procedure. OSS regular file access policies differ from Guardian disk file access policies.
Porting UNIX Applications to the OSS Environment General Programming Practices Most UNIX systems provide C compilers that support both ISO/ANSI C and Common C by using a compiler flag. If your program is written in Common C, it can be converted to use ISO/ANSI C and tested on the UNIX platform on which it was written before porting to the OSS environment. A number of commercially available books contain guidelines for converting programs from Common C to ISO/ANSI C.
Porting UNIX Applications to the OSS Environment • • Function Prototypes Do not assume that different pointer types are the same. Use unsigned types for bit fields. Function Prototypes The ISO/ANSI C innovation of function prototypes is one of the more important features added to the C language.
Porting UNIX Applications to the OSS Environment Defined Symbols and Header Files environment. In addition, the following header files are provided to define the interfaces to HP extensions: cextdecs.h Function prototype declarations for the Guardian procedures sql.h Embedded SQL/MP definitions and some SQL/MX data-type declarations sqlcli.
Porting UNIX Applications to the OSS Environment Defined Symbols and Header Files _XOPEN_SOURCE When defined, all symbols defined by POSIX.1, POSIX.2, and XPG4 are visible. The pragma SYSTYPE OSS defines the _XOPEN_SOURCE macro. _XOPEN_SOURCE_EXTENDED When defined, all symbols defined by POSIX.1, POSIX.2, XPG4, and XPG4 Version 2 are visible.
Porting UNIX Applications to the OSS Environment C Compiler Pragmas _OSS_HOST When defined, the identifiers used by the C compiler for the OSS environment are identified. The user does not define or undefine this macro, it is used only by the compiler. _OSS_TARGET When defined, the identifiers required for executing in an OSS environment are identified. The user does not explicitly define this macro, it is defined when using the c89 -Wsystype=oss flag.
Porting UNIX Applications to the OSS Environment C Compiler Translation Limits The following OSS C compiler pragmas are included: ANSICOMPLY Strict ISO/ANSI C syntax checking (only for G-series TNS C compiler) EXTENSIONS HP language extensions are allowed (only for native C compilers) ANSISTREAMS Odd-unstructured standard I/O files FUNCTION Attributes of external routines SYSTYPE Target environment, OSS C compilers default to SYSTYPE OSS WIDE Data model (default value for SYSTYPE OSS) NOEXTENS
Porting UNIX Applications to the OSS Environment OSS C Run-Time Library Functions on page 5-5 or the Open System Services Programmer’s Guide for more information on these functions. When porting UNIX programs to the OSS environment, use only the OSS C run-time library functions. If you wish to access a routine in the Guardian C run-time library, you must use mixed-module programming techniques, discussed in Section 5, Interoperating Between Programming Environments.
Porting UNIX Applications to the OSS Environment 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: 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 n
Porting UNIX Applications to the OSS Environment Using OSS Function Calls Using OSS Function Calls The OSS function calls specified by the POSIX.1 and POSIX.2 standards are compliant with those standards. However, the POSIX standards do allow for implementation-defined behavior, which is described in this subsection. UNIX application programs ported to the OSS environment might be affected by this behavior.
Porting UNIX Applications to the OSS Environment Using OSS Function Calls The value of the S_NONSTOP flag on a regular OSS file can be changed with chmod(), but the change takes effect at the next open() call. Using the chown() Function For OSS files, a process can use the chown() function call to change the owner ID of a file only if the effective user ID of the process is the super ID. The _POSIX_CHOWN_RESTRICTED feature of this call is enforced for OSS files.
Porting UNIX Applications to the OSS Environment Using OSS Function Calls Using the lstat(), readlink(), and symlink() Functions You cannot use the lstat(), readlink(), or symlink() functions to set symbolic links in the Guardian file system. However, Guardian files can be pointed to by symbolic links created in the OSS file system.
Porting UNIX Applications to the OSS Environment Using OSS Function Calls standard Guardian security mechanisms and by Safeguard for Guardian disk file and process access. Using the opendir() and readdir() Functions The opendir() function call can be used for OSS and Guardian directories. Using readdir() on the /G, /G/vol, and /G/vol/subvol directories returns all entries, even files inaccessible through OSS interfaces, such as Enscribe structured files and SQL tables and views.
Porting UNIX Applications to the OSS Environment Using OSS Function Calls Using the stat() and fstat() Functions For files other than regular OSS files, the stat() and fstat() functions return zero as the value for the st_size field of the stat structure and 4096 as the value for directories. For regular OSS files, the size of the file is returned. For Guardian EDIT files, the st_size field specifies the actual (physical) end of a file, not the number of bytes in the file.
Using OSS Function Calls Porting UNIX Applications to the OSS Environment Table 7-2.
Porting UNIX Applications to the OSS Environment Using HP Extensions Additional signals defined by HP include: SIGABEND Abnormal termination SIGLIMIT NonStop operating system limits trap SIGMEMERR Uncorrectable memory error SIGMEMMGR Memory manager read error SIGNOMEM No memory available SIGSTK Stack overflow SIGTIMEOUT Process loop timeout When a receiving process is terminated with saveabend, a file named ZZSAnnnn (the saveabend file, also known as a snapshot file) is created in the curren
Porting UNIX Applications to the OSS Environment Guardian Procedure Calls for Interoperability HP extension functions give application programs access to a richer set of features than those available through the standard open functions. These features include Guardian procedure calls, interoperable I/O routines, and process-control functions.
Porting UNIX Applications to the OSS Environment Calling Guardian Procedures Calls on page 6-13 provides information about when to use these process-creation functions.
Porting UNIX Applications to the OSS Environment Calling Guardian Procedures C compiler generates the appropriate interface code to call the Guardian system procedures. The cextdecs.h header file contains function prototype declarations for the Guardian procedures that can be called directly from a C program by specifying the C names for the procedures in uppercase characters and providing a section for each procedure using the SECTION pragma.
Porting UNIX Applications to the OSS Environment Using the OSS Internationalization Subsystem Using the OSS Internationalization Subsystem Internationalization is the process of developing software applications without making assumptions about the language, encoding methods, and cultural data that the applications are expected to handle. Internationalized applications support new languages, cultures, and code sets without requiring changes to source code. Quite simply, internationalized code is portable.
Porting UNIX Applications to the OSS Environment Locales in OSS Client/Server Applications locale(1) reference pages either online or in the Open System Services Shell and Utilities Reference Manual and to the setlocale(3) and localeconv(3) reference pages either online or in the Open System Services Library Calls Reference Manual.
8 Migrating Guardian Applications to the OSS Environment Guardian programs for NonStop systems have been written in a number of programming languages, including TAL, C, C++, and COBOL85. You can make programs more open by using OSS features in the Guardian environment, or even migrate the programs to run in the OSS environment. There are basically two ways to migrate an existing Guardian TNS program: • • Migrate the Guardian TNS program to the Guardian native environment.
Migrating Guardian Applications to the OSS Environment TNS to TNS/R or TNS/E Native Migration completely migrate the application from the Guardian environment to the OSS environment. If the program makes use of features which are not available from the OSS environment, this may not be possible, and you may decide that a more realistic approach is to add open features to the existing Guardian application.
Migrating Guardian Applications to the OSS Environment Migration Options Migration Options The first thing you need to do when you decide you want to add more openness to your Guardian application is to decide how far you can or want to migrate your application.
Migrating Guardian Applications to the OSS Environment Using OSS Functions in a Guardian Program Using OSS Functions in a Guardian Program More open features are available to a Guardian program with the use of OSS functions, most of which can be called from a Guardian program. Refer to the API interoperability tables in the Open System Services Programmer’s Guide for a complete list of OSS functions that you can use to provide open features to Guardian programs.
Migrating Guardian Applications to the OSS Environment Compiler Tools Development Environment. This subsection is addressed to C or C++ programmers who wish to use the native tools to add open features to Guardian C programs. The OSS environment provides powerful program development tools to build and maintain programs.
Migrating Guardian Applications to the OSS Environment • • 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.
Migrating Guardian Applications to the OSS Environment Include File Search Order The use of header files is optional (but strongly recommended) for programs that contain Guardian modules exclusively. However, using header files is required for mixed-module programs: for example, when an OSS module is bound into a Guardian program. If compilation is done without using header files, the linker cannot correctly resolve external references to Guardian and OSS functions. Note.
Migrating Guardian Applications to the OSS Environment Binding TNS Programs These preprocessor symbols are set by default when the OSS C compiler is invoked with the -Wsystype=guardian option. Other symbols can be set by using the appropriate options in the c89 command line, or the appropriate pragmas in the C or C++ source code. Binding TNS Programs In the Guardian environment, Binder is used to bind the specified object files with any libraries referenced into an executable program.
Migrating Guardian Applications to the OSS Environment Equivalent OSS Commands for Compiling Guardian Programs Table 8-2.
Migrating Guardian Applications to the OSS Environment Using New and Extended Guardian Procedures Table 8-2.
Migrating Guardian Applications to the OSS Environment 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.
Migrating Guardian Applications to the OSS Environment Guardian Process-Management Procedures The following Guardian procedures support some actions on OSS files: Procedure Description FILE_GETINFO_ Returns a limited set of information on a file, identified by a file number FILE_GETINFOBYNAME_ Returns a limited set of information on a file, identified by a filename FILE_GETINFOLIST_ Returns detailed information about a file, identified by a file number FILE_GETINFOLISTBYNAME_ Returns detailed inf
Migrating Guardian Applications to the OSS Environment Guardian Process-Management Procedures OSS processes. If you wish to use a subsystem or product that runs only in the OSS environment, you may need to manage the processes from the Guardian environment. When using Guardian procedures, OSS processes are identified by process handles rather than by process IDs. You can get your own process handle using a Guardian procedure call, such as PROCESSHANDLE_GETMINE_.
Migrating Guardian Applications to the OSS Environment Using OSS Functions in a Guardian Program management procedures with OSS processes are shown in the Open System Services Programmer’s Guide.
Migrating Guardian Applications to the OSS Environment Process Target Type Process Target Type The target of a module, chosen at compile time, determines the environment of the routines being selected. The chosen target interacts with special toggles (feature-test macros) in the header files to select particular implementations appropriate for the target. Usually, all modules of a program have the same environment and are bound together into a program that runs as a process of that environment.
Migrating Guardian Applications to the OSS Environment Object Type Being Manipulated remove(), tmpfile(), and tmpnam(). These functions have an explicit perenvironment name: for example, fopen_oss() and fopen_guardian(). By calling the OSS variant of the function (for example, fopen_oss()) explicitly from a Guardian program, the correct version of the function is called for the action to be taken. You can write a module that can fit into either a Guardian or OSS program.
Migrating Guardian Applications to the OSS Environment API Interoperability Programmer’s Guide for more details on mixed-language programming. Refer to the TAL Programmer’s Guide for details on writing CRE-compliant TAL code. API Interoperability API interoperability tables, listing all of the functions and macros in the Guardian C runtime library and in the OSS C run-time library, give the programmer an overview of which functions can be called from which module and from which process.
Migrating Guardian Applications to the OSS Environment • • • • $RECEIVE Using Shared Memory on page 8-19 Using Semaphores on page 8-19 Using Intermediate Processes on page 8-20 Using Signals on page 8-20 The proper use of the appropriate IPC mechanisms enables a Guardian process to communicate with an OSS process, giving it greater access to the open environment. See also the Using Interprocess Communication (IPC) Mechanisms on page 6-3.
Migrating Guardian Applications to the OSS Environment Using Files Using Files Guardian and OSS processes can share a file. The file can be an OSS file or a Guardian file and can be accessed through Guardian procedures or C functions in a Guardian program. In an OSS program, the file can be accessed using a C run-time function. If one process completes the writing of a file before the other process reads the file, no synchronization problems occur.
Migrating Guardian Applications to the OSS Environment Using Intermediate Processes resource allocation usage. OSS semaphores are available only to OSS programs. Semaphores are commonly used in both the OSS environment and the Guardian environment to synchronize access to shared memory. When memory is shared between a Guardian process and an OSS process, Guardian semaphores must be used.
Migrating Guardian Applications to the OSS Environment • • Using OSH From TACL Using PROCESS_SPAWN_ in a Guardian Program on page 8-22 Using the Guardian LISTNER Program on page 8-23 Using OSH From TACL The OSH command can be used to run a process in the OSS environment from the Guardian environment. The OSH command is a Guardian program that spawns an OSS process within the same node, allowing you to specify the environment and initial process attributes of the child process.
Migrating Guardian Applications to the OSS Environment Using PROCESS_SPAWN_ in a Guardian Program Using PROCESS_SPAWN_ in a Guardian Program Another way to start OSS programs from the Guardian environment is to use the PROCESS_SPAWN_ procedure call in a Guardian program from the TACL command interpreter. This method is a much more direct means of starting an OSS process from the Guardian environment, because the OSS shell command interpreter is not involved.
Migrating Guardian Applications to the OSS Environment Using the Guardian LISTNER Program Example 8-1. runossp.c Sample Code /* runossp.c - use the Guardian C runtime routine system() within a Guardian program invoked from the TACL command interpreter to run an OSS "command string". The command string may be any valid OSS shell command, OSS utility name, or script file pathname and can include parameters to be processed by the named command, utility or script.
Migrating Guardian Applications to the OSS Environment C Compiler Considerations for OSS Programs OSS server programs can be initiated from the OSS shell either in the foreground or in the background. They cannot be activated directly from the Guardian LISTNER program, but they can be activated by the LISTNER using an intermediate Guardian server program.
Migrating Guardian Applications to the OSS Environment Compiler Tools Compiler Tools In the Guardian environment, TNS C or C++ source modules are compiled using the TACL C command with appropriate qualifiers and parameters. When the executable program is built from more than one source module, each source module must be compiled separately and bound using the BIND command in a separate step.
Migrating Guardian Applications to the OSS Environment Include File Search Order /usr/include/stdio.h are identical to the contents of $SYSTEM.SYSTEM.STDIOH, for example. Any Guardian C or C++ source code that includes completely qualified header file names in Guardian filename syntax must be modified to use the equivalent OSS pathname syntax.
Migrating Guardian Applications to the OSS Environment Predefined Preprocessor Symbols Predefined Preprocessor Symbols The native and TNS C compilers provide three predefined preprocessor symbols: __TANDEM, __INT32, and __XMEM. (Note that there are two underscores at the beginning of these preprocessor symbol names.) You can use __TANDEM to increase the portability of your C programs. (Enclose system-dependent source text in a #ifdef or #ifndef section to test for the existence of __TANDEM.
Migrating Guardian Applications to the OSS Environment Porting a Guardian Program to the OSS Environment Porting a Guardian Program to the OSS Environment When you make the decision to port your Guardian C or C++ program from the Guardian environment to the OSS environment, there are more than C compiler issues to take into consideration.
Migrating Guardian Applications to the OSS Environment • Which Run-Time Routines Are Available Opening the standard input, output, and error files (stdin, stdout, stderr) The arguments for the program are set up in an argument array that is accessible from the main program. The run-time library also saves information in the environment array for Guardian processes. The environment array contains environment parameters from PARAM messages.
Migrating Guardian Applications to the OSS Environment Use of Common Run-Time Environment (CRE) Functions functions specified by the XPG4 specifications. It also provides HP extensions for input and output, memory management, string manipulation, and fault-tolerant programming. All ISO/ANSI C functions are available in both environments. Some of the XPG4 functions and HP extension functions are available only in one environment.
Migrating Guardian Applications to the OSS Environment • Replacing Guardian Procedure Calls With Equivalent OSS Functions $RECEIVE processing functions cannot be used to access process startup sequence information, including ASSIGNs and PARAMs. ($RECEIVE processing functions can continue to be used for interprocess communication.) These restrictions must be taken into consideration when migrating a Guardian program to the OSS environment.
Migrating Guardian Applications to the OSS Environment Interactions Between Guardian and OSS Functions When an OSS process calls one of the exec set of functions, the process remains in the OSS sense, but dies (another one is built) in the Guardian sense. The OSS process retains the same OSS process ID number, but can have different process handles throughout its lifecycle. Each call to a function in the exec set of functions creates a new Guardian process that requires a new process handle.
9 Porting From Specific UNIX Systems This subsection discusses other vendors’ UNIX environments for developing or compiling C and C++ programs that you want to port to the OSS environment. The following topics are discussed: • • • The UNIX Workstation Development Environment on page 9-1 C Compilation on a Workstation on page 9-7 Resolving the Endian Problem on page 9-8 The UNIX Workstation Development Environment Your UNIX workstation environment should be XPG4 compliant.
Porting From Specific UNIX Systems Editors Editors There are two common editors available on all UNIX workstations: • • The vi editor, which is the de facto standard, full-screen editor for UNIX systems. More information about using vi is available in the vi(1) online reference page; vi is also available in the OSS environment. The ed editor, which is the original line editor that comes with UNIX systems.
Porting From Specific UNIX Systems Development Tools You should perform your program analysis before porting to the OSS environment. Therefore, these tools are not provided with the OSS environment. Program Management Tools The following program management tools might be available on your UNIX workstation: • make is one of the most important utilities that comes with UNIX systems. It tracks dependencies between modules of a program and builds an executable file using rules in the make file.
Porting From Specific UNIX Systems • • • • • Development Tools cflow produces a chart of external references for checking program dependencies. ctrace prints out variables during execution for following execution of a C program, one statement at a time. cxref analyzes a group of C source files and builds a cross-reference table for symbols in each for checking program dependencies. indent indents and formats C source files to produce more readable C code.
Porting From Specific UNIX Systems • Development Tools strip removes the symbolic debugging information and symbol tables from an object file, reducing the amount of space taken on a disk. More information about using strip is available in the strip(1) online reference page; strip is also available in the OSS environment. If you manage your disk usage on the workstation using strip, then you can manage your disk usage in the OSS environment using strip.
Development Tools Porting From Specific UNIX Systems Standard and Alternate Library Directories Libraries on a UNIX workstation are usually kept in the /usr/lib and /lib directories. The OSS file system provides the same directory structure, so that ported applications can keep their libraries in the same locations. You should check the location and content of libraries on the system you are porting from and on the system you are porting to.
Porting From Specific UNIX Systems C Compilation on a Workstation C Compilation on a Workstation Many C compilers are available from workstation vendors, from public domain software suppliers, and from third-party software vendors. The C compilers and utilities discussed in the following paragraphs are used only as examples. Some of these may not exist on the platforms available to you.
Porting From Specific UNIX Systems GNU C Compiler Because applications that use strictly ISO/ANSI C semantics are the easiest to port, your application should compile successfully with the -Xa flag before being considered ready to port to the OSS environment. GNU C Compiler The GNU C compiler supports ISO/ANSI C language syntax and supports a “pedantic” mode, which requires strict adherence ISO/ANSI C. It supports the following: • • ISO/ANSI C and Common C.
Porting From Specific UNIX Systems Using Data Overlays The endian problem affects programs that are ported between platforms that use different byte-endian ordering when those programs access data within a word by using byte addresses or bit locations. For example: If var1=256+32+3, its value is 291 or 0x00000123. If the value of var1 is manipulated as a unit, then no problem exists.
Porting From Specific UNIX Systems Initializing Multiple-Word Entities in Chunks of Multiple Bits Initializing Multiple-Word Entities in Chunks of Multiple Bits Use care when porting code that initializes multiple-word entities with specific bit patterns. For example, on a little-endian system, the following array of two 32-bit integer values can be used to initialize a 64-bit double entity: u.ul[0] = 0x7fffffff; u.
10 Native Migration Overview This section is intended for OSS and Guardian C or C++ programmers who are interested in migrating their programs from the TNS environment to the TNS/R or TNS/E native environment. It contains an overview of the major areas in which differences exist between the two systems’ development tools, and between the TNS and native execution environments.
Native Environment Features Native Migration Overview HP supports development tools for native mode programs. These tools differ from those used to develop TNS programs, and are available in the OSS environment as well as some workstation environments. User libraries, SRLs, and DLLs are supported in TNS/R native mode. TNS/E native mode supports DLLs and user libraries (actually a DLL), but not SRLs.
Stack and Heap Sizes Native Migration Overview • • • Dynamic-Link Libraries on page 10-3 Signal Handling for Guardian Processes on page 10-4 OSS and Guardian API Interoperability on page 10-4 Stack and Heap Sizes User processes initially can have a stack size of 1 MB (G-series) or 2 MB (H-series), which can be specified by processes to be up to 32 MB. You can specify the maximum value for the size of the stack, but it is given a default size when the process is first created.
Signal Handling for Guardian Processes Native Migration Overview 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.
User Library Migration Issues Native Migration Overview There are significant benefits to using the native C and C++ compilers. They compile code faster than the TNS compiler and the Accelerator or Object Code Accelerator, and may produce faster code. The native C and C++ cross compilers run in the Guardian and OSS environments, as well as on the HP Enterprise Toolkit—NonStop Edition (ETK) and, for G-series systems only, on the HP Tandem Development Suite (TDS) on a PC.
C Language Compilers Native Migration Overview Two types of user libraries are supported: TNS user libraries and native user libraries. A TNS user library is available only to TNS interpreted and accelerated processes in the Guardian environment. A native user library is available only to native processes in the Guardian and OSS environments.
Using the C Run-Time Library Native Migration Overview The native C and C++ compilers require that certain pragmas be specified as flags to the OSS c89 utility if the default settings are not desired; for instance, the INSPECT, RUNNABLE, SEARCH, SSV, and other pragmas. For details on C or C++ program compilation in the OSS environment, refer to the c89(1) reference page either online or in the Open System Services Shell and Utilities Reference Manual. 3. Check the use of changed pragmas.
Changes to the exit() Function Native Migration Overview Changes to the exit() Function Check the use of the changed C library exit() standard function. In the TNS Guardian environment, a nonzero status parameter value from exit() indicates abnormal termination. In the native Guardian environment, any status parameter value indicates normal termination.
Memory Attributes Native Migration Overview Memory Attributes Native processes have different stack and heap sizes than TNS interpreted processes and TNS accelerated processes.
TAL to pTAL Conversion Native Migration Overview • • • • • • SIGACTION_INIT_ supersedes ARMTRAP. CHECKPOINTX supersedes CHECKPOINT. CHEKPOINTMANYX supersedes CHECKPOINTMANY. CURRENTSPACE is obsolete and has no replacement. ADDRESS_DELIMIT_ supersedes LASTADDR and LASTADDRX. SIGACTION_SUPPLANT_ supersedes SETTRAP. For details on Guardian procedures, refer to the Guardian Procedure Calls Reference Manual.
11 Porting or Migrating Sockets Applications This section discusses the following topics: • • • Porting UNIX Sockets Applications to the OSS Environment on page 11-1 Porting Guardian Sockets Applications to the OSS Environment on page 11-4 Interoperability of OSS and Guardian Sockets in an OSS Application on page 11-8 Porting UNIX Sockets Applications to the OSS Environment The following topics are discussed in this subsection: • • • General Considerations on page 11-1 Differences Between OSS Sockets a
Porting or Migrating Sockets Applications Differences Between OSS Sockets and Berkeley Software Distribution Sockets be named by setting the Guardian MAP DEFINE =TCPIP^PROCESS^NAME for the sockets application before starting the application or by calling the socket_transport_name_set() function while the application is running. The current transport provider process name can be determined by calling the socket_transport_name_get() function.
Porting or Migrating Sockets Applications ° • • • • Porting Situations socket_transport_name_get(), which an application can call to retrieve the name of the transport provider process being used. OSS sockets can return the following error codes that are not BSD error codes: ETANOTRUNNING Returned when an attempt is made to create a socket without a transport agent process running on that processor.
Porting or Migrating Sockets Applications Porting Guardian Sockets Applications to the OSS Environment A BSD sockets application using nonblocking socket input/output can be easily ported to the OSS environment with one minor change. In the UNIX environment, a socket is marked as nonblocking by calling the fcntl() function for the socket descriptor and using the function’s F_SETFL command to set the FNDELAY flag.
Porting or Migrating Sockets Applications Differences Between OSS Sockets and Guardian Sockets Differences Between OSS Sockets and Guardian Sockets If you have been using Guardian sockets, you should be aware of the differences between the Guardian implementation and the OSS implementation. • • Guardian processes cannot receive the SIGWINCH signal. OSS processes support this signal.
Porting or Migrating Sockets Applications Differences Between OSS Sockets and Guardian Sockets LISTNER cannot directly activate OSS programs. To activate an application in the OSS environment the same way that LISTNER activates Guardian programs, either start the application using inetd or write a small program to interface with the LISTNER process. The latter program would start the real application in the OSS environment, passing the port number and IP address from LISTNER to the OSS application.
Porting or Migrating Sockets Applications • • • 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. Table 11-2.
Porting or Migrating Sockets Applications Interoperability of OSS and Guardian Sockets in an OSS Application Interoperability of OSS and Guardian Sockets in an OSS Application An OSS sockets application might contain program modules that call Guardian sockets functions as well as program modules that call OSS sockets functions, but only one type of sockets functions (OSS or Guardian) can be used in a given module.
Porting or Migrating Sockets Applications Interoperability of OSS and Guardian Sockets in an OSS Application Table 11-3.
Porting or Migrating Sockets Applications Interoperability of OSS and Guardian Sockets in an OSS Application Table 11-3.
12 Porting Threaded Applications This section summarizes the information you need to port existing threaded applications from the previous standard (Draft 4) to Standard POSIX Threads. In particular, this section summarizes considerations for porting HP NonStop Distributed Computing Environment (DCE) Threads applications, and gives pointers to sources of detailed information. Standard POSIX Threads (T1248), a new product available in the G06.14 RVU, adheres to IEEE POSIX Standard 1003.1c.
Porting Threaded Applications General Considerations for Porting to Standard POSIX Threads General Considerations for Porting to Standard POSIX Threads For applications that use thread functions adhering to the previous standard (Draft 4), see Appendix B, “Pthreads Draft 4 vs. The Final Standard,” in Pthreads Programming by Nichols, Buttlar, and Farrell.
A Equivalent OSS and UNIX Commands for Guardian Users Table A-1 provides a comparison of Guardian commands and similar or equivalent OSS and UNIX commands. For each Guardian command, a description is provided. If a similar or equivalent OSS command exists, it is listed. Table A-1.
Equivalent OSS and UNIX Commands for Guardian Users Table A-1.
Equivalent OSS and UNIX Commands for Guardian Users Table A-1. Equivalent OSS and UNIX Commands for Guardian Users (page 3 of 3) Guardian Command Description OSS and UNIX Commands RESTORE Restores backup copies of disk files pax, pinstall RUN Executes a program run SET DEFINE Sets values for attributes in working set set_define* SET DEFMODE Enables attributes for current command interpreter process SETPROMPT Changes command interpreter prompt env, .
Equivalent OSS and UNIX Commands for Guardian Users Open System Services Porting Guide —520573-006 A- 4
B Equivalent Guardian Commands for OSS and UNIX Users Table B-1 provides a comparison of OSS and UNIX commands and similar or equivalent Guardian commands. For each OSS and UNIX command, a description is provided; if a similar or equivalent Guardian command exists, it is listed. Table B-1.
Equivalent Guardian Commands for OSS and UNIX Users Table B-1.
Equivalent Guardian Commands for OSS and UNIX Users Table B-1.
Equivalent Guardian Commands for OSS and UNIX Users Table B-1.
Equivalent Guardian Commands for OSS and UNIX Users Table B-1. Equivalent Guardian Commands for OSS and UNIX Users (page 5 of 5) OSS and UNIX Command Description wc Word, line, byte or character count who Displays who is on the system write Writes to another user xargs Constructs argument list and invokes utility yacc Yet another compiler compiler Guardian Commands or TACL Macros USERS, STATUS * OSS command only. Bracketed [ ] information indicates a series of command steps.
Equivalent Guardian Commands for OSS and UNIX Users Open System Services Porting Guide —520573-006 B- 6
C Equivalent Inspect Debugging Commands for dbx Commands The Inspect debugger displays source from OSS files. Because line numbers automatically increment for OSS files but not for Guardian files, line numbers for corresponding converted source files might differ. If your file was originally compiled in an OSS environment, the line numbers do correspond. Table C-1 presents a mapping of dbx commands to Inspect commands to help OSS programmers who are more familiar with dbx than with the Inspect debugger.
Equivalent Inspect Debugging Commands for dbx Commands Table C-1. Equivalent Inspect Commands for dbx Commands (page 2 of 2) dbx Inspect dbx Inspect nexti Step Icode whatis Info Identifier playback input Obey when Break ... IF ... THEN ... playback output N.A. where Trace print Display whereis Match Identifier, Match Scope printf N.A. which N.A. printregs Display Register Table C-2 lists Inspect commands that do not have a dbx command equivalent. Table C-2.
D Equivalent Native Inspect Debugging Commands for dbx Commands Native Inspect is the H-series command line symbolic debugging tool. The Native Inspect debugger displays source from OSS files. Because line numbers automatically increment for OSS files but not for Guardian files, line numbers for corresponding converted source files might differ. If your file was originally compiled in an OSS environment, the line numbers do correspond.
Equivalent Native Inspect Debugging Commands for dbx Commands Table D-1.
E Standard POSIX Threads Functions: Differences Between the Previous and Current Standards This appendix contains: • • Reference Pages for Thread Functions on page E-1 Changed Thread Functions on page E-2 Reference Pages for Thread Functions For full syntax and usage information about the Standard POSIX Threads functions, see the Open System Services System Calls Reference Manual.
Standard POSIX Threads Functions: Differences Between the Previous and Current Standards Changed Thread Functions Changed Thread Functions This subsection lists the thread functions in groups according to differences between the following two standards: • • The IEEE 1003.1c standard, 1995. (Standard POSIX Threads adheres to this standard, officially listed as International Standard ISO/IEC 9945-1; 1996 (E) IEEE Std. 1003.1,1996 [Incorporating ANSI/IEEE Stds 1003.1-1990, 1003.1b-1993, 1003.
Standard POSIX Threads Functions: Differences Between the Previous and Current Standards Changed Thread Functions Table E-1 lists the Draft 4 thread functions that have been either replaced by new standard functions or renamed in Standard POSIX Threads. Table E-1.
Standard POSIX Threads Functions: Differences Between the Previous and Current Standards Changed Thread Functions Table E-2 lists the thread functions that have changes in the syntax of their parameters. Table E-2.
Standard POSIX Threads Functions: Differences Between the Previous and Current Standards Changed Thread Functions Table E-2.
Standard POSIX Threads Functions: Differences Between the Previous and Current Standards Changed Thread Functions Table E-4 lists thread functions that have changes to return values only. Errors are returned as status values, not in errno. Code changes are required if you are porting an existing threaded application to Standard POSIX Threads. Table E-4.
Standard POSIX Threads Functions: Differences Between the Previous and Current Standards Changed Thread Functions Table E-4. Thread Functions With Changes to Return Values Only (page 2 of 2) Function Return Values in Standard POSIX Threads pthread_get_ expiration_np() 0 = successful pthread_join() 0 = successful -1 = unsuccessful (Check errno for last error, such as EINVAL.) EINVAL The implementation has detected that the value specified by thread does not refer to a thread that can be joined.
Standard POSIX Threads Functions: Differences Between the Previous and Current Standards Changed Thread Functions Table E-5 lists the return values for new thread functions and for thread functions whose return values have changed in addition to other changes listed in this appendix. Table E-5.
Standard POSIX Threads Functions: Differences Between the Previous and Current Standards Changed Thread Functions Table E-5. Thread Functions With Changes to Return Values Among Other Changes (page 2 of 5) Function Return Values in Standard POSIX Threads pthread_attr_ setschedparam() 0 = successful EINVAL The value of the attribute being set is invalid. ENOTSUP An attempt was made to set the attribute to an unsupported value.
Standard POSIX Threads Functions: Differences Between the Previous and Current Standards Changed Thread Functions Table E-5. Thread Functions With Changes to Return Values Among Other Changes (page 3 of 5) Function Return Values in Standard POSIX Threads pthread_detach() 0 = successful EINVAL The implementation has detected that the value specified by thread does not refer to a thread that can be joined. ESRCH No thread could be found corresponding to that specified by the given thread ID.
Standard POSIX Threads Functions: Differences Between the Previous and Current Standards Changed Thread Functions Table E-5. Thread Functions With Changes to Return Values Among Other Changes (page 4 of 5) Function Return Values in Standard POSIX Threads pthread_mutexattr_ destroy() 0 = successful pthread_mutexattr_ getkind_np() 0 = successful pthread_mutexattr_ init() 0 = successful EINVAL The value specified by attr is invalid. -1 = error (Check errno for last error, such as EINVAL.
Standard POSIX Threads Functions: Differences Between the Previous and Current Standards Changed Thread Functions Table E-5. Thread Functions With Changes to Return Values Among Other Changes (page 5 of 5) Function Return Values in Standard POSIX Threads pthread_setspecific() 0 = successful EINVAL The key value is invalid. ENOMEM Insufficient memory exists to associate the value with the key.
Standard POSIX Threads Functions: Differences Between the Previous and Current Standards Changed Thread Functions Table E-8 lists the thread functions that are not supported in Standard POSIX Threads. Thread and C library functions that use priority scheduling are not supported because the NonStop operating system environment is nonpreemptive and is not an SMP environment. Table E-8.
Standard POSIX Threads Functions: Differences Between the Previous and Current Standards Changed Thread Functions Table E-8. Thread Functions Not Supported in Standard POSIX Threads (page 2 of 2) Function Reason pthread_mutexattr_ getprotocol() _POSIX_THREAD_PRIORITY_SCHEDULING not defined. pthread_mutexattr_ getpshared() _POSIX_THREAD_PROCESS_SHARED not defined. pthread_mutexattr_ setprioceiling() _POSIX_THREAD_PRIORITY_SCHEDULING not defined.
Standard POSIX Threads Functions: Differences Between the Previous and Current Standards Changed Thread Functions Table E-9 lists the old and new syntax of the optional functions that are supported by Standard POSIX Threads. The _np suffix indicates that the function is not portable. Table E-9.
Standard POSIX Threads Functions: Differences Between the Previous and Current Standards Changed Thread Functions Table E-10.
Standard POSIX Threads Functions: Differences Between the Previous and Current Standards Changed Thread Functions Table E-10.
Standard POSIX Threads Functions: Differences Between the Previous and Current Standards Open System Services Porting Guide —520573-006 E -18 Changed Thread Functions
Glossary absolute pathname. An Open System Services (OSS) pathname that begins with a slash (/) character and is resolved beginning with the root directory. Contrast with relative pathname. address space. The memory locations to which a process has access. ANSI. The American National Standards Institute. API. See application program interface (API). application program interface (API).
character set Glossary character set. A finite set of characters (letters, digits, symbols, ideographs, or control functions) used for the organization, representation, or control of data. See also code set. child process. A process created by another process. The creating process becomes the parent process of the new process. See also parent process. client application. An application that requests a service from a server application. Execution of remote procedure calls is an example of such a service.
DLL. Glossary DLL. See dynamic-link library (DLL) dynamic-link library (DLL). A collection of procedures whose code and data can be loaded and executed at any virtual memory address, with run-time resolution of links to and from the main program and other independent libraries. The same DLL can be used by more than one process. Each process gets its own copy of DLL static data. Contrast with shared run-time library (SRL). See also position-independent code (PIC). empty directory.
file system Glossary The term file system is often used interchangeably with fileset in UNIX publications. file system. In the Open System Services (OSS) environment, a collection of files and file attributes. A file system provides the namespace for the file serial numbers that uniquely identify its files. Open System Services provides a file system (see also ISO/IEC IS 9945-1:1990 [ANSI/IEEE Std. 1003.1-1990], Clause 2.2.2.
Guardian Glossary • Saved-set group ID Guardian. An environment available for interactive or programmatic use with the HP NonStop operating system. Processes that run in the Guardian environment use the Guardian system procedure calls as their application program interface; interactive users of the Guardian environment use the HP Tandem Advanced Command Language (TACL) or another HP product’s command interpreter. Contrast with Open System Services (OSS). Guardian environment.
internationalization. Glossary internationalization. The process of designing and coding software so that it can be adapted to meet the needs of different languages, cultures, and character sets, with the ability to handle various linguistic and cultural conventions. Internationalization methods enable the processing of character-based data independently of the underlying character encoding, allowing choice among character sets.
localization Glossary localization. The process of adapting computer interfaces, data, and documentation to the culturally accepted way of presenting information in the culture. Sometimes referred to as “L10N,” derived from the 10 letters between the initial “L” and the final “N” of the word “localization.” login. The activity by which a user establishes a locally authenticated identity on an HP NonStop network node. Each login has one login name. login name. A user name associated with a session.
open file description Glossary open file description. A data structure within an HP NonStop Expand network node that contains information about the access of a process or of a group of processes to a file. An open file description records such attributes as the file offset, file status, and file access modes. An open file description is associated with only one open file but can be associated with one or more file descriptors. open system.
pathname component Glossary pathname component. See filename. pathname resolution. In the OSS environment, the process of associating a single file with a specified pathname. pathname-variable limits. Limits that can vary within the OSS file hierarchy. That is, the limits on a pathname variable can vary according to the directory in which pathname resolution begins. path prefix. In the OSS environment, a pathname, with an optional final slash (/) character, that refers to a directory. PIC.
process group Glossary thread of control that executes within that address space, and the system resources required by that thread of control. process group. A set of processes that can signal associated processes. Each process in an Expand node is a member of a process group; the process group has a process group ID. A new process becomes a member of the process group of its creator. process group ID. The unique identifier representing a process group during its lifetime. process group leader.
root directory Glossary Accelerator-generated RISC instructions are produced by accelerating TNS object code using the Accelerator program (AXCEL). Native-compiled RISC instructions are produced by compiling source code with a TNS/R native compiler. root directory. A directory associated with a process that the system uses for pathname resolution when a pathname begins with a slash (/) character. saveabend file. A file containing dump information needed by the system debugging tool.
signal mask Glossary signal mask. The set of signals that are currently blocked from delivery to a specific process. snapshot file. See process snapshot file. socket. An end-point for stream-oriented communication. A socket has a file descriptor. special character. A character entered from a terminal that has an effect other than being part of the input stream from that terminal. static server.
terminal Glossary terminal. A type of character special file that conforms to the interface description in Clause 7 of ISO/IEC IS 9945-1: 1990. TNS C compiler. The C compiler that generates TNS object files. TNS object files can be processed by the Accelerator or Object Code Accelerator to produce accelerated object files. Compare with TNS/R native C compiler and TNS/E native C compiler. TNS instructions.
TNS/R native mode Glossary TNS/R native mode. The primary execution environment on a TNS/R system, in which native-compiled MIPS object code executes, following TNS/R native-mode compiler conventions for data locations, addressing, stack frames, registers, and call linkage. See also TNS/E native mode. TNS/R native object code. The RISC instructions that result from processing program source code with a TNS/R native compiler.
Index A abort() function 5-8 Absolute pathname Glossary-1 Accelerated TNS object files 2-3 Accelerator programs Accelerator 2-12, 8-9, 10-2, 10-10 axcel 2-11 Object Code Accelerator 2-11, 2-12, 8-9, 10-2, 10-10 TNS/E 2-3 TNS/R 2-3 Access control lists (ACLs), Guardian files 7-9 access() function, Guardian files 7-19 ACLs, Guardian files 7-9 Address space Glossary-1 memory, mapped files 6-2 shared memory 6-9 ADDRESS_DELIMIT_ procedure 10-10 Advisory locking 7-20 Advisory lock, fcntl() function 7-20 AF_INET s
B Index B Background process Glossary-1 Background process group Glossary-1 Backward compatibility, extensions 7-1 Base computing platform Glossary-1 Berkeley Software Distribution (BSD) Glossary-1 Binary semaphores 8-19 BIND command 8-25 Binder program 2-14, 2-21, 10-5 Binding, static 2-14 Blocking I/O 6-3 Bourne shell 9-1 Bridge process 8-20 BSD Glossary-1 Buffered data, caching 6-21 Built-in run utility 4-22 Byte orders compatibility 7-2 guidelines 7-11 C C compilation issues for Guardian programs 8-4
C Index Caching (continued) file 6-21 OSS name server 6-19, 6-21 CAE Glossary-2 cat utility Guardian files 4-24 in Guardian environment 4-17 redirecting input and output with 4-20 Catalog, OSS Enscribe database 6-19 file operations 6-19 OSS fileset 6-19 CCOMP compiler 8-25 cextdecs.
C Index Commands, OSS (continued) repeating 4-8 run, built-in 4-22 typeset -f 4-7 Common applications environment (CAE) Glossary-2 Common C code 2-2, 10-1 in native environment 10-1 language 7-1, 7-2, 7-10, 7-11, 7-12, 9-8 compiler 7-13 Common header files 2-10 Common library routines 2-10 Common Run-Time Environment (CRE) See CRE Communication with OSS programs 8-4 Compatibility compilers 7-2 data-file 7-2 operating systems 7-3 Compiler locations TNS 2-15 TNS/E native 2-15 TNS/R native 2-15 Compiler symb
D Index CRE (continued) library, definition 5-16 main() function 8-16 mixed languages 8-16 OSS programs 7-18 role of 5-15 trap handler 10-9 creat() function, Guardian file system 7-21 Cross-compilation native compilation tools 2-4 options 2-4 support 2-2 UNIX workstations 2-4 Cross-processor pipes 6-8 process-creation functions 6-14, 6-15, 6-22 CTOEDIT utility 4-17 ctype.
E Index Directory Glossary-2 deleting 4-26 operations, performance 6-20 root 7-7 stream, inherited by child process 6-20 Disk I/O, caching 6-21 Disk opens, performance 6-21 DLL See Dynamic-link library (DLL) DP2, with OSS name server 6-19 Dynamic linking 9-5 Dynamic portability checker, OSPC 3-4, 7-3 Dynamic server 6-23, 6-24 Dynamic-link library (DLL) 10-3, 10-5 building your own 2-14 common between native environments 5-5 multiple 10-3, 10-4 user libraries 10-3 E ed utility 4-12, 9-2 EDIT files 5-2, 5-
F Index exec set of functions creating processes 7-8 OSS compared to UNIX 6-13 OSS environment 7-23 process handle 7-24 UNIX environments 6-13 Executable and linkable format (ELF) See ELF Executable file compatibility 2-3 example 4-13 native 10-4 exit() function changes for native mode 10-8 child process 7-24 issued by either OSS or Guardian 5-9 parent process 7-24 Extensions backward compatibility with 7-1 HP See HP extensions in modules 7-5 scope of 7-2 using 6-12, 7-11 F fc utility, editing a temporar
F Index File suffixes in programming 4-13 requirement for native C compilers 2-13 File system ID, translating 6-18 File systems Guardian 4-24, 7-7, 7-21 OSS and EDIT files 4-24 defined 7-7 management of 6-18 /G, OSS environment 4-17 File transfer protocol (FTP) 2-6 File Utility Program (FUP) commands See FUP commands file utility, deleting files 4-25 Filenames beginning with ZYQ 4-18 conversion Guardian to OSS 4-18 OSS to Guardian 6-19 creation, OSS 6-19 format, Guardian and creating OSS files 6-19 Guardi
F Index Files, Guardian (continued) deleting 4-26 directory structure 7-8 EDIT 4-23, 4-24, 7-8 filename format 7-8 open() function 7-21 pax utility 4-25 permission 7-19 protection bits 7-9 reading with OSS functions 7-8 relocating 4-25 renaming 4-25 restoring after conversion 4-25 security 4-24, 7-9, 7-19, 7-21 special 7-8 types 4-17, 4-25, 5-9, 5-10 with OSS functions 7-8, 7-19 Files, OSS See also Files accessing 5-10, 7-7, 7-10 compared with Guardian 7-9 filename conversions 5-2 printer I/O 5-13 protect
G Index Functions (continued) Guardian alternate-model 10-7 obsolete 10-7 with OSS processes 7-8 interoperability 7-17 listing current 4-7 making queries 7-8 managing processes 6-14 memory allocation 6-11 memory deallocation 6-11 modifying process environment 7-8 nonstandard 7-4, 7-6 obsolete 10-7 OSS See functions under OSS process ID 6-14 process-creation 6-13, 7-27 programming guidelines 7-5 ranked by portability 7-6 reading Guardian files 7-8, 7-9 sending signals 7-8 shell 4-7 standard 7-4, 7-6 trap h
H Index Guardian (continued) filenames See Filenames files See Files, Guardian header files 11-5 interface, compared to OSS interface 1-8 nowait I/O 11-7 PARAMs, converted into OSS variables 4-9, 8-21 PIN 4-15 procedures called from OSS 7-28 changes for native mode 10-9 compared to UNIX features 1-8 extended for OSS 5-11 FILENAME_FINDNEXT_ 5-4 FILE_GETINFOBYNAME_ 8-11 FILE_GETINFOLISTBYNAME_ 8-1 1 FILE_GETINFOLIST_ 8-11 FILE_GETINFO_ 8-11 FILE_GETRECEIVEINFO_ 8-11 FILE_OPEN_ 8-11 GROUPMEMBER_GETNEXT_ 8 -1
I Index Header files (continued) entry points 7-13 environment-specific functions 8-16 feature-test macros 5-3, 7-13, 8-26 for Guardian programs 8-7 function entry points 5-4 function prototypes 7-12 Guardian interface 7-28 guidelines 7-11 HP extensions 7-12 ISO/ANSI C 1-6 standard 5-3 OSS and Guardian compared 7-13 POSIX standards 5-3 pragmas 7-13 recommendations 7-28 search order 8-26 standard C and C++ 2-15 standards 7-12 tal.h 5-4, 7-28 tdmext.h 7-27 XPG4 5-3 $SYSTEM.
I Index Inspect (continued) commands compared to dbx commands C-1 compared with noft utility 2-21 debugging OSS files 2-18 native files 2-19 noft utility 2-19 optimized files 2-19 OSS environment considerations 2-20 restrictions 2-19 running from TACL 2-20 running program files 2-20 TNS files 2-18 TNS/R native files 2-18 TNS/R native programs 10-5 with OSS commands 4-22 Intermediate processes 8-20 Internationalization 7-29 Internet address, OSS server program 8-24 Internet domain address manipulation func
J Index ISO/IEC-conforming POSIX.
M Index Listener servers 6-24, 6-25 LISTNER process compared to inetd demon 8-23 configuration file 6-25 Guardian program 8-23 inetd activated programs 6-27 listening for requests 6-25 starting Guardian servers 6-26 Load balancing 11-3 static server 6-24 tdm_spawn() 6-15 Locales character classification 7-29 default 7-30 defined 7-29 environment variables 7-30 in client/server applications 7-30 interoperability 7-30 objects 7-29 locale.
N Index Message queues 6-4 fork() and exec set of functions 6-7 global 6-7 identifiers 6-7 msgctl() function 6-6 msgget() function 6-6 msgrcv() function 6-6 msgsnd() function 6-6 not between Guardian and OSS environments 6-6 $RECEIVE file 6-26 Messages from $RECEIVE 5-9 start-up, Guardian 5-2 Migration 10-1 data model 10-6 Guardian program to the OSS environment 8-4 guidelines 8-1, 8-2 keywords, obsolete 10-7 options 8-3 planning for 10-2 pragmas 10-6, 10-7 recommendations 10-2 sequence of steps 8-2 to na
O Index Native process Glossary-7 Native shared run-time libraries See TNS/R native shared run-time library (TNS/R native SRL) Native signal Glossary-7 Native-compiled Itanium instructions Glossary-7 Native-compiled RISC instructions Glossary-7 Native-mode applications 10-1 Network activity, listener servers 6-25 Network utilities, on workstations 2-6 nld utility Guardian environment 2-13 memory 10-3 OSS environment 2-13 replacing Binder 2-21, 10-5 TNS/R native only 2-21, 10-2 user library 10-6 nm utility
O Index open() function 5-10 and the chown() function 7-20 Guardian file system 7-21 opening FIFOs 6-8 Operating system, compatibility 7-3 Operating system, HP NonStop 4-3, Glossary-5 Optimization TNS/E native environment 10-5 TNS/R native environment 10-5 variables 10-5 osh utility 8-18 converting Guardian PARAMs 4-9 Guardian DEFINEs 8-21 Guardian environment variables 4-8 intermediate processes 8-20 login initialization 4-19 OSS shell 4-5, 4-19 starting from Guardian environment 5-7 TACL RUN options 8-2
P Index OSS (continued) signal Glossary-8 standards 1-8 OSS catalog See Catalog, OSS OSS name server caching 6-19, 6-21 DP2 6-18, 6-19 opening FIFOs 6-8 opening files 6-19 OSS pipe server 6-18 resolving names 6-8, 6-18 OSS pipe server file operations 6-18 opening FIFOs 6-8 pipe creation 6-8 OSS process ID (PID) 5-2, 7-27 defined Glossary-8 kill utility 4-11 process-management 5-8 OSSTTY facility 4-12, 4-20, 4-24, 5-13, 8-21 OSS_PID_NULL_ procedure 8-12 Output functions 1-3 redirecting cat utility 4-20 gre
P Index Performance (continued) system costs 6-22 World Wide Web server 6-24 pe_heap_max attribute 6-14, 10-9 pe_mainstack_max attribute 6-14, 10-9 pe_parms attribute 6-14 pe_space_guarantee attribute 6-12, 6-14, 10-9 PIC See Position-independent code (PIC) PIN, Guardian 4-15 Pipe buffer, creating pipes 6-8 Pipe character (|) 4-22, 6-7 Pipe server, OSS See OSS pipe server Pipes 6-4 across processors 6-8 creating 6-7, 6-8 defined Glossary-9 lseek() function 7-20 pipe() function 6-7 pname utility, pathname
P Index Process creation across processors 6-14, 6-15, 6-22 calls 6-16 differences between environments 5-2 functions Guardian attributes 6-13 specific to HP 7-27 UNIX environment 6-13 Guardian attributes 5-2 Guardian environment variables 4-8 OSS attributes 5-2 OSS shell 4-8 performance 6-13 procedures 5-7 PROCESS_SPAWN_ procedure See PROCESS_SPAWN_ procedure static server 6-23 Process group Glossary-10 Process group ID Glossary-10 Process group leader Glossary-10 Process group lifetime Glossary-10 Proce
P Index Processes, OSS (continued) nowait manner 8-22 propagated attributes 7-8 requester 8-18 server 8-18 shared memory 8-19 status information 4-11, 7-25 stopping 4-11 terminating 7-8, 7-25 waited manner 8-22 PROCESSHANDLE_*_ procedures 8-13 PROCESSNAME_CREATE_ procedure 8-12 Processors architecture, multiple 7-4 opening files 6-22 static server 6-24 PROCESS_ACTIVATE_ procedure 8-12 PROCESS_CREATE_ procedure, changes for native mode 10-9 PROCESS_DEBUG_ procedure 8-12 process_extension_def input structur
Q Index Q Queue files printing 4-12 use of 8-19 $RECEIVE 6-26 R readdir() function, Guardian file system 7-22 readlink() function, symbolic links 6-22, 7-21 READX procedure 5-11 read() function, Guardian file system 7-22 Recoding for UNIX features 6-2 UNIX functions 7-6 Redirecting input, left angle bracket (<) operator 4-20 Redirecting output, right angle bracket (>) operator 4-20 Reference page Glossary-10 Relative pathname Glossary-10 remove() function 5-5, 8-15 Removing directories 7-20 rename() func
S Index Security files 4-24, 7-9, 7-10, 7-18, 7-21 interoperability 7-10 models 7-9, 7-23 process-identity attributes 7-9 protection bits 7-9 select() function 6-2 Semaphores 6-5 accessing resources with 6-10 binary 8-19 Guardian 8-19 OSS 8-19 shared memory 6-9 single processor 6-10 XPG4 counting 6-10 Sequential processing, multithreading 6-2 Server application Glossary-11 Server processes and client communication 6-23 demon 6-24 dynamic 6-23 Guardian, starting LISTNER process 6-26 inetd 6-25 listener 6-2
S Index Shells (continued) manipulating files with 4-23 OSS See shell under OSS running from TACL 4-19 running TACL programs 4-21 set utility 4-5 startup procedure 4-5 switching from TACL to OSS 4-21 TACL, accessing from OSS shell 4-21 UNIX 4-4 variables 4-6 sigaction() function, signals 10-4 SIGACTION_INIT_ procedure 10-10 SIGACTION_SUPPLANT_ procedure 10-10 SIGCHLD signals 5-9 SIGIO signal 11-1 Signal delivery Glossary-11 Signal generation Glossary-11 Signal handler Glossary-11 Signal mask Glossary-12 c
S Index Standards 2-2 and interoperability 5-1 C language 4-3, 7-1 c89 utility 2-10 compliance, portability checking 3-1 functions, portability 7-4 header files 7-12 maximize portability 7-12 OSS 1-8 POSIX 7-7 Start-up files profile 4-5 shell 4-5 Static linking 9-5 Static server Glossary-12 listening for requests 6-23 load balancing 6-24 process-creation functions 6-23 queue file 6-23 started by demon process 6-24 World Wide Web server 6-24 $RECEIVE 6-26 Statistics, ls utility 4-25 STATUS command compared
T Index System Glossary-12 compatibility 2-2 entry points 7-13 limits, OSS environment 7-17 System calls OSS standards 1-8 portability 3-2 System process Glossary-12 System services, portability checking 3-4 System V Glossary-12 system() library call, using in a Guardian program 8-21 System-level routines, Guardian, message queues 6-6 SYSTYPE pragma environment-specific functions 10-4 mixed-module programming 5-15 S_IFCHR file type system, mknod() function 7-21 T T1248 spt functions E-15 TACL commands 8-
T Index terminate_program() function, changes to make for 10-8 Text files editing 4-16 printing 4-18 Thread functions E-2 Threaded applications, porting 12-1 Threads Standard POSIX 12-1 times() function 5-8 time.
U Index TNS/R native object file Glossary-14 TNS/R native process Glossary-14 TNS/R native shared run-time library (TNS/R native SRL) 10-3, Glossary-14 TNS/R native signal Glossary-14 TNS/R native user library Glossary-13 TNS/R native-mode applications 10-1 Tools C program analysis 9-2 porting See tools under Porting Transaction Application Language (TAL) See TAL programs Transferring files, back to the workstation 2-8 Translation limits 7-16 Transport Layer Interface (TLI) 6-3 Trap handling 10-4 performa
W Index vi utility (continued) defined 4-12, 9-2 editing 2-17 set options 4-8 Visual Inspect 2-19 debugging OSS files 2-18 native files 2-19 running from TACL 2-20 running program files 2-20 TNS/E native programs 10-5 TNS/R and TNS/E native program files 2-18 TNS/R native programs 10-5 Visual Inspect restrictions 2-19 W Waited operation, PROCESS_SPAWN_ procedure 6-15 Waited OSS process 8-22 waitpid() function, terminated processes 7-25 wait() function, terminated processes 7-25 who utility, Guardian form
Special Characters Index _exit() function, issued by either OSS or Guardian 5-9 _IGNORE_LOCALE feature-test macro 5-3, 7-13, 7-15, 8-26 _OSS_HOST feature-test macro 7-13, 7-15, 8-26 _OSS_TARGET feature-test macro 7-13, 7-15, 8-26 _POSIX_C_SOURCE feature-test macro 5-3, 7-13, 8-26 _POSIX_C_SOURCE=2 feature-test macro 7-13, 8-26 _POSIX_SOURCE feature-test macro 5-3, 7-13, 8-26 _TANDEM_SOURCE feature-test macro 5-3, 7-13, 7-14, 8-26 _TNS_E_TARGET preprocessor symbol 7-15 _TNS_R_TARGET preprocessor symbol 7-1
Special Characters Index Open System Services Porting Guide —520573-006 Index -32
