Open System Services Porting Guide Abstract 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. This manual supports J06.03 and all subsequent J-series RVUS, H06.06 and all subsequent H-series RVUs, and G06.
© Copyright 1995, 2012 Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. Warranty The information contained herein is subject to change without notice.
Contents About This Manual......................................................................................13 Supported Release Version Updates (RVUs)................................................................................13 Intended Audience..................................................................................................................13 Disclaimer.............................................................................................................................
Using Archiving Utilities......................................................................................................37 The tar Utility................................................................................................................37 The pax Utility..............................................................................................................37 Working on the NonStop System..............................................................................................
FCEDIT....................................................................................................................57 HISTSIZE and HISTFILE..............................................................................................57 Guardian Environment Variables and the OSS Shell...............................................................57 OSS Commands for the Guardian User.....................................................................................59 Managing Processes From OSS......
Process-Creation Interoperability..........................................................................................75 fork() and exec Set of Functions.......................................................................................75 tdm_fork(), tdm_execve set, and tdm_spawn() Functions......................................................75 PROCESS_LAUNCH_ Procedure......................................................................................75 PROCESS_SPAWN_ Procedure................
Using the tdm_spawn Set of Functions for Load Leveling..........................................................97 Using PROCESS_SPAWN_..................................................................................................98 Which Call to Use for Process Creation.................................................................................98 The SIGCHLD Signal and the Creation of Zombie Processes.........................................................99 Performing File Operations.............
OSS and Guardian APIs..............................................................................................120 System and Process Limit Values....................................................................................120 Device Interfaces.........................................................................................................121 /etc/passwd and /etc/group Data Files........................................................................121 OSS Programs and CRE...............
Converting TAL or pTAL Code to C or C++..........................................................................138 Using New and Extended Guardian Procedures in Guardian Programs..................................138 Using OSS Functions in a Guardian Program.......................................................................138 Communicating With OSS Programs..................................................................................138 Migrating a Guardian Program to the OSS Environment..........
Replacing Guardian Procedure Calls With Equivalent OSS Functions......................................160 Which IPC Mechanisms Can Be Used................................................................................160 Interactions Between Guardian and OSS Functions...............................................................161 9 Porting From Specific UNIX Systems..........................................................162 The UNIX Workstation Development Environment.................................
Compiling Native and TNS OSS Programs..........................................................................183 Interoperability of OSS and Guardian Sockets in an OSS Application.........................................184 12 Porting Threaded Applications from the Draft 4 Standard to the Standard POSIX Threads Library.........................................................................................186 Change in Error Reporting.......................................................................
Figures 1 2 3 Relationship of OSS to NonStop Operating System and Guardian Environment........................30 OSS and Guardian Interoperability....................................................................................53 Mixed-Module Programming Using the c89 Utility................................................................83 Tables 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 ISO/ANSI C Features Not Supported in Common C .........................................
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.
New and Changed Information This manual contains information about some of the following G-series development tools. If your server is running J06.03 or later J-series RVUs, these tools are supported. For servers running H-series RVUs, these tools are supported only in H06.
Revised information about shared memory in: • “Interprocess Communication Using OSS APIs ” (page 88) • “Interprocess Communication Using OSS and Guardian APIs ” (page 89) • “Using Shared Memory” (page 93) • “Using Shared Memory” (page 150) Added default-file-security information for processes to “Process-Identity Attributes ” (page 113).
Chapter 5: Interoperating Between Programming Environments Discusses interoperability between the Guardian and OSS programming environments. Interoperability is discussed with regard to header files, objects (files and processes), and mixed-module programming. Chapter 6: OSS Porting Considerations Discusses how to achieve equivalent behavior when porting applications to the OSS environment or writing new programs for the OSS environment.
Notation Conventions General Syntax Notation This list summarizes the notation conventions for syntax presentation in this manual. UPPERCASE LETTERS Uppercase letters indicate keywords and reserved words. Type these items exactly as shown. Items not enclosed in brackets are required. For example: MAXATTACH Italic Letters Italic letters, regardless of font, indicate variable items that you supply. Items not enclosed in brackets are required.
{ } 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 A vertical line separates alternatives in a horizontal list that is enclosed in brackets or braces.
Use the following standard documents when porting code to the OSS environment: • ISO/IEC 9899-1 C Programming Language Standard • ISO/IEC 9945-1 POSIX.1 Standard • ISO/IEC 9945-2 POSIX.
• SQL/MP Programming Manual for C. This manual documents the programming interface to HP NonStop SQL/MP for C. It is intended for application programmers who are embedding SQL statements and directives in a C program. It provides the information needed for use of an SQL/MP application from the OSS environment. • SQL/MP Programming Manual for COBOL85. This manual documents the programming interface to SQL/MP for COBOL.
the migration tasks involved in migrating G-series programs to the H-series environment. It is written for application programmers. • TNS/R Native Application Migration Guide. This guide introduces the TNS/R compilers and utilities and the native execution environment. It presents a strategy to migrate programs to the TNS/R native environment and describes the migration tasks. It is written for application and system programmers.
HP Encourages Your Comments HP encourages your comments concerning this document. We are committed to providing documentation that meets your needs. Send any errors found, suggestions for improvement, or compliments to: pubs.comments@hp.com Include the document title, part number, and any comment, error found, or suggestion for improvement you have concerning this document.
1 Introduction to Porting This chapter provides an introduction to porting applications to the HP NonStop Open System Services (OSS) environment; it contains these topics: • “Overview of Porting” (page 23) • “Overview of the OSS Environment” (page 28) Overview of Porting The 1. 2. 3. 4. porting process is simple: Clean up code; remove architectural dependencies and nonstandard practices. Compile code. Fix problems found at compile time. Fix segment faults and unaligned accesses.
• Local headers: define common data structures and symbols • Macros: defined here with comments to describe the macros. • File scope variables: those that are shared by several functions in the same file. • External variables: those defined in other modules but used in current module. • External functions: list external functions used by each module. • Structures and unions: define structures used in current file. • Signal catching functions: keep signal catching functions in this area.
• System data files that store information about a system • The data interchange formats used by the tar, cpio, and pax utilities POSIX.1 Conformance Open System Services supports all required application program interfaces defined within the 1990 edition of the POSIX.1 standard. OSS also supports some interfaces from later editions of the standard.
File Summit (LFS) submission, version 1.5 (March 20, 1996), and are supported on systems running G06.29 or later G-series RVUs, H06.06 or later H-series RVUs, and on J-series RVUs. • Functions that support OSS access control lists (ACLs) are based on the HP-UX implementation and Information Technology – Portable Operating System Interface (POSIX) – Part 1: System Application Program Interface (API) Amendment #: Protection, Audit, and Control Interfaces [C Language] (IEEE Draft P1003.1e), October 1997.
Table 1 ISO/ANSI C Features Not Supported in Common C (continued) Feature Type ISO/ANSI C Feature Keywords void, const, volatile, signed, and enum Operators Assignment operators -=, +=, and so on are treated as single tokens unary + added size of yields size_t instead of unsigned int & operator can always be applied to arrays & operator can never be used with an object declared as a register Strings List of \x escapes expanded Adjacent string literals are concatenated String constants can be placed i
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.
those statements and syntax rules set forth. Thus, an application written to these standards will run with little or no source-code change on all computer systems that support the same standards (once recompiled for the new machine). Open System Services has very strong UNIX roots with respect to function calls, user commands, and utilities. The X/Open CAE Specifications incorporate the POSIX.1 and POSIX.2 standards, among other guidelines.
Figure 1 Relationship of OSS to NonStop Operating System and Guardian Environment • 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
2 The Development Environment This chapter discusses different environments for developing or compiling C and C++ programs to run in the OSS environment. These environments include using cross compilers on the PC (used with the NonStop Development Environment for Eclipse NSDEE) or the HP Enterprise Toolkit-—NonStop Edition (ETK)) and using development tools directly in the OSS environment.
If you wish to migrate your TNS C or C++ source code to TNS/R native mode, refer to the TNS/R Native Application Migration Guide for issues related to migrating the code to TNS/R native mode. To migrate a TNS program to TNS/E native mode, you can first convert it to TNS/R native mode, then migrate the TNS/R native program to the TNS/E native environment.
Executable files created by the TNS/R native C compiler can run only on a TNS/R native system running D40.00 or later D-series RVUs; they cannot run on a TNS system, a TNS/R system running an RVU earlier than D40.00, or a TNS/E system. Executable files created by the TNS/E native C compiler can run only on a TNS/E native system running H06.01 or later H-series RVUs or a J-series RVU; they cannot run on a TNS system or on a TNS/R system.
For compilation 2 through 7, you can also cross-compile for the opposite environment; that is, generate a Guardian executable file from the OSS environment and vice versa. For compilation option 8, you cannot cross-compile for the opposite environment because the H-series and J-series OSS environments do not support TNS compilation and execution. Table 2 presents the cross-compile options available with PC compilers and HP compilers generating executable files for the OSS and Guardian environments.
• H-series TNS/E environment (Guardian only) • J-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.
Welcome to host_name.subdomain.domain.zone [PORT $ZTC0 #23 WINDOW $ZTN0A.#PTAAAE3] TELSERV - T9553H01 - (01OCT2004) Available Services: OSS TACL EXIT Enter Choice> Enter your choice after the prompt: >TACL Log on to the OSS system after the TACL prompt: TACL1> logon nih00.user Password: XXXXXXXX Execute the Guardian osh utility to start a Korn-compatible OSS shell: TACL2> osh Create a directory named samples: $ mkdir samples Note that the OSS shell prompt might not be $.
Using Archiving Utilities Archiving utilities can simplify movement of large numbers of files between systems. Open Systems Services supports tar, cpio, and pax (pax is the standard archiving utility in the OSS environment). tar and pax are discussed in the following subsections; cpio is not discussed in this guide because it is rarely used. The tar Utility The tar utility saves and restores data from traditional tar format archives.
Working on the NonStop System Here is a brief overview of the tools you can use when porting or developing programs on the NonStop system.
files and the run-time libraries, enabling you to compile programs compliant with ISO/ANSI C for either the OSS or Guardian environment. By default, if you run c99 in the OSS environment; it will produce executables for the OSS environment.
3. 4. 5. If the program is going to run in a TNS/R native environment, use the Accelerator program to optimize performance If the program is going to run in an H-series or J-series Guardian environment, use the Object Code Accelerator program to optimize performance If the program contains embedded SQL statements, use an SQL compiler as the final step TNS/R Native c89 Flags and TNS c89 Flags The c89 flags support compiling, linking, and optimizing and are used for setting compiler pragmas.
and c99 Files” (page 42); file locations are different between the native and TNS C compilation tools. For more information about compiling and linking files with c89 or c99, refer to the c89(1) or c99(1) online reference page or the Open System Services Shell and Utilities Reference Manual. Refer also to the C/C++ Programmer’s Guide.
File Locations for c89 and c99 Files The standard C and C++ header files, library files, and other files for native c89, c99, and TNS c89 are in different locations. Native c89 and c99 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. Native c89 and c99 Standard Library Directories For native environments, the linker searches a list of standard library directories.
c89 file.c -lc -Wcall_shared -WBstatic -l archive -WBdynamic -l native ld (if the target platform is TNS/R) or eld (if the target platform is TNS/E) performs dynamic linking by searching first for the file libc.so and then libc.a. ld or eld then performs static linking by searching for the file libarchive.a. ld or eld then performs dynamic linking by searching first for the file libnative.so and then libnative.a. • The following command compiles the source file mydll.
Editing OSS Files Using emacs Another editor available for the OSS environment is the emacs editor. This editor is not automatically installed in the OSS environment. Check your system to see whether the emacs editor is available. The emacs editor is a customizable, extensible, real-time display editor. Online documentation is provided with the emacs editor. Press Ctrl-H (Control key plus the H or h key) to display your options. These options describe information needed to use the emacs editor.
Inspect commands contained in the INSPLOCL file. You can also place Inspect commands in the Inspect custom file INSPCSTM in your default logon directory. Commands in INSPCSTM are also executed when an Inspect session begins. Commands in INSPCSTM override those in INSPLOCL because Inspect reads INSPCSTM after reading INSPLOCL. Native Inspect also provides a custom file in the default logon directory, named EINSCSTM.
The debugger that is started depends on the program type, as shown in the following table: Program Type Starts This Debugger TNS/R native non-PIC Visual Inspect if a matching client connection has been established, Inspect otherwise TNS/R native PIC Visual Inspect if a matching client connection has been established, Debug otherwise TNS/E native Visual Inspect if a matching client connection has been established, Native Inspect otherwise The following commands are entered from the OSS shell.
NOTE: You cannot use ld, eld, rld, nld, noft, or enoft on TNS or accelerated object files. You can display the following object file components with the noft and enoft utilities: • File headers • Program text and data • Symbol table and its component parts • Run-Time Data Units (RTDUs) The ld, eld, nld, noft, and, enoft utilities can be used in the Guardian or OSS environments.
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.
In addition to these checks, lint checks for the following programming faults: • Defined but unused variables and functions • Variables used before they are set • Functions that return unused values • Flow control: unreachable program portions, unlabeled statements, and endless loops • Strict type-checking: enumeration, function use, operator selection, and implied assignments • Nonportable character use, such as incompatible character ranges The most important messages lint returns involve the
general), and for maintainability. Further, there are rule files that check for good programming techniques and format: consistent braces, proper indentation, and ordering of file elements. You make your checking selections from the optional parameters and the library of rule profiles. CodeCheck’s options are available at the command line.
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. Code Coverage Tool The Code Coverage Tool is a utility program that you can use either to evaluate the code coverage provided by test cases or to understand what parts of an application are used, or most heavily used, under a representative workload.
4 Interoperating Between User Environments The Open System Services (OSS) shell and utilities let you 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.
Open System Services accomplishes interoperability between environments using standard function calls and HP extensions to these calls and to the Guardian procedures. Chapter 1 (page 23), discusses the relationships of the OSS and Guardian environments to the NonStop operating system. Figure 2 illustrates interoperability between the OSS and Guardian environments.
Guide for details about programming for the OSS and Guardian environments. Interoperability discussions in those guides include: • Interoperability between the OSS API and Guardian API (functions and macros in the OSS and Guardian C run-time libraries) • Manipulating OSS and Guardian objects • Writing mixed-module programs See also Chapter 5 (page 71), for various topics of interoperability between the OSS and Guardian environments.
• “Aliases and Functions” (page 56) • “stty Settings” (page 56) • “Line and History Editing” (page 56) Shell Start-Up Files The start-up procedure for the OSS shell is the same as the procedure for a UNIX Korn shell. If the shell is a login shell (the OSS shell is considered a login shell when the OSH utility is specified with the -ls option or with no options), the commands in the following start-up files are executed: /etc/profile (analogous to the /etc/.cshrc C shell file) $HOME/.
PSn Variable The PSn variables determine the prompts used by the OSS shell. n is either 1 or 2, specifying the primary or secondary prompt string. The default for PS1 is the dollar sign ($); the default for PS2 is the right angle bracket (>) followed by a blank space.
either by setting one of the vi, emacs, or gmacs options with the set command, or by setting the VISUAL or EDITOR variables. 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.
DEFINEs are automatically passed to the new Guardian process from its parent process when the new process is created.
In this example, the show_define command displays the values of the unnamed DEFINE set just created, and two add_define commands create the attributes unique to each DEFINE. The following table shows the values of the DEFINEs created in this example.
Managing Files From OSS In the OSS environment, several utilities provide file operations. In the Guardian environment, the File Utility Program (FUP) is used to provide this function. The 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.
Compiling and Linking Programs From OSS There are two native-mode C compilers: one runs in the OSS environment and one runs in the Guardian environment. Each compiler compiles OSS and Guardian programs and produces identical code. However, each compiler has different default pragma settings. Compiling and linking programs for the OSS environment is done using the c89 or the c99 utility, a compilation driver program.
ADD * FROM TEST2O SELECT SEARCH $SYSTEM.SYSTEM.CWIDE SELECT RUNNABLE OBJECT ON SELECT LIST * OFF SET HEAP 20 PAGES BUILD TESTER Refer to the C/C++ Programmer’s Guide for detailed information on compiling and binding programs in the OSS environment. Guardian Commands for the UNIX User This subsection is intended for UNIX users who may occasionally directly use Guardian commands to manipulate Guardian objects.
Use the Guardian STOP command to stop processes. The STOP command uses either the process name or the processor number and PIN combination to access the process. For example, the following two commands are equivalent: STOP $SRVR STOP 5,48 OSS utilities enhanced to access a Guardian process would specify /G/srvr or /G/5,48 for the previous commands.
rm /home/stu01/report ed /home/stu01/report r /G/DATA01/REPORTS/JAN94 w q In the second command line, /home/stu01/report is automatically created when starting the ed utility. The r command reads the Guardian file $DATA01.REPORTS.JAN94 into the ed workspace. When the w command is executed, the contents of the workspace are written to the /home/stu01/report file. The /home/stu01/report file is then in standard. The q command terminates ed.
To list process names associated with commands being executed, use the Guardian STATUS command for both OSS and Guardian process names. See “Guardian Commands for the UNIX User” (page 62) for a sample output of the Guardian STATUS command. To obtain the status of only OSS processes, use the OSS ps utility, discussed in “OSS Commands for the Guardian User” (page 59). OSS processes are identified by the program filename, with subvolume names beginning with ZYQ.
The two commands shown next redirect their output: the first to an OSS file, and the second to a Guardian file in the /G file system. The -nowait parameter is used to return control to the user immediately after the commands are initiated: osh -nowait -p /bin/ls /home/stu01 > /home/stu01/myfiles osh -nowait -p /bin/ls /home/stu01 > /G/DATA01/STU01/MYFILES In the following example, input is redirected from the Guardian file system (myfiles) with the left angle bracket.
The following examples present different ways of using the OSS gtacl utility. • The following command executes a single Guardian command: gtacl -c 'FUP SECURE $DATA01.REPORT.JAN94,"AOAO"' The single quotes (' ') are used to avoid any special processing of the $ and " characters by the shell. • The following command line executes the Guardian STATUS command and directs the output to the grep utility by using a pipe character (|).
Managing Guardian Processes From the OSS Shell The OSS ps utility displays information on OSS processes. Additionally, you can use the ps utility to display information on Guardian processes by using the -W parameter. The following shows different ways of using the ps utility for Guardian processes: ps -W all displays status of all Guardian processes. ps -W name=/G/SVR1 displays status of Guardian process $SVR1. ps -W cpu=5 displays status of all processes running in processor 5.
The setacl Utility For filesets that support OSS ACLs, use the setacl utility to change access control lists for an OSS file. For each file specified, the setacl utility does one of two things: • Replaces the entire ACL. • Adds, modifies, or deletes the specified ACL entries, including default entries for directories.
The pax Utility With the pax utility, you can specify Guardian files for archiving by using the /G syntax. Files with file types 0 and 180 are copied unmodified; files with file types 101 (EDIT files) are converted to ASCII text files that are compatible with OSS; all other Guardian files are ignored. Files restored in /G are given file type 0.
5 Interoperating Between Programming Environments This chapter is intended for users of the OSS and Guardian environments who need to understand interoperability between the two environments.
file descriptors of its parent and parameters from arguments put in its data resource at startup time. • The relationship between MOM and ancestor processes is indicated differently for Guardian processes than it is for OSS parent and child processes. These differences can create complications when a Guardian process-creation function is called from the OSS environment.
Use of Feature Test Macros The C compiler provides feature test macros, for example: _POSIX_SOURCE, _POSIX_C_SOURCE, _XOPEN_SOURCE, and _TANDEM_SOURCE. Sometimes options are also selected by macros. For example, _IGNORE_LOCALE is used in ctype.h to select C/POSIX locale macros rather than internationalized functions. Use of these macros determine whether a particular set of features will be included from header files. Feature test macros also enable you to check how well a program compiles.
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.
OSS processes have a full set of Guardian attributes as well as OSS attributes. Most Guardian process-management procedures can access OSS processes, and a small set of OSS process-management functions can access Guardian processes. The following subsections discuss these topics: • “Process-Creation Interoperability” (page 75) • “Process-Management Interoperability” (page 76) • “Process-Termination Interoperability” (page 77) Beginning with the H06.24 and J06.
The Guardian PROCESS_LAUNCH_ and PROCESS_SPAWN_ procedures obey the Guardian MOM and ancestor relationships, but the OSS functions obey the UNIX parent and child process relationships. See “Using Process-Creation Calls” (page 96) for a discussion of the UNIX parent and child process relationship. Guardian MOM and ancestors are notified of child termination using system messages on $RECEIVE. OSS parents are notified of child termination using the SIGCHLD signal and wait status.
tables in the Open System Services Programmer’s Guide for more information on using OSS functions for accessing Guardian processes. For specific information on a particular function, refer to the online reference pages, the Open System Services Library Calls Reference Manual or the Open System Services System Calls Reference Manual.
reading and writing of both even and odd byte counts and positioning to both even and odd byte addresses. Unstructured files do not have a built-in record structure. • EDIT files (file type 101). These files are unstructured. You can access them only for reading. • Telnet processes. Odd-unstructured files and EDIT files are opened as OSS regular files.
the AWAITIO[X] procedure. For details on using nowait I/O with Guardian procedures, refer to the Guardian Programmer’s Guide. The Open System Services Programmer’s Guide contains an example of using the AWAITIO[X] procedure to read an OSS file. Because Enscribe has long understood Guardian Format 2 files, a program running on a system that does not support large OSS files can use Enscribe APIs with 64-bit elections to open an OSS file that resides on a system that supports large files.
FUP RENAME TEMP,myfile • Protect the application by creating the file as a Guardian Format 1 file and then appending data to the file. For example, replace this command: cp myfile /G/disk/subvol/myfile With these commands: gtacl -c 'FUP CREATE $disk.subvol.
can also exercise control over another OSS process by sending a signal to it using the kill() function. A Guardian native process can use most of the signal functions in the OSS API to send, receive, and handle signals but only for the purpose of exercising control over itself. Guardian native process cannot send a signal to or receive a signal from another Guardian or OSS process using the kill() function.
Programmer’s Guide discusses accessing terminals from the OSS environment, including details on static and dynamic windows, terminal parameters, and control characters, where managing I/O is discussed. There is also a discussion of the OSSTTY facility. The OSS terminal interface is described in detail in the termios(4) and tty(7) reference pages, either online or in the Open System Services System Calls Reference Manual. Printer I/O The OSS API has no function that accesses printers or spoolers directly.
Figure 3 Mixed-Module Programming Using the c89 Utility You should always include all relevant headers in the source modules to ensure function references are resolved to the proper variant. Linking should be deferred until all object modules are created. In the OSS environment, linking can be initiated automatically for you by the c89 or the c99 utility, as discussed in Chapter 2 (page 31).
After deciding on the environment in which a program runs, choose a development environment. The development environment is the environment in which you compile, link, and optimize (or accelerate) the program. While you can develop a program in one environment that runs in the other environment, it is easier to develop a program in the environment in which will run. After choosing the development environment, you can begin writing the program.
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 chapter 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.
Standards Are Used” (page 24). When porting code that uses extensions, use functional equivalents from the POSIX standards to avoid propagating extensions to the OSS environment. Memory Mapping Mapped files provide a mechanism for a process to access files by directly incorporating file data into the address space of the process. After a file is mapped into a process address space, the data can be manipulated as memory. If more than one process maps a file, its contents are shared among them.
For additional information about Guardian segments, see the Managing Memory chapter in the Guardian Programmer’s Guide and the descriptions of SEGMENT_ALLOCATE_, SEGMENT_ALLOCATE64_, SEGMENT_DEALLOCATE_ and SEGMENT_RESIZE_ in the Guardian Procedure Calls Reference Manual. In addition to these techniques that employ existing memory-mapping techniques, there are others that do not actually map memory.
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.
1 Applies to both AF_UNIX Release 2 sockets and earlier AF_UNIX sockets. However, AF_UNIX Release 2 sockets must be of the same mode (compatibility mode or portability mode) to communicate with each other. For more information, see the Open System Services Programmer's Guide Table 7 lists the interprocess-communication methods available to an OSS process using both OSS and Guardian APIs, and the capabilities of each API relevant to communication between processors and nodes.
to its underlying operations. AF_INET and AF_INET6 sockets are the most widely used application program interface (API) for communication between processes running on different systems. AF_UNIX sockets are used for communication between processes running on the same system. The Guardian version of sockets was implemented for the versions of UNIX systems developed at the University of California, Berkeley, by the Berkeley Software Distribution (BSD) group.
There is no message-queue support between the Guardian and OSS environments with the OSS message-queue function calls. The services provided by message queues also can be provided using other OSS IPC mechanisms that are generally available on all UNIX systems. The following IPC mechanisms can be used if you need to modify your application program to provide the equivalent feature: pipes, FIFOs, and OSS sockets.
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. This interaction involves copying information between pipe buffers across processors, thereby using more system resources. If the child process is created in another processor, all pipe I/O by the child processes is handled by the processor in which the parent process is running.
Using Signals OSS signal functions can be used with TNS/R and TNS/E native Guardian processes but not with TNS processes. Refer to the Open System Services Programmer’s Guide for more information. Using Shared Memory Shared memory segments enable processes to communicate directly with each other by sharing portions of each other’s address space in a single processor. Shared memory does not simply provide common access to data, it provides the fastest possible communication between processes.
OSS semaphores are created and controlled with the semctl(), semget(), or semop() function calls. OSS semaphores can be listed and deleted using the ipcs and ipcrm utilities (refer to the semctl(2), semget(2), and semop(2) reference pages either online or in the Open System Services System Calls Reference Manual and to the ipcs(1) and ipcrm(1) reference pages either online or in the Open System Services Shell and Utilities Reference Manual for more information).
storage class specifier.) Both global and static aggregates have storage class static, which means that they retain their values throughout the execution of the entire program. The main stack of a native process can grow in size dynamically, up to a default or specified limit. By default that limit is 1 megabyte (MB) on TNS/R systems or 2 MB on TNS/E systems; on both platforms you can specify a limit of up to 32 MB.
POSIX standards as much as possible. If your program can use a standard set of interfaces, follow the XPG4 specifications because most UNIX platforms conform to them. If performance is a priority, consider the changes discussed under “Using Interprocess Communication (IPC) Mechanisms” (page 88). Then consider using some of the HP extensions, which take advantage of the NonStop system architecture. For example, you can use almost all the Guardian procedure calls in your C program in the OSS environment.
Using fork() and the exec Set of Functions in OSS In the OSS environment, you can use fork() and the exec set of functions as you would in the UNIX environment, or you can use comparable versions of these functions that are HP extensions: tdm_fork() and the tdm_execve set of functions. The OSS process-creation functions are similar to their UNIX counterparts, except that creating processes in the OSS environment also gives the processes Guardian attributes.
and pr_results) for modifying Guardian attributes as described for tdm_fork() and the tdm_exec set of functions. You can use the tdm_spawn set of functions to create a process in another processor, and it is generally more efficient than the combined use of tdm_fork() and the tdm_execve set of functions.
• • • • ◦ More features than the tdm_spawn set of functions: see online reference pages ◦ More flexible than the fork() function and the exec set because you can change process attributes ◦ File opens are propagated to the child process ◦ Less efficient when creating many processes ◦ Supports specifying maximum heap and main stack values tdm_spawn set of functions ◦ Flexibility to change process attributes ◦ Efficient when creating many processes ◦ Creates a process on another processor e
is ignored. In the OSS implementation, when a child process exits and SIGCHLD is ignored, the child process is transformed 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.
Extra Steps for Creating Files The extra steps for opening OSS files involve the pathnames translation performed by the OSS name server. The catalog accessed is an Enscribe database describing the files in the fileset. Each OSS fileset has a catalog. For the OSS fileset, each OSS file has an entry in a catalog, as does each filename. Creating a file involves a few more steps than opening an existing OSS file.
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 Similar to a hard link, a symbolic link allows a file to have multiple logical names. The file named in a symbolic link actually contains the name of the file that contains the data. A symbolic link permits links across file systems. Symbolic links are implemented in the OSS environment, but only for OSS pathnames. You cannot create symbolic links in the /G directory. The OSS functions supporting symbolic links include symlink(), readlink(), lchmod(), lchown(), lstat(), and lstat64().
In the client and server model, communication takes the form of request and reply pairs, which are initiated by the client and serviced by the server. For example, servers support Internet services such as FTP, TELNET, SMTP, and so on. This subsection focuses on how using static servers and demon processes can improve system performance in the OSS environment. A dynamic server is a server process created by an application or super server to handle a new request as it comes in.
Careful Programming With Static Servers When dynamic servers are used, a programmer can be careless about how memory is deallocated and files are closed after a request is handled because dynamic servers are terminated after handling the request. Because static servers are not terminated after a request is handled, more careful accounting for resource use by the server program is required. If memory is not released after its use (creating memory leaks) a process can grow to be very large.
Applications using an inetd type of service to start servers can generally be ported to the OSS environment with minimal changes. However, you can use the Guardian procedure PROCESS_SPAWN_ to start OSS processes; see “Starting an OSS Server Process” (page 106). Starting a Guardian Server Process Typically, a client program is started by an application user at a terminal.
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.
• “HP Extensions” (page 110) • “Programming for Portability” (page 110) Scope of Portability Scope of portability refers to the number of target platforms on which the program currently runs or will run. To ensure that the program stays portable to the UNIX environment from which you are porting, you must make sure that you do not use extensions specific to HP, if possible. If the UNIX program uses only standard POSIX and ISO/ANSI C functions, keeping the program portable will be easier.
using the proper set of tools, you can identify the areas that need the most attention in performing the port: • The lint program, found on most UNIX systems, finds bad constructs in C programs. It identifies variables used before they are set, unreachable program segments, and functions that return unused values. • A findcalls tool performs a simple lexical analysis of C source code by searching for the use of function calls.
need to be rewritten to use a standard function, one close to the original functionality. This requirement is particularly true for old Berkeley Software Development (BSD) and System V Release 4 UNIX (SVR4) programs that use nonstandard functions. See “Using Functional Equivalents” (page 111) for further details. Single-Processor Versus Multiprocessor Systems Most UNIX programs today are written to run on a single-processor architecture.
Using Functional Equivalents The fewer nonstandard functions used by a program, the more portable it is. A program becomes increasingly more difficult to port to multiple environments as it uses functions in more of the categories in the order listed below: • ISO/ANSI C • POSIX.1 • POSIX.
Table 8 Functions Currently Not in the OSS Environment (continued) Function Replacement Recommendation vfork() Use fork(). vhangup() Use tcsetattr(). wait3() Use waitpid(). Differences Between OSS and UNIX Environments The OSS functions available to programmers conform to the POSIX.1 and POSIX.2 standards and to the XPG4 specifications. The OSS functions coexist on NonStop systems with the traditional Guardian interfaces, which a programmer can also use from an OSS program.
OSS processes have a full set of Guardian attributes, typically associated with Guardian processes. Guardian processes have some OSS attributes; OSS processes have an additional set of attributes specific to OSS that are not associated with Guardian processes. A small set of OSS process-management functions can access Guardian processes. You can create OSS processes with the fork() function and run programs with the exec set of functions.
File Attributes and Access OSS files have different attributes than Guardian disk files. For example, the file protection bits, the file owner ID, and the group ID are stored differently for OSS files than for Guardian disk files. Guardian files are protected by a 12-bit security vector and optionally by the Safeguard Access Control Lists (ACLs). The Safeguard ACLs are associated with Guardian files.
entries is denied. This behavior matches the behavior for G-series RVUs, H06.19 and earlier H-series RVUs, and J06.08 and earlier J-series RVUs. For information about the NFSPERMMAP attribute for OSS filesets, see the Open System Services Management and Operations Guide. For a detailed description of OSS ACLs, including examples, see the acl(5) reference page either online or in the Miscellaneous Topics section of the Open System Services System Calls Reference Manual. On systems running J06.
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.
global (static) or local (automatic) variables to dynamic objects allocated from the heap or in separate user-allocated segments. Function Prototypes The ISO/ANSI C innovation of function prototypes is one of the more important features added to the C language. Using proper function prototypes in header files ensures that the invocation of a function from a program is compatible with the formal definition of the function in terms of numbers and types of arguments, and the type of the return value.
The contents of the header files in the OSS environment in /usr/include are identical to the contents of the header files in the Guardian environment in $SYSTEM.SYSTEM. These files support the OSS and the Guardian environments. The system entry points are different for the same external run-time routine for each of the memory and data models. (For more information about memory and data models, see “Memory and Data Models in TNS and Native Environments” (page 140).
_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 or c99-Wsystype=oss flag. _IGNORE_LOCALE When defined, macros that support only the C/POSIX locale are selected, instead of internationalized functions that support multiple locales. The macro _IGNORE_LOCALE affects functions in the ctype.h header file. NOTE: Beginning with the H06.24 and J06.
OSS environment doesn’t exceed the guaranteed limits, it should successfully compile with the NonStop C compiler. C Data Types The integral data types and the floating point data types supported in the C compilation environments are specified in limits.h and float.h header files, respectively. Beginning with the H06.24 and J06.13 RVUs, both the ILP32 and LP64 data models are supported by the NonStop C/C++ compilers.
OPEN_MAX Maximum number of files that one process can have open at one time STREAM_MAX Maximum number of streams that one process can have open at one time 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 i
OSS programs are CRE-compliant. You can call explicitly many CRE library functions from both OSS and Guardian modules.
opendir() readdir() remove() rename_oss() rmdir() setfilepriv() unlink() utime() For more information about restricted-access filesets and file privileges, see the Open System Services Management and Operations Guide. Using the access() Function For the access() function call, the behavior on OSS files is defined by the POSIX.1 standard with minor implementation-defined behavior. When the filename resolves to the /G directory, the permissions are “r-xr-xr-x.
file. However, processes that have an effective user ID equal to the file owner can only change the group of a file to a group to which they belong (their effective group or one of their supplementary groups). For files in restricted-access filesets, a process started by a member of the Safeguard SECURITY-OSS-ADMINISTRATOR (SOA) group has the appropriate privilege to use this function on any file in the restricted-access fileset.
When you use mkdir() for directories within the Guardian file system, the owner ID is set to 65535 (the group ID is set to 255), and the permission bits are set to “rwxrwxrwx.” Only Guardian subvolumes can be created within the Guardian file system; mkdir() cannot create a Guardian node, volume, or file. Using the mknod() Function The mknod() function can be used to create a new OSS file that is a FIFO, character-special, directory, or regular file.
See also “Special Considerations for Files in Restricted-Access Filesets” (page 122). Using the rename() and rmdir() Functions The rename() and rmdir() function calls are not allowed on /G, /dev, /dev/tty, /dev/null, or /lost+found in the root directory of an OSS fileset.
For systems running AF_UNIX Release 2 software, calls to the OSS sockets functions for AF_UNIX connections can use an alternate transport-provider name to specify the semantics to use: • Using the $ZPLS transport-provider name specifies that compatibility mode be used. Compatibility mode sockets have the same characteristics and behavior as AF_UNIX Release 1 software semantics.
Beginning with the H06.24 and J06.13 RVUs, 64-bit OSS processes are supported and can be created by OSS and native Guardian processes. For information about 64-bit OSS processes, see the 64-Bit Support in OSS and Guardian chapter in the Open System Services Programmer's Guide. Using the fork() and exec Set of Functions The standard POSIX.1 fork() function and exec set of functions are implemented in the OSS environment. In addition to the normal POSIX.
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 current directory of the terminated program if possible.
regular files, sockets, FIFOs, and OSSTTY (terminal process must be running on a system running G06.27 and later G-series RVUs, H06.06 and later H-series RVUs, or J-series RVUs). FILE_COMPLETE_GETINFO_ Provides information about the set of files that are enabled for completion. Supports Guardian files, OSS regular files, sockets, FIFOs, and OSSTTY (terminal process must be running on a system running G06.27 and later G-series RVUs, H06.06 and later H-series RVUs, or J-series RVUs).
and OSS process attributes can be specified when the new process is created or the new program is executed. tdm_fork() and the tdm_exec set of functions use the same parameters as fork() and the exec set of functions, respectively, plus two new parameters. The first new parameter is a pointer to an input structure, containing Guardian process attributes to assign to the new process. The input structure is defined in the tdmext.h header file, including default initialization values for this structure.
#include #include _cc_status CC; ... retcode = FILE_OPEN_(pathname, , &filenum, 1, , , , 040); ... CC = READX(filenum, buffer, 1024); if (_status_eq(CC)) { ... } else ... The syntax of a Guardian procedure call determines whether a parameter is required or optional. Refer to the Guardian Procedure Calls Reference Manual and the Guardian Programmer’s Guide for more information on using Guardian procedures.
ftruncate64() lseek64() fcntl() fstat64() lstat64() stat64() fstatvfs64() statvfs64() readdir64() ftw64() nftw64() glob() The large file aware native C runtime library APIs are: __ns_backup_fopen64() __ns_fopen64_special() fgetpos64() fopen64() fopen64_guardian() fopen64_oss() fopen64_std_file() freopen64() freopen64_guardian() freopen64_oss() fseeko64() fsetpos64() ftello64() scandir64() tmpfile64() tmpfile64_guardian() tmpfile64_oss() The native C++ runtime libraries do not have new 64-bit specific APIs i
getacl Lists access control list entries for a file. setacl Modifies the access control list for a file. For a detailed description of OSS ACLs and their use, see the Open System Services Programmer’s Guide. Other Extension Functions In addition to the functions listed earlier in this chapter, HP supports other functions that are extensions to the XPG4 specification. Examples include the lchmod() function, the setfilepriv() function, and functions that support Standard POSIX Threads.
localeconv(3) reference pages either online or in the Open System Services Library Calls Reference Manual. Locales in OSS Client/Server Applications For homogeneous client/server applications in the OSS environment, Open System Services provides the setlocale_from_msg() function to enable a server to receive a client’s locale information, along with messages from $RECEIVE.
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.
In deciding the degree of migration, you must consider the general issues discussed in the following subsections: • “TNS to TNS/R or TNS/E Native Migration” (page 137) • “Migration Options” (page 137) • “Converting TAL or pTAL Code to C or C++” (page 138) • “Using New and Extended Guardian Procedures in Guardian Programs” (page 138) • “Using OSS Functions in a Guardian Program” (page 138) • “Communicating With OSS Programs” (page 138) • “Migrating a Guardian Program to the OSS Environment” (pag
In some cases, interprocess communication features can be added to a Guardian application to set up communication channels with OSS applications. To make your Guardian application as open as possible, and, therefore, in a position to access new open facilities as they are introduced, you can migrate your application to run in the OSS environment. The next few subsections introduce various aspects of migrating your Guardian application.
requires considerations about security mechanisms, use of filenames, recompiling the application, use of certain commands and statements, and so forth. Refer to the SQL/MP Programming Manual for C or the SQL/MX Programming Manual for C and COBOL for more information about SQL/MP or SQL/MX applications in the OSS environment. C Compiler Issues for Guardian Programs The Guardian C or C++ programmer has typically used the TNS compiler tools available in the Guardian environment to build TNS programs.
• On J-series or H-series systems, the Visual Inspect debugger can be used to debug 32-bit programs compiled with the Guardian TNS or TNS/E native compilation components and with the OSS TNS/E native compilation components. • On J-series or 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 a J-series or H-series system.
header files are in /usr/include and its subdirectories by default. Because the OSS C compiler requires that header files use the OSS pathname syntax, all header files must be specified in this syntax. All uses of #include preprocessor directives in the Guardian C source program must be modified, if necessary, to use the OSS pathname syntax. Simple file names like stdio.h are correct in both environments, but names traditionally containing relative paths are condensed into a single Guardian name.
Binding TNS Programs In the Guardian environment, Binder is used to bind the specified object files with any libraries referenced into an executable program. The Guardian C run-time library routines are searched for in the $SYSTEM.SYSTEM.CWIDE library file. The TNS Guardian C run-time library routines that are bound into a Guardian program by the Binder can be found in /nonnative/usr/lib/libgwc.a. This file is equivalent to the Guardian file $SYSTEM.SYSTEM.CWIDE.
Table 11 Common Guardian Compiler Tasks and How Similar Tasks Are Achieved in the OSS Environment (continued) Guardian TNS Environment Equivalent OSS Action Action OSS Native c89 Flags to Use OSS c99 Flags to Use Run the SQL/MP compiler Invoke the SQL/MP -Wsqlcomp=args compiler by running the c89 utility with the -Wsqlcomp flag Not supported Run the SQL/MX compiler Invoke the SQL/MX -Wmxcmp=args compiler by running the c89 utility with the -Wmxcmp flag -Wmxcmp=args Compile Guardian module Specify t
The GROUP_GETINFO_ procedure retrieves information about a group specified either by group name or by group ID. A textual description of the group and information as to whether the group is automatically deleted when the last member is deleted can be obtained using this procedure. The GROUPMEMBER_GETNEXT_ procedure retrieves a user name or alias associated with a group ID. All user names and aliases associated with a group ID can be obtained with successive calls of the procedure.
The FILE_COMPLETE_ procedure and its companion procedures, FILE_COMPLETE_SET_ and FILE_COMPLETE_GETINFO_, provide additional capabilities for programs that use nowait I/O. They combine and enhance the function of the AWAITIO[X] procedures and the OSS select() function. For example, you can use these procedures to complete nowait I/O on OSS files in parallel with nowait I/O on Guardian files.
Procedure Description PROCESS_SUSPEND_ Places process into suspended state PROCESSHANDLE_*_ [Various process handle procedure calls] PROCESSNAME_CREATE_ Creates unique process name SETLOOPTIMER Sets caller's process loop-timer value When PROCESS_ACTIVATE_ and PROCESS_STOP_ are used on a target OSS process, they are equivalent to kill(pid, SIGCONT) and kill(pid, SIGSTOP) respectively, including the delivery of the SIGCHLD signal to the parent process.
• “Language or C Environment Type” (page 148) • “API Interoperability” (page 148) • “Side Effects” (page 149) Memory and Data Models to Be Used The C language supports three combinations of memory and data models (small, large, wide), varying in the width of an integer, in the width of a pointer, and in various combinations thereof. OSS functions support only the wide-data model (int is 32 bits).
not expect these opposite-environment functions to perform exactly as they would within same-environment processes or on same-environment objects. The syntax of the calling sequence can be different for opposite-environment functions. The semantics is usually also different: for example, Guardian fopen() expects a Guardian filename, and OSS fopen() expects an OSS pathname. These environment-specific functions are fopen(), fclose(), freopen(), rename(), remove(), tmpfile(), and tmpnam().
Side Effects When a Guardian process starts to use OSS services, it may observe several side effects, depending on the procedure used: • Two file numbers are allocated, but not necessarily the next available two numbers, for use as the root and current working directories. Once allocated, these files cannot be closed by calling FILE_CLOSE_. • A current working directory is assigned based on the current value of the VOLUME attribute of the =_DEFAULTS DEFINE.
The process acting as the requester must use the FILE_OPEN_ procedure to open a communication channel to the named server process.
accessing 64-bit addressable memory, see the 64-Bit Support in OSS and Guardian chapter in the Open System Services Programmer's Guide. On servers running J06.12 or later J-series RVUs or H06.23 or later H-series RVUs, both Guardian processes and OSS processes can call the OSS shared memory functions, which are shmat(), shmctl(), shmdt(), and shmget(). They can share segments as described for shmget(). On servers running J06.11 or earlier J-series RVUs, H06.
Starting an OSS Program From the Guardian Environment Migration from the Guardian environment to the OSS environment can involve the ability to start an OSS program from the Guardian environment, which you can do either using commands or programmatically, as described in the following subsections: • “Using OSH From TACL” (page 152) • “Using system() in a Guardian Program” (page 152) • “Using PROCESS_SPAWN_ in a Guardian Program” (page 152) • “Using the Guardian LISTNER Program” (page 154) Using OSH
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. A new OSS process is created optionally with an assigned name, with the caller becoming the Guardian parent of the OSS child process. The caller will be notified of child process termination through a system message on $RECEIVE, not through an OSS SIGCHLD signal. DEFINEs can be propagated to the new process.
Example 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. */ #include #include #include #include
process created by the LISTNER is passed one command line parameter (port number and Internet address) from the PORTCONF configuration file. The parameter is then passed to the OSS server program created by the Guardian program. For example, if a service request is received on port 4321 from the Internet address 130.252.3.234, the parameter ultimately passed to the OSS server program would be 4321.130.252.3.234.
In the OSS environment, all of the compilation, linking, and optimization steps required to build the final executables are specified in a make file. The make file, used by the make utility, contains a list of dependencies for each target to be built. When migrating Guardian programs written in C or C++ to the OSS environment, you are encouraged to use the set of tools available in the OSS environment to build, test, and debug your application.
SSV Specifies list of search subvolumes for files in #include directives NOXMEM Gives an error; all OSS programs are wide model These pragmas can be removed from the C or C++ source files if the source files are to be compiled in the OSS environment. Feature Test Macros Feature test macros control the visibility of symbols. They determine which set of features is included in header files. The following feature test macros can be used in the OSS environment.
The TNS c89 utility looks for a file with the .so suffix (for example, libc.so) instead of a file with the .srl suffix. 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.
The startup procedures are somewhat different in the OSS environment. The standard files are controlled by the OSS file system, not the CRE. Also, because OSS processes do not use startup messages, information is passed to a new OSS process mainly by use of program arguments and environment variables. These differences must be taken into consideration when migrating a Guardian program to the OSS environment.
In cases where the Guardian routines have no equivalents in the OSS environment, you have two options. The first is to compile the module containing the Guardian C run-time routine as a Guardian module; the second is to replace the module with an equivalent module. The second option will make the program more portable to other open systems environments. You should refer to the C/C++ Programmer’s Guide for more details on which C run-time routines work in which environment.
queue files can be used in the OSS environment in the same manner as they are used in the Guardian environment. The use of OSS shared memory and OSS semaphores is encouraged when communicating between two OSS processes, but flat segments can be shared between OSS and Guardian processes using Guardian procedure calls as well.
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” (page 162) • “C Compilation on a Workstation” (page 166) • “Resolving the Endian Problem” (page 168) The UNIX Workstation Development Environment Your UNIX workstation environment should be XPG4 compliant.
Development Tools Typical C program development tools found on many UNIX workstations are discussed in the following subsections: • “C Program Analysis Tools” (page 163) • “Program Management Tools” (page 163) • “C Source Code Utilities” (page 164) • “Object File Utilities” (page 164) • “Linkable Library Routines” (page 165) • “Standard and Alternate Library Directories” (page 165) • “Implementor-Defined Values” (page 166) C Program Analysis Tools The following C program analysis tools might b
• The Source Code Control System (SCCS) is used to manage source code. SCCS was developed by AT&T and comes with SVR3 and SVR4 UNIX systems and with SunOS systems. SCCS is not provided as part of the OSS environment. • The Revision Control System (RCS) is used to manage source code. RCS was created at Purdue University; it is available from the public domain, distributed by the Free Software Foundation, Inc. under the GNU license. It is also available on some SunOS systems.
OSS environment. More information about using size is available in the size(1) online reference page; size is not available in the OSS environment. • 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.
The object modules in the OSS versions of the standard C library include the system calls and the standard run-time routines provided by many UNIX systems. The standard C library is searched by default when the C compiler invokes the nld, ld, or eld linker to build an executable program; when you invoke nld, ld, or eld directly, you must explicitly specify the standard C library.
These macros are also available with the HP C compiler. Program behavior dependent on these macros should be portable. • These preprocessor-defined macros: sparc sun sun4 unix These macros are not available with the HP C compiler. The equivalent behavior can be created by using #ifdef in your header files.
Resolving the Endian Problem The term “endian” refers to the order in which a computer numbers and stores its bytes.
if((my_var.int_val & 0xff) == 0) printf("The number is divisible by 256\n"); 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.ul[1] = 0xffffffff; To produce the correct results on a big-endian system, the subscripts must be reversed: u.
10 Native Migration Overview This chapter 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.
and C, is not supported in pTAL. No embedded SQL can be included in a user library, which is a dynamic-link library (for PIC programs) or a shared run-time library (for non-PIC programs). A TNS/R native C and C++ migration tool aids the programmer in migrating an application from a TNS environment to a TNS/R native environment. This tool is discussed in the TNS/R Native Application Migration Guide.
system-managed swap files for native processes. The space guarantee attribute (pe_space_guarantee) of a process can be used by KMSF to reserve space in system swap files. If the requested space is not available at process creation, an error is returned and the process is not started. Native Shared Run-Time Libraries Native shared run-time libraries (SRLs) are supported in the TNS/R native environment. TNS/R native programs can use multiple public SRLs.
the c89 utility (or the c99 utility, if applicable), link object files using the nld, ld, or eld utility, and use the SQL/MP compiler on the resulting object file or the SQL/MX compiler on the resulting module definition file (if necessary). The native C compilers accept ISO/ANSI C as well as Common C. The native C++ compilers have more features than the TNS C++ preprocessor, such as forward declarations of class specializations and nested templates, and make it easier to debug code.
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. The memory architecture and implementation of native user libraries differs from TNS user libraries, but these differences do not affect the restrictions on and capabilities of user libraries.
6. There are changes in data alignment with the use of values for the FIELDALIGN pragma, such as auto, cshared2, and shared2 in the native C compilers, from their use in the TNS C compilers. Native C or C++ programs that share data structures with TNS C or C++ programs might require the use of the CSHARED2 pragma. Native programs that share data structures with TAL programs or Guardian API structures might require the use of the SHARED2 pragma.
By using the tal.h header file for native programs, the above equivalent code can be used for TNS and accelerated programs. In the same manner, _status_eq would be used instead of CCE, and _status_lt would be used instead of CCL.
Some Guardian procedure calls have been replaced in the native environment: • 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 chapter discusses the following topics: • “Porting UNIX Sockets Applications to the OSS Environment” (page 178) • “Porting Guardian Sockets Applications to the OSS Environment” (page 180) • “Interoperability of OSS and Guardian Sockets in an OSS Application” (page 184) Porting UNIX Sockets Applications to the OSS Environment The following topics are discussed in this subsection: • “General Considerations” (page 178) • “Differences Between OSS Socket
NOTE: Although the names $ZPLS and $ZAFN2 are used as transport-provider names, neither of these are processes that run on the system. For more information about AF_UNIX Release 2 software and sockets, see the Open System Services Programmer's Guide. • The OSS ioctl() function does not conform to a published standard. Refer to the ioctl(2) reference page either online or in the Open System Services System Calls Reference Manual for a description of its capabilities. • Beginning with the H06.24 and J06.
• OSS sockets support capture of the SIGURG signal. BSD sockets support capture of the SIGURG and SIGIO signals. In the OSS environment, the SIGURG signal is enabled by using the fcntl() function to invoke the F_SETOWN command. In a BSD environment, SIGURG is enabled using the fcntl() function to invoke the FASYNC command.
General Considerations The following is a list of general considerations for porting a sockets program from the Guardian environment to the OSS environment: • Guardian C programs can use 32-bit or 16-bit integers. OSS C programs use only 32-bit integers. Most sockets routine arguments are of type int.
Table 12 Sockets Header Filenames (continued) Guardian Header Filename (in $SYSTEM.ZTCPIP) OSS Header Filename (in /usr/include) NETDBH ROUTEH SOCKETH TYPESH • In the Guardian environment, the LISTNER process must be used to activate servers. The OSS environment supports the use of inetd to spawn server processes. LISTNER cannot directly activate OSS programs.
Refer to the requester2 sample program in the Open System Services Programmer’s Guide for a blocking sockets application. – You can modify the application to use blocking sockets in a nonblocking manner.
/nonnative/usr/c89 -o nnsock nnsock.c -l inet -l c -D _XOPEN_SOURCE_EXTENDED = 1 -D _TANDEM_SOURCE See the C/C++ Programmer’s Guide and the nld Manual, the ld Manual, or the eld Manual for more information on compiling and linking native C and C++ programs.
Table 14 Additional Internet Domain Support Functions (continued) Function Description getprotobyname() Gets the protocol number of the specified protocol name getprotobynumber() Gets the protocol name of the specified protocol number getservbyname() Gets the service port number for the specified port name getservbyport() Gets the service name of the specified port number host_file_gethostbyaddr() Gets the name of the host with the specified Internet address host_file_gethostbyname() Gets the I
12 Porting Threaded Applications from the Draft 4 Standard to the Standard POSIX Threads Library This chapter summarizes the information you need to port existing threaded applications from the Draft 4 to the Standard POSIX Threads library (T1248). In particular, this chapter summarizes considerations for porting HP NonStop Distributed Computing Environment (DCE) Threads applications, and gives pointers to sources of detailed information.
Considerations for Porting DCE Threads to Standard POSIX Threads To port applications that use DCE Threads (T8403) or DCE Threads on Java (T5819) to Standard POSIX Threads, see the following sources of information: • • Pthreads Programming, Bradford Nichols, Dick Buttlar, and Jacqueline Proulx Farrell, O'Reilly & Associates, 1998, 270 pp.
13 Porting Threaded Applications to the POSIX User Thread (PUT) Model library The POSIX User Model Thread library is a user-space implementation of IEEE Std 1003.1, 2004, POSIX System Application Program Interface for use by native C and C++ TNS/E-targeted applications in the OSS environment on NonStop servers. This library is supported on systems running H06.21 and later H-series RVUs and J06.10 and later J-series RVUs. It is described in detail in the Open System Services Programmer's Guide.
routines provided by HP also reduces portability of a threaded application; see the Open System Services Programmer's Guide for more information about the jacket routines.
14 Porting Applications to Support Large OSS Files This chapter describes changing an application to support OSS files larger than approximately 2 gigabytes on systems running G06.29 and later G-series RVUs, H06.06 and later H-series RVUs, and J-series RVUs. For RVUs earlier than H06.06 and G06.29, OSS files always had an underlying Guardian file format of Format 1 and were limited in size to approximately 2 gigabytes.
For the near future HP expects that large files will be rare instead of commonplace, so the OSS implementation of large file support: • Ensures that existing applications, without modification, can continue to support small files. • Enables you to either choose a compilation environment that allows you to use the standard POSIX APIs in your code to ease future portability or to choose a compilation environment that allows you to explicitly call the 64-bit large file aware function calls.
Advantages to choosing the transitional compilation environment include: • Clean up of code can be confined to the routines that handle large files. • Because the 64-bit APIs can use different data types and structures than the 32-bit versions, calling the 64-bit APIs explicitly can result in code that is easier to debug. • If handling large files is the exception, you might not have to examine or change as much of the application code.
• Precision is lost in shifting. For example, this existing code fragment assumes that off_t is the same size as int: off_t offset; int blkno; offset = blkno << BLOCK_SHIFT; In the large file compilation environment, the codes should be as follows: off_t offset; int blkno; offset = (off_t)blkno << BLOCK_SHIFT; Typecasting blkno forces its promotion to a 64-bit value before the shift takes place.
Example 2 Sample Portable fseek() and ftell() Conversion Code Fragment /** begin code fragment **/ movepos(fd) FILE *fd; { int rslt; /** If ((TNS/R and G06.29 or later) or **/ /** (TNS/E and H06.
Example 3 Program Before Converting to Support Large Files #include #include #include #include
Example 4 Program Converted For a Transitional Compilation Environment #include #include #include #include #define _LARGEFILE64_SOURCE 1 /** You can specify this macro as a comiler option **/ /** instead of including it in the source code.
option instead of in the source code. The source has no assumptions about whether off_t is larger or smaller than an int. Example 5 Program Converted For a Large File Compilation Environment #include #include #include #include #define _FILE_OFFSET_BITS 64 /** You can specify this macro as a comiler option **/ /** instead of including it in the source code.
A Equivalent OSS and UNIX Commands for Guardian Users Table 15 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 15 Equivalent OSS and UNIX Commands for Guardian Users (continued) Guardian Command Description OSS and UNIX Commands HISTORY Displays previously issued commands fc HOME Specifies where command interpreter looks env for VARs INFO DEFINE Displays attributes of current command interpreter process info_define1 INSPECT High-level debugger run -debug, runv1 LOAD Loads a library file into memory LOGOFF Log off system MEDIACOM Manages labeled tapes PARAM Parameter to process at creation
Table 15 Equivalent OSS and UNIX Commands for Guardian Users (continued) Guardian Command Description OSS and UNIX Commands TEDIT Full-screen editor vi TFORM, TGAL Simple text formatter TIME Displays date and time USE Defines search list to find existing variables USERS Displays attributes of users and groups logname, who, id, env, umask VOLUME Temporarily changes your default volume, subvol, security cd, chmod VPROC Displays product version information vproc1 WAKEUP Sets TACL wakeup m
B Equivalent Guardian Commands for OSS and UNIX Users Table 16 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 16 Equivalent Guardian Commands for OSS and UNIX Users (continued) OSS and UNIX Command Description Guardian Commands or TACL Macros env Sets environment for command invocation ENV, SET expand Converts tabs to spaces expr Evaluates arguments as expressions #ARGUMENT fc Processes command history list FC, HISTORY, !,? fg Runs jobs in the foreground RUN file Determines file type FILEINFO, FUP INFO find Finds files FILES, FILEINFO, FILENAMES fold Filter for folding lines gencat G
Table 16 Equivalent Guardian Commands for OSS and UNIX Users (continued) OSS and UNIX Command Description nohup Invokes a utility immune to hangups od Dumps files in various formats paste Merges corresponding or subsequent lines of files pathck Checks pathnames pax Portable archive interchange BACKUP and RESTORE pr Prints files FUP COPY printf Writes formatted output #output ps Prints process status STATUS, PPD pwd Returns working directory name #defaults rm Removes directory entri
Table 16 Equivalent Guardian Commands for OSS and UNIX Users (continued) OSS and UNIX Command Description wait Awaits process completion 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 1 Guardian Commands or TACL Macros USERS, STATUS OSS command only. Bracketed [ ] information indicates a series of command steps.
C Standard POSIX Thread Functions: Differences Between the Draft 4 and IEEE 1003.1c 1995 Standards This appendix describes the differences between the Draft 4 standard and IEEE 1003.1c standard, 1995, as implemented in the Standard POSIX Threads library (T1248).
Table 17 Replaced or Renamed Thread Functions Draft 4 Thread Function Replacement or Renamed Standard POSIX Threads Function pthread_attr_create() pthread_attr_init() pthread_attr_delete() pthread_attr_destroy() pthread_attr_getdetach_np() pthread_attr_getdetachstate() pthread_attr_getprio() pthread_attr_getschedparam() pthread_attr_getsched() pthread_attr_getschedpolicy() pthread_condattr_create() pthread_condattr_init() pthread_condattr_delete() pthread_condattr_destroy() pthread_keycreate
Table 18 Thread Functions With Changed Parameters (continued) Syntax of Draft 4 Thread Function pthread_startroutine_t start_routine, pthread_addr_t arg); Syntax of Standard POSIX Threads Function void * (*start_routine) (void *), void *arg); int pthread_detach( pthread_t *thread); int pthread_detach(pthread_t thread); int pthread_getspecific( thread_key_t key, pthread_addr_t *value); void * pthread_getspecific( pthread_key_t key); void pthread_lock_ global_np(); int pthread_lock_global_np (void); i
Table 20 Thread Functions With Changes to Return Values Only (continued) Function Return Values in Standard POSIX Threads EINVAL The value specified by cond is invalid. pthread_cond_signal() 0 = successful EINVAL The value cond does not refer to an initialized condition variable. pthread_cond_signal_int_np() 0 = successful EINVAL The address or value specified by cond is invalid. pthread_cond_timedwait() 0 = successful ETIMEDOUT The time specified by abstime to pthread_cond_timedwait() has passed.
Table 20 Thread Functions With Changes to Return Values Only (continued) Function Return Values in Standard POSIX Threads EPERM The current thread does not own the mutex. pthread_once() None. Table 21 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 21 Thread Functions With Changes to Return Values Among Other Changes (continued) Function Return Values in Standard POSIX Threads ENOTSUP An attempt was made to set the attribute to an unsupported value. 210 pthread_attr_setstacksize() 0 = successful EINVAL The value of stacksize is less than PTHREAD_STACK_MIN or exceeds a system-imposed limit. pthread_cleanup_pop() None pthread_cleanup_push() None pthread_condattr_destroy() 0 = successful EINVAL The value specified by attr is invalid.
Table 21 Thread Functions With Changes to Return Values Among Other Changes (continued) Function Return Values in Standard POSIX Threads pthread_key_create() 0 = successful EAGAIN The system lacked the necessary resources to create another thread-specific data key, or the system-imposed limit on the total number of keys in a process (PTHREAD_KEYS_MAX) has been exceeded. ENOMEM Insufficient memory exists to create the key. pthread_key_delete() 0 = successful EINVAL The key value is invalid.
Table 21 Thread Functions With Changes to Return Values Among Other Changes (continued) Function Return Values in Standard POSIX Threads ENOMEM Insufficient memory exists to associate the value with the key. pthread_sigmask() 0 = successful EINVAL The value of the how parameter is not equal to one of the allowed values. pthread_signal_to_cancel_np() 0 = successful -1 = error (Check errno for last error, such as EINVAL.
Table 24 Thread Functions Not Supported in the Standard POSIX Threads Library (continued) Function Reason getchar_unlocked() For systems running G-series RVUs, H-series RVUs earler than H06.21, or J-series RVUs earlier than J06.10, C library function not supported in OSS environment. getlogin_r() For systems running G-series RVUs, H-series RVUs earler than H06.21, or J-series RVUs earlier than J06.10, C library function not supported in OSS environment.
Table 24 Thread Functions Not Supported in the Standard POSIX Threads Library (continued) Function Reason putchar_unlocked() For systems running G-series RVUs, H-series RVUs earler than H06.21, or J-series RVUs earlier than J06.10, C library function not supported in OSS environment. rand_r() For systems running G-series RVUs, H-series RVUs earler than H06.21, or J-series RVUs earlier than J06.10, C library function not supported in OSS environment.
Table 26 Obsolete and Replacement APIs in T1248 POSIX Threads (continued) Obsolete API Replacment API cma_fprintf() spt_fprintf() cma_fputc() spt_fputc() cma_fputs() spt_fputs() cma_fread() spt_fread() cma_fwrite() spt_fwrite() cma_gets() spt_gets() cma_getw() spt_getw() cma_pause() spt_pause() cma_printf() spt_printf() cma_puts() spt_puts() cma_putw() spt_putw() cma_read() spt_read() cma_recv() spt_recv() cma_recvfrom() spt_recvfrom() cma_recvmsg() spt_recvmsg() cma_select()
Table 26 Obsolete and Replacement APIs in T1248 POSIX Threads (continued) 216 Obsolete API Replacment API cma_fcntl() fcntl() cma_fdopen() fdopen() cma_fopen() fopen() cma_freopen() freopen() cma_fseek() fseek() cma_ftell() ftell() cma_isatty() isatty() cma_lib_calloc() calloc() cma_lib_cfree() cfree() cma_lib_free() free() cma_lib_malloc() malloc() cma_lib_realloc() realloc() cma_listen() listen() cma_mktemp() mktemp() cma_open() open() cma_pclose() pclose() cma_popen()
Glossary $RECEIVE A special Guardian file through which a process receives and optionally replies to messages from other processes. 32-bit address space The portion of the address space available to users of 32-bit addresses. On TNS/E systems, 32-bit addresses become 64-bit addresses by sign extension. Addresses 0 through 0x7FFFFFFF designate the first 2 gigabytes (GB) of per-process address space, starting at address 0.
appropriate privileges An implementation-defined means of associating privileges with a process for function calls or function call options that need special privileges. authorization attributes Security attributes of a process that can change through use of functions such as setuid() (or of Guardian procedures such as PROCESS_CREATE_) without reauthentication. The authorization attributes include the effective user ID, saved-set user ID, saved-set group ID, user audit flags, and the effective user name.
conforming POSIX.1 application An application that is either an ISO/IEC-conforming POSIX.1 application or a national-standards-body conforming POSIX.1 application. constraint An object that helps protect the integrity of data in a table by specifying a condition or conditions that all the values in a particular column of the table must satisfy. Unlike other SQL objects, a constraint has only an SQL name, not an operating system name, and a constraint does not have a file label.
event A significant change in some condition in the system or network. An event can be an operational error, notification of limits exceeded, request for action, notification of lines and other objects becoming available, and so on. Note that an event is not always an error. Event Management Service (EMS) A part of the Distributed Systems Management (DSM) product used to provide event collection, event logging, and event distribution facilities.
file transfer protocol (FTP) 1. 2. The Internet-standard, high-level protocol for transferring files from one machine to another. The application used to send complete files over Transmission Control Protocol/Internet Protocol (TCP/IP) services filename In the OSS environment, a component of a pathnamecontaining any valid characters other than slash (/) or null. See also file name. fileset In the OSS environment, a set of files with a common mount point within the file hierarchy.
Guardian services An application program interface (API) to the HP NonStop™ operating system, plus the tools and utilities associated with that API. This term is synonymous with Guardian environment. See also Guardian. hard link The relationship between two directory entries for the same file. A hard link acts as an additional pointer to a file. A hard link cannot be used to point to a file in another fileset. Contrast with symbolic link. header 1. 2.
large file aware An application or function that can process large OSS files in addition to small OSS files. For example, it must be able to access large files as input and generate large files as output. Contrast with large file safe. large file safe An application or function that causes no loss of data or corruption of data when it encounters a large OSS file.
noft utility A utility that reads and displays information from TNS/R native object files. non-regular file An OSS file that is not a regular (disk) file. noncanonical input mode A terminal input mode in which data is made available to a process when a timer expires or when a certain number of characters have been entered. Noncanonical data is not grouped into logical lines of input. This mode is sometimes called block mode or transparent mode. Contrast with canonical input mode.
OSS signal See Open System Services (OSS) signal. parent process The process that created a given process, or (if that process has stopped) a process that has inherited a given process. See also child process. path prefix In the OSS environment, a pathname, with an optional final slash (/) character, that refers to a directory. pathname In the OSS file system and Network File System (NFS), the string of characters that uniquely identifies a file within its file system.
process group A set of OSS 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 The process that has the process group ID of its process group as its OSS process ID.
root fileset The fileset with the device number of 0, normally containing the root directory for the OSS file system in an HP NonStop system. HP recommends that this fileset be named “root”. save file A file created by the Inspect subsystem in response to a command from a debugger. A save file contains enough information about a running process at a given time to restart the process at the same point in its execution.
other processes. A process can block some deferrable signals but not others. A signal is nondeferrable by the nature of its generation, not its identity; thus kill(pid, SIGSEGV) sends a deferrable signal to the target pid. Signals are used in all native and all OSS processes, but not in Guardian TNS processes (which use traps instead). signal delivery The action taken in or upon the target process because of the signal.
system process A process running as part of or on behalf of the HP NonStop operating system. A system process does not have an OSS process ID. System V A version of UNIX developed and marketed originally by AT&T. terminal A type of character special file that conforms to the interface description in Clause 7 of ISO/IEC IS 9945-1: 1990.
RISC instruction set and can run TNS object files by interpretation or after acceleration. TNS/R systems include all HP systems that use NSR-x processors. Contrast with TNS and TNS/E. TNS/R C compiler The C compiler that generates TNS/R object files. Compare with TNS C compiler and TNS/E C compiler.
drives, or to a virtual volume managed by the Storage Management Foundation (SMF). The volume name is also the name of the process that manages the volume. waited I/O I/O operations for which the initiating process does not resume execution until the I/O operations are completed. Contrast with nowait I/O. working directory In the Open System Services (OSS) environment, a directory, associated with a process, that is used in pathname resolution for relative pathnames.
Index Symbols #ifdef directives, 108 #include directive, 73 $RECEIVE file, 89, 91, 94 Guardian, message queues, 95 locales, 135 message queues, 91, 106 messages from, 77 PROCESS_SPAWN_, 98 requester as an OSS process, 150 server as an OSS process, 150 starting servers from OSS, 106 static server, 106 system messages , 76 $SYSTEM.SYSTEM, 73 $SYSTEM.SYSTEM.LIBCOBEY file, linking, 142 $SYSTEM.SYSTEM.
Guardian, 53, 90 interoperability coexistence , 73 defined, 120 table, 74, 148 large file aware (LFA), 132, 191 large file safe (LFS), 191 POSIX.1, 24 UNIX based, 29 Application, standardized, 28 ar utility, 156, 164, 173 Architecture, processors and porting stages, 110 Arguments file descriptor, 131 how passed to the C program, 158 Arithmetic precision, guidelines, 116 ARMTRAP procedure, 172, 177 ASCII text files converting with pax, 70 copying, 69 editing, 63 printing, 64 assert.
mixed-module programming, 83 standards conformation, 38 UNIX workstations, 33 Caching buffered data, 102 data block, 102 disk I/O, 102 file, 102 OSS name server, 100, 102 cat utility Guardian files, 68 in Guardian environment, 64 redirecting input and output with, 66 Catalog, OSS Enscribe database, 101 file operations, 100 OSS fileset, 101 CCOMP compiler, 155 cextdecs.
required file suffixes, 40 OSS, 116 pragmas, 119 SGI C, 166 Sun C, 166 Compiling and linking, 40, 41 C programs, 61 Guardian module, 83 on a workstation, 166 OSS module, 83 Condition codes changes for native mode, 175 header files, 131 Configuration file inetd process, 105 LISTNER process, 105 PORTCONF , 154 Connection requests and servers, 104 Constants, 27 Control characters, terminal, 56 Converting code, 138 Core file see Saveabend file cp utility between file systems, 69 flags, 69 Guardian files, 64, 69
Dynamic server, 104 Dynamic-link library (DLL), 172, 173 building your own, 41 common between native environments, 74 multiple, 172 user libraries, 172 E ed utility, 60, 162 EDIT files, 72, 77 editing from TACL, 63 open() function, 125 read by OSS functions, 112 Editing files on OSS using vi, 43 modes, OSS shell, 56 Editors ed utility, 60, 162 emacs utility, 44, 162 TEDIT, Guardian, 60, 63 UNIX, 63 vi utility, 43, 57, 60, 64, 162 EDITTOC utility, 64 Effects of Guardian process using OSS services, 149 eld u
File conversion to ASCII, with cp utility, 69 to ASCII, with pax utility, 70 to Guardian, with CTOEDIT, 64 to OSS, with EDITTOC, 64 File management Guardian commands, 60, 63 environment, 78 procedures , 77 OSS catalog, 100 commands, 60 environment, 77 functions, 77 name server, 100 opening a file, 100 performance, 101 performance, 102 File suffixes in programming, 61 requirement for native C compilers, 40 File system ID, translating, 100 File systems /G, OSS environment, 63 Guardian, 68, 112, 125 OSS and ED
see also Files accessing, 78, 112, 114 compared with Guardian, 114 filename conversions, 72 printer I/O, 82 protection bits, 114 security, 114 terminal character, 112 findcalls porting tool, 49, 109 Flags compiling with, 61 cp utility, 69 ls utility, 66 OSS files, 123 ps utility, 68 fopen() and fopen64() functions, 74, 148 fork() function compared to UNIX exec(), 97 creating processes, 113 OSS environment, 128 process handle, 128 UNIX environments, 96 fprintf() function, 74, 148 freopen() and freopen64() fu
procedures AWAITIO and AWAITIOX procedures, 79 called from OSS, 131 changes for native mode, 176 compared to UNIX features, 29 extended for OSS, 80 FILE_COMPLETE_, 145 FILE_COMPLETE_GETINFO_, 145 FILE_COMPLETE_SET_, 145 FILE_GETINFO_, 145 FILE_GETINFOBYNAME_, 145 FILE_GETINFOLIST_, 145 FILE_GETINFOLISTBYNAME_, 145 FILE_GETRECEIVEINFO_, 145 FILE_OPEN_, 145 FILENAME_FINDNEXT_, 73 FILENAME_TO_PATHNAME_, 144 GROUP_GETINFO_, 143 GROUPMEMBER_GETNEXT_ , 143 in C programs, 96, 131 interoperability, 115, 120, 129 ob
IEEE standards, compared with OSS, 24 Include files, 42 search order, 141, 156 Industry standards, programmatic calls, 28 inetd activated services, 106 configuration file, 105 demon, compared to LISTNER process, 154 porting programs using, 180 starting other servers with, 105 UNIX, 105 Inherited attributes, modifying with HP extensions, 97 Initialization values, default, 131 Inodes caching, 102 OSS name server, 100 Input functions, 24 redirecting with cat utility, 66 Inspect and optimized files, 45 compared
application conversion compilation environments, 191 examples, 194 fseek(), 193 fseeko(), 193 ftell(), 193 ftello(), 193 general issues, 192 Guardian files, 79 large file compilation environment, 191, 192 opening with Guardian procedures, 78 regular composition environment, 191 underlying Guardian file format, 79 LASTADDR procedure, 177 LASTADDRX procedure, 177 ld utility Guardian environment, 41 memory, 171 OSS environment, 41 replacing Binder, 46, 173 TNS/R native only, 47 user library , 174 Left angle br
shared with Guardian procedures, 93 stack size for native mode, 176 synchronize access, 150 virtual, 172 when starting processes, 149 Memory mapping, 86 Memory models, 140, 147, 156 Message queues, 89 $RECEIVE file, 106 fault tolerant, 95 fork() and exec set of functions, 91 FT type, 95 global, 91 Guardian, $RECEIVE file, 95 identifiers, 91 msgctl() function, 90 msgget() function , 90 msgrcv() function , 90 msgsnd() function , 90 NONFT type, 95 not between Guardian and OSS environments, 91 priority, 95 Mess
O Object Code Accelerator (OCA) optimizer see Accelerator programs Object code, restrictions for mixing different types, 170 Object files, 170 native, 41, 46, 47, 173 UNIX format (ELF), 47 utilities, 164 Object-oriented security model, 113 Objects agreement with function, 148 and functions of opposite environment, 148 functions for manipulating, 148 Guardian, accessing, 113 manipulating, 53 OSS, accessing, 113 security rules, 148 OCA see Accelerator programs Odd-unstructured files , 77, 112, 125 old objects
structure, error information, 131 P Parallel processing, static server, 105 Parameters command line, 56 guidelines, 116 OSS pe_parms, 97 pr_results, 97 portability checking, 50 STATUS command, 62 PARAMs, Guardian environment variables, 57 Parent process creating pipes, 91 exit() function, 128 open files, 131 OSS functions, 128 PROCESS_SPAWN_ procedure, 98, 106 PATH variable, C shell, 55 PATHNAME_TO_FILENAME_ procedure, 77 Pathnames conversion, OSS to Guardian, 64 mapping, 129 OSS, limits, 112 resolving, 92
across processors, 97, 102 calls, 98 differences between environments, 72 functions Guardian attributes, 97 specific to HP, 131 UNIX environment, 96 Guardian attributes, 72 Guardian environment variables, 57 OSS attributes, 72 OSS shell, 57 performance, 96 procedures, 76 PROCESS_SPAWN_ procedure see PROCESS_SPAWN_ procedure static server, 104 Process handle changing by exec set of functions, 128 Guardian, 71, 131 process-management, 76 Process ID not for Guardian processes, 127 Process identification number
binding, 61 file suffixes, 61 search path, 55 Prompt string, 56 Protection bits, for files, 114 Protection, changing for files, 60, 63 Prototypes, functions, 117 ps utility compared with STATUS command, 59 flags, 68 pTAL language, 177 signals, 80 no embedded SQL support, 170 source code, 170 converting to C or C++, 138 Pthread functions, 188 Pthreads, 186 Pthreads functions differences between Draft 4 and IEEE 1003.
Semaphores, 89 accessing resources with, 94 binary, 151 Guardian, 151 OSS, 151 shared memory, 93 single processor, 93 XPG4 counting, 93 Sequential processing, multithreading, 87 Server processes and client communication, 104 demon, 104 dynamic, 104 Guardian, starting LISTNER process, 106 inetd, 105 listener, 105 LISTNER, 105, 154 OSS, PROCESS_SPAWN_ procedure, 106 starting, 104 static, 104 World Wide Web, 104 SERVICES file, LISTNER process, 105 set_defaults_from_env() function, 135 set_env_from_defaults() f
OSS, 178 performance considerations, 90 TCP/IP, 106 Source code C compilation, 38 control system (SCCS), 164 Guardian applications, 31, 170 moving to OSS, 35 portability checking, 48 Specifications, XPG4, 53, 112, 117 Spooler locations commands for finding, 60 printing from TACL, 64 Spooler procedures, OSS files , 82 SPOOLSTART procedure, printer I/O , 82 spt functions T1248, 214 sqlc utility, for NonStop SQL/MP preprocessor, 39 sqlcomp utility, for NonStop SQL/MP compiler, 39 SSV pragma, 156 Stack size gui
TACL =_AFUNIX_PROCESS_NAME MAP DEFINE, 127 =TCPIP^PROCESS^NAME MAP DEFINE, 126 commands, 151 OSH command, 152 osh utility, 152 running Inspect from, 45 shell popen() function, 151 switching to OSS shell from, 66 TAL programs converting to C code, 138 converting to pTAL code, 138, 177 tal.
file compatibility, 32 improved performance, 31, 170 new C compilation tools, 31 new features, 171 object files, 32 restrictions, 170 shared run-time library, 137 source code, 31 system compatibility, 32 user library, 174 TNS/R native shared run-time library (TNS/R native SRL), 172 TNS/R native-mode applications, 170 Tools C program analysis, 163 porting see tools under Porting Transaction Application Language (TAL) see TAL programs Transferring files, back to the workstation, 36 Translation limits, 119 Tra
Z zinetsrl library, 179, 184 Zombie processes, avoiding, 99 ZYQ subvolume names, 64 251
