TNS/E Native Application Conversion Guide Abstract This manual introduces the TNS/E native development and execution environments and explains how to convert existing TNS applications to TNS/E native applications. Product Version N.A. Supported Release Version Updates (RVUs) This publication supports H06.03 and all subsequent H-series RVUs until otherwise indicated by its replacement publication.
Document History Part Number Product Version Published 529659-002 N.A. July 2005 529659-003 N.A.
TNS/E Native Application Conversion Guide Glossary Index Examples What’s New in This Manual vii Manual Information vii New and Changed Information About This Manual ix Audience ix Purpose x Organization xi For More Information xii Notation Conventions Figures Tables vii xiii 1.
2. Developing a Conversion Strategy Contents Native Architecture Features (continued) Signals Facility 1-16 DLLs 1-17 Native Mode Conversion Considerations KMSF 1-19 Benefits of Native Mode 1-21 Constraints of Native Mode 1-22 1-18 2.
3. C and C++ Conversion Tasks (continued) Contents 3. C and C++ Conversion Tasks (continued) Checking Changed Pragmas 3-15 Removing Obsolete Pragmas 3-16 4. Converting COBOL Programs COBOL Compiler Overview 4-1 Converting COBOL Programs 4-2 Changing the Source Program 4-4 General Conversion Tasks 4-4 Removal Required 4-4 Possible Changes Required 4-5 Removal Optional 4-9 New Features 4-10 5. Converting TAL to pTAL Using the pTAL Compiler Required Changes 5-1 5-1 6.
Contents 9. Converting Programs That Share Data 9. Converting Programs That Share Data Sharing Data Between TNS and TNS/E Native Programs 9-1 Sharing Data Between pTAL Programs and Native C or C++ Programs 10.
Glossary Contents Glossary Index Examples Example 3-1. Example 5-1. Examining _cc_status 3-6 pTAL Compiler Listing With Syntax Checking 5-2 Figures Figure 1-1. Figure 1-2. Native Mode Benefits All Programs 1-3 Run-Time Library Organization 1-19 Tables Table 1-1. Table 1-2. Table 3-1. Table 3-2. Table 3-3. Table 3-4. Table 8-1. Table 8-2. Table 8-3. Table 11-1. Table 11-2.
Contents TNS/E Native Application Conversion Guide —529659-003 vi
What’s New in This Manual Manual Information TNS/E Native Application Conversion Guide Abstract This manual introduces the TNS/E native development and execution environments and explains how to convert existing TNS applications to TNS/E native applications. Product Version N.A. Supported Release Version Updates (RVUs) This publication supports H06.03 and all subsequent H-series RVUs until otherwise indicated by its replacement publication.
What’s New in This Manual New in the H06.21/J06.
About This Manual This manual introduces the TNS/E native development and execution environments and explains how to convert existing TNS applications to TNS/E native applications. This manual applies to all TNS programs; those that run on a TNS/R system and those that run on a TNS/E system. The information in this manual applies only to conversion to TNS/E native mode, although converting a TNS program to TNS/R native mode is similar.
About This Manual Purpose This document is designed to help you perform these tasks: • • • • • • • • • • Learn about the TNS/E native execution and development environment and how it differs from the TNS environment. Determine which programs can be converted and the effort required to convert them. Plan a conversion strategy. Convert programs written in C and C++ from TNS to native mode. Convert programs written in COBOL from TNS to native mode.
About This Manual Organization Section Explains Section 1, Introduction to Native Mode TNS/E native development and execution environments, features of TNS/E native architecture, and benefits and constraints of TNS/E native mode Section 2, Developing a Conversion Strategy How to prepare programs for conversion, plan system resources, determine which programs to convert, maintain common TNS and native source files, and maximize the performance of TNS/E native programs Section 3, C and C++ Conversion T
About This Manual For More Information Manual Explains (page 1 of 2) Object Code Accelerator (OCA) Manual How to improve performance of TNS programs running on TNS/E systems (converting them to TNS/E native mode is preferable) Binder Manual How to use the stand-alone Binder product to bind compilation units (or modules) that were compiled with TNS compilers C/C++ Programmer’s Guide The NonStop C and NonStop C++ programming languages, compilers, and run-time libraries COBOL Manual for TNS/E Programs
Notation Conventions About This Manual Manual Explains (page 2 of 2) KMSF Manual How to use NSKCOM utility to configure and manage the swap volumes used by the KernelManaged Swap Facility (KMSF) Inspect Manual How to debug programs using the Inspect sourcelevel and machine-level interactive debugger Open System Services System Calls Reference Manual The syntax and semantics of part of the HP NonStop Open System Services (OSS) API, including the ISO/ANSI NonStop C run-time library calls Open System
HP Encourages Your Comments About This Manual 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 docsfeedback@hp.com. Include the document title, part number, and any comment, error found, or suggestion for improvement that you have concerning this document.
1 Introduction to Native Mode TNS/E native mode enables you to write programs that are fully optimized for Integrity NonStop servers that use the TNS/E architecture. The term TNS/E native means the program uses the process, memory, and instruction set architectures that are native to Intel® Itanium® processors. Throughout the rest of this manual, the terms native and native mode are used to mean TNS/E native and TNS/E native mode, respectively.
Summary of Execution Modes Introduction to Native Mode Summary of Execution Modes A TNS process—a process that runs in TNS interpreted mode or TNS accelerated mode—is initiated by running a TNS interpreted or accelerated object file. A native process—a process that runs in native mode—is initiated by running a native object file. Native object files consist entirely of Intel® Itanium® instructions. Native processes do not maintain TNS architecture-specific constructs.
Underlying Native Mode Structure for All Programs Introduction to Native Mode Underlying Native Mode Structure for All Programs As shown in Figure 1-1, in H-series RVUs, HP has converted nearly all system code, system library routines, and other products to run in native mode. (Shaded regions in the figure indicate code that runs in native mode.
Introduction to Native Mode Differences Between Accelerated and Native Object Code Differences Between Accelerated and Native Object Code While both accelerated and native object code execute Itanium instructions, most native object code has a significant performance advantage over accelerated object code. The OCA cannot produce Itanium instructions for TNS instruction sequences whose exact meaning cannot be determined until run time.
pTAL Compiler Introduction to Native Mode Table 1-1 compares the tools used in the TNS and native development environments: Table 1-1.
Introduction to Native Mode Native C Compiler Guardian environment. The EPTAL compiler command line syntax is similar to that of the TAL compiler command. The eptal utility runs the pTAL compiler on the PC. ETK enables you to compile and link programs on a PC (for details, see the pTAL Reference Manual). You can copy the object files to a TNS/R or TNS/E system and execute them in the Guardian and OSS environments. The TNS/E pTAL compiler provides a syntax-checking mode that helps you convert TAL to pTAL.
Introduction to Native Mode Native COBOL Compiler The native C++ compiler command line syntax is similar to that of the TNS C compiler and Cfront. The native c89 utility runs the compiler in the OSS environment and on the PC. The native c89 utility syntax is similar to that of the TNS c89 utility. ETK provides cross compilers that enable you to compile and link programs on a PC under the Windows operating system for execution on the Integrity NonStop server.
Introduction to Native Mode Native C Run-Time Library Native C Run-Time Library The native C run-time library provides functions conforming to the ISO/ANSI C Standard. It also contains functions conforming to the X/OPEN UNIX 95 specification and HP extensions for NonStop systems to these standards. The native C run-time library supports Guardian and OSS processes.
Introduction to Native Mode Native Object File Tool (enoft Utility) Native Object File Tool (enoft Utility) The native object file tool, enoft, reads and displays information about native object files. You can use enoft to: • • • • Determine the optimization level of procedures Display object code with corresponding source code List object file attributes List unresolved references enoft runs in the Guardian and OSS environments.
Introduction to Native Mode Native Mode Debugging Tools As part of the migration process, the tool ensures that all files pertaining to the TDS target remain part of the ETK project. However, file properties for file types that are unknown to ETK are not migrated. For every such file type, users must explicitly add these file properties in ETK. The migration tool supports the following file extensions: .cpp, .css, .tal, .cob, and .cbl. Note.
Introduction to Native Mode Visual Inspect For code compiled at optimization level 0 (no optimization) or optimization level 1 (intermediate optimization), you can perform the same operations for native processes (using Visual Inspect) as for TNS process (using Inspect), including: • • • • Step through code Set breakpoints Display source Display variables In addition, H-series Visual Inspect provides these machine-level capabilities: • • • • • Set instruction breakpoints Display instruction code Disp
Introduction to Native Mode Native Inspect Native Inspect Native Inspect is a command-line symbolic debugging tool that can be used for debugging TNS/E native processes and snapshot files. It can be used for source statement level debugging as well as machine-level debugging. Native Inspect is intended as a replacement for the G-series Debug facility and the G-series Inspect debugger for native mode debugging. The command name for Native Inspect is eInspect. Note.
Introduction to Native Mode Native Architecture Features Native Architecture Features The native architecture introduces these new features: • • • • • Native Process Environment Native Object File Format on page 1-16 Signals Facility on page 1-17 DLLs on page 1-17 KMSF on page 1-19 Native Process Environment A process that runs in TNS interpreted mode or TNS accelerated mode—a TNS process—consists entirely of TNS instructions or both TNS instructions and Object Code Accelerator-generated Itanium instru
Native Process Environment Introduction to Native Mode When a process is created, it occupies space in virtual memory. The basic organization of a process is discussed next in terms of code spaces, which are associated with the objects in the preceding list, and data spaces. Code Segments A process has distinct code segments that contain executable code. (Segments is the term used for TNS/R and TNS/E native processes. In the TNS environment, the term code spaces is used.
Native Process Environment Introduction to Native Mode Data Segments When a process is created, several data segments are allocated for its use.
Introduction to Native Mode Native Object File Format For native C and C++ programs, the native Common Run-Time Environment (CRE) automatically manages a heap in the globals-heap segment. The heap is optional for other programs. TNS and Itanium stack growth is as follows: • • • TNS stacks grow upwards (from lower to higher addresses). The Itanium RSE backing store grows upwards. Itanium memory stacks grow downwards.
Introduction to Native Mode Signals Facility Signals Facility Certain critical error conditions occurring during process execution prevent normal process execution. Most of these error conditions are unrecoverable. In TNS processes, these errors cause the process to receive a trap. In native processes, these errors cause the process to receive a signal. Native processes do not receive traps.
Introduction to Native Mode Native Mode Conversion Considerations PIC and DLLs were introduced in the G06.20 RVU. Non-PIC and SRLs continue to be supported in the G06.2x RVUs. On H-series systems, all native code is PIC, and all native libraries are DLLs. Non-PIC and SRLs are not supported. DLLs on H-series systems include: • • • The system library, which is packaged as a set of implicit DLLs Other libraries supplied by HP, such as compiler run-time libraries All user-created libraries.
KMSF Introduction to Native Mode Figure 1-2. Run-Time Library Organization TNS C Programs TNS/E Native C Programs Application Code Application Code C Run-Time Library (Model-Dependent) C Run-Time Library (Initialization) Application Program System C Run-Time Library (Model-Independent) CRE Library C Run-Time Library DLL CRE Library DLL VST 002.VSD As shown in Figure 1-2, the TNS C and CRE libraries are located in the system library. The native C and CRE libraries are DLLs.
Introduction to Native Mode KMSF KMSF manages: • • • • • • The globals-heap segment and DLL instance data segments (variable and constant) for TNS/E native processes The memory stack segment, RSE backing store segment, and privileged backing store segment for TNS/E native processes The main stack segment and the privileged stack segment for TNS processes The user data segment for TNS processes The default extended data segment for TNS processes, unless it is explicitly specified not to be managed by KMS
KMSF Introduction to Native Mode Table 1-2. Comparing Swap for TNS and Native Processes How Specified Effect on TNS Processes Effect on Native Processes RUN command SWAP option Managed by KMSF. Ignored. Managed by KMSF. Ignored.
Introduction to Native Mode Benefits of Native Mode Benefits of Native Mode • • • General ° Native code often runs significantly faster than TNS interpreted or accelerated code. ° ° ° Native object code does not need to be accelerated. Native processes support more global variables than TNS processes. Native processes support a default stack of 2 MB (expandable to 32 MB), which is significantly larger than the 64 KB stack limit for TNS processes.
Introduction to Native Mode Constraints of Native Mode ZCOBDLL contains the COBOL utility routines which, for TNS COBOL, reside in the system library, COBOLLIB, and CBL85UTL. ZCREDLL contains the COBOL run-time routines which, for TNS COBOL, reside in the system library or in CLULIB. Constraints of Native Mode Before you start converting applications to native mode, be aware of the constraints of the native environment: • • • • • • • • pTAL, unlike TAL, cannot contain embedded SQL statements.
Introduction to Native Mode Constraints of Native Mode TNS/E Native Application Conversion Guide —529659-003 1- 24
2 Developing a Conversion Strategy This section describes the decisions you must make to convert a program to native mode, including: • • • • • • • Determining Which Programs to Convert Preparing Programs for Conversion on page 2-2 Planning System Resources on page 2-2 Maintaining Common Source Code for TNS and TNS/E Native Compilers on page 2-3 Determining Optimization Levels on page 2-5 Determining Data Alignment on page 2-6 Tuning the Performance of Native Programs on page 2-8 Determining Which Progra
Developing a Conversion Strategy Preparing Programs for Conversion You can use the Measure system performance-analysis tool to determine which programs can be significantly improved by native-compiling. When measuring program performance, select a measurement window that coincides with some representative portion of the system workload, usually the system’s peak time. For further verification, take and compare multiple measurements to create a level of confidence with the data collected.
Developing a Conversion Strategy Maintaining Common Source Code for TNS and TNS/E Native Compilers Maintaining Common Source Code for TNS and TNS/E Native Compilers If your program requires few changes to convert to native mode, you can often maintain common source code for the TNS and native compilers. If your program requires extensive or complex changes to convert to native mode, maintaining common source code is impractical.
Adjusting for Increased DCT Limits Developing a Conversion Strategy In some cases, two logically equivalent but syntactically different fragments of code might be required: one for TNS compilers and one for native compilers.
Determining Optimization Levels Developing a Conversion Strategy The recommended solution is to replace the affected procedures with updated procedures that can handle increased DCT limits: C-Series Procedure Replacement Procedure FILEINFO FILE_GETINFOLIST_ GETDEVNAME DEVICE_GETINFOBYLDEV_ CONFIG_GETINFOBYLDEV_ CONFIG_GETINFOBYLDEV2_ FILENAME_FINDSTART_ FILENAME_FINDNEXT_ GETPPDENTRY PROCESS_GETPAIRINFO_ GETSYSTEMNAME NODENUMBER_TO_NODENAME_ LOCATESYSTEM NODENAME_TO_NODENUMBER_ LOOKUPPROCESSNA
Developing a Conversion Strategy Determining Data Alignment the optimization level for the native COBOL and pTAL compilers. The native compilers’ default optimization level is 1. For C, C++, and pTAL, optimization can be set on a module or procedure basis. Therefore, native programs can contain modules or procedures compiled at different optimization levels. This hybrid approach can be used to improve program performance while maintaining as much symbolic debugging support as possible.
Developing a Conversion Strategy Converting Programs With Misaligned Data FIELDALIGN SHARED2 and REFALIGNED 2 directives in pTAL. These pragmas and directives ensure that the native compilers use the same data alignment as TNS compilers. Another strategy is to set the FIELDALIGN CSHARED2 and REFALIGNED 2 pragmas or the FIELDALIGN SHARED2 and REFALIGNED 2 directives when you first start converting a program.
Developing a Conversion Strategy Tuning the Performance of Native Programs Both TNS/R and TNS/E systems offer facilities for detecting misaligned addresses and for controlling program action if a misalignment is detected.
Developing a Conversion Strategy Eliminating Compatibility Traps These directives and pragmas ensure that compatibility traps do not occur.
Developing a Conversion Strategy Eliminating Compatibility Traps TNS/E Native Application Conversion Guide —529659-003 2- 10
3 C and C++ Conversion Tasks This section describes how to convert TNS C and C++ programs to TNS/E native mode.
C and C++ Conversion Tasks Using the Native C and C++ Compilers This section assumes your program can be compiled by the current TNS C compiler or TNS C++ preprocessor. It also assumes your program runs on the current version of the operating system. See the C/C++ Programmer’s Guide for information on converting C programs to use the current TNS C compiler.
C and C++ Conversion Tasks Converting Code to Use 32-Bit Pointers and Integers TNS/R code cannot be executed on a TNS/E platform, and TNS/E code cannot be executed on a TNS/R platform. For c89 and c99 conversion information, see Section 11, OSS API and Utilities Conversion Tasks. All code generated by the TNS/E native compilers is position-independent code (PIC). PIC is code that need not be modified to run at different virtual addresses and is used to create dynamic-link libraries (DLLs).
Converting Code to Use 32-Bit Pointers and Integers C and C++ Conversion Tasks • Ensure that the type of a function call argument matches the defined type of its associated parameter. The TNS C compiler issues this warning message for argument-parameter mismatches: Warning 86: argument "name" conflicts with formal definition • Write function prototypes for all user-written functions without prototypes.
Using IEEE Floating Point Format C and C++ Conversion Tasks Using IEEE Floating Point Format TNS C and C++ programs use the HP proprietary TNS floating-point format. The native C and C++ compilers provide the option of using either the TNS or the IEEE floatingpoint format. The default option is IEEE format. Programs that depend on TNS format must specify the TANDEM_FLOAT pragma (or -Wtandem_float flag) when converted to native mode.
C and C++ Conversion Tasks Changing Use of _cc_status for Return Values The extptr keywords identify 32-bit pointers in external function declarations for TAL. Native programs support only 32-bit pointers, so this keyword is unnecessary. Delete the extptr keyword. Changing Use of _cc_status for Return Values _cc_status is used for calls to Guardian and TAL procedures that set a conditioncode register instead of returning a value.
C and C++ Conversion Tasks Replacing Calls to Obsolete C Library Supplementary Functions Example 3-1 shows the difference between using the new macros and the previous macros to examine _cc_status. Example 3-1. Examining _cc_status Previous macros (TNS Programs Only) _tal _extensible _cc_status READX ( ... ); #include ... _cc_status CC; CC = READX ( ... ); if (CC == CCL) { ... } else if (CC == CCG) { ... } Current macros (TNS and Native Programs) _tal _extensible _cc_status READX ( ...
Replacing Calls to Obsolete C Library Supplementary Functions C and C++ Conversion Tasks Table 3-1. Obsolete C Supplementary Functions (page 1 of 2) Obsolete Function Suggested Replacement _is_system_trap() Delete _is_system_trap(). Trap handling mechanism is replaced with signals in native processes. See the Guardian Programmer’s Guide for details. iscsym() Write your own function iscsym() to check whether a character is a valid character in a C identifier.
C and C++ Conversion Tasks Replacing Calls to Obsolete C Library Guardian Alternate-Model I/O Functions Table 3-1. Obsolete C Supplementary Functions (page 2 of 2) Obsolete Function Suggested Replacement stcpm() Replace stcpm() with a call to strstr(). The order and type of parameters and the return value for these two functions are different. Additional code might be required to support pattern matching. stcpma() Replace stcpma() with a call to strstr().
C and C++ Conversion Tasks Replacing Calls to Obsolete C Library Guardian Alternate-Model I/O Functions on the system running the program. For details, see the function’s reference page online or in the Open System Services Library Calls Reference Manual. The obsolete Guardian alternate-model I/O functions and replacement options are listed in Table 3-2. Table 3-2.
Checking Calls to Changed C Library Functions C and C++ Conversion Tasks Checking Calls to Changed C Library Functions Functions Having Different Behavior The following functions have changes in ISO/ANSI C standard implementation-defined behavior. These changes affect only Guardian C functions and were made to match the behavior of the TNS OSS environment and the UNIX computer industry .
C and C++ Conversion Tasks Using the setjmp() and longjmp() Functions Using the setjmp() and longjmp() Functions Calling the setjmp() function in a function marked as inline and then doing a subsequent longjmp() to the location of the calling function is a practice that should be avoided.
C and C++ Conversion Tasks Changing Programs That Use Guardian and OSS Environment Interoperability Changing Programs That Use Guardian and OSS Environment Interoperability Because of differences in the Guardian and OSS file systems, six functions require environment-specific parameters: fopen(), freopen(), remove(), rename(), tmpnam(), and tmpfile(). Each of these base functions has a Guardian variant and an OSS variant, such as fopen_guardian() and fopen_oss().
Using Active Backup Programming in C C and C++ Conversion Tasks Using Active Backup Programming in C To convert a TNS program that uses the active backup programming functions to native mode: • • Replace the header file nonstop.h with crtlns.h. Instead of binding in cnonstop, link the active backup support library: Environment Active Backup Support Library Guardian CRTLNS OSS or PC crtlns.
Specifying Pragmas or Flags C and C++ Conversion Tasks Specifying Pragmas or Flags The native C and C++ compilers are multipass, multicomponent compilers. As such, they require that the following pragmas be specified on the C or C++ compiler Guardian RUN command line or as flags to the c89 or c99 utility.
Checking Changed Pragmas C and C++ Conversion Tasks Checking Changed Pragmas For the pragmas listed in Table 3-3, the native C and C++ compilers produce results different from those of the TNS compilers. Verify that programs do not rely on any of the changed behaviors and make appropriate changes. Table 3-3. Changed Pragmas Changed Pragma Changed Behavior Action Required [NO]INLINE Native C and C++ compilers do not generate inline code for standard C function calls.
Removing Obsolete Pragmas C and C++ Conversion Tasks Removing Obsolete Pragmas The native C and C++ compilers do not support the pragmas in Table 3-4. In most cases, you must remove the pragma from the source code. In a few cases, you might need to write additional code. Table 3-4. Obsolete Pragmas (page 1 of 2) Pragma Reason pragma is obsolete Action Required ANSICOMPLY Pragma has been replaced by NOEXTENSIONS pragma. None. The NOEXTENSIONS pragma is set by default.
Removing Obsolete Pragmas C and C++ Conversion Tasks Table 3-4. Obsolete Pragmas (page 2 of 2) Pragma Reason pragma is obsolete Action Required [NO]WIDE Native compilers generate programs that use only the 32-bit (or wide) data model. Remove pragma and recode programs that specify NOWIDE to use the 32-bit (or wide) data model. [NO]XMEM Native compilers generate programs that use only the largememory model. Remove pragma and recode programs that specify NOXMEM to use the large-memory model.
4 Converting COBOL Programs This section describes how to convert TNS COBOL programs to TNS/E native mode. The compilers to which this section applies are: Compiler T Number TNS COBOL85 T9257 TNS cobol T8498 TNS/E ECOBOL T0356 TNS/E ecobol T0356 This section discusses: • • • COBOL Compiler Overview Converting COBOL Programs Changing the Source Program COBOL Compiler Overview Both the TNS COBOL compiler and the TNS/E native COBOL compiler comply with the 1985 COBOL85 standard.
Converting COBOL Programs • • Converting COBOL Programs The data space limit of approximately 60 KB for the sum of all the Working-Storage Sections and File Sections of a TNS process does not apply to native COBOL programs. The Working-Storage Section and the Extended-Storage Section are the same in native COBOL. In TNS/E native COBOL, there is no distinction between the small data area and the large data area.
Converting COBOL Programs Converting COBOL Programs If any of your TAL programs use the FORTRAN convention for determining the length of a string parameter (that is, if they use the ENTER routine and do not specify the language TAL), convert them to use another method. (For example, use the string:length convention or pass the length as a separate parameter.) For information on tools that can help you convert TAL programs to pTAL programs, see Section 5, Converting TAL to pTAL.
Converting COBOL Programs Changing the Source Program 6. Compile your source program with the native COBOL compiler. For instructions, see the COBOL Manual for TNS/E Programs. The native COBOL compiler needs more symbol table space than the TNS COBOL compiler does. If the native COBOL compilation fails because of dictionary overflow, use the PARAM SYMBOL-BLOCKS command to increase the space available for the symbol table, local label table, and embedded SQL statements and then recompile.
Converting COBOL Programs Removal Required Removal Required Remove the following directives, statements, and library references from your TNS COBOL source program before compiling it with the native COBOL compiler: • ENV OLD directive If you specify the ENV OLD directive, the native COBOL compiler reports an error. Native COBOL programs always run in the CRE. • SQL directive If your program contains SQL statements, include the SQL directive in the native ECOBOL compiler command line.
Converting COBOL Programs Possible Changes Required Possible Changes Required The TNS and native COBOL compilers handle the following directives, the ENTER statement, floating-point arithmetic, and checkpointing differently. Make any necessary changes to them before compiling your COBOL source program with the native COBOL compiler. For complete descriptions of the directives, see the COBOL Manual for TNS/E Programs.
Converting COBOL Programs • Possible Changes Required SEARCH For the native COBOL compiler, each object-name in a SEARCH directive must designate a native object file (otherwise the native COBOL compiler reports an error). If a native COBOL program references the object in a CALL or ENTER statement, the object must have been compiled with symbols. • SUBTYPE The SUBTYPE directive works in the native COBOL compiler only if you specify the new RUNNABLE directive (see RUNNABLE directive on page 4-11).
Possible Changes Required Converting COBOL Programs Checkpointing The TNS COBOL compiler automatically checkpoints data items that are stored directly on the stack in two or fewer bytes (that is, if they are level-01 or level-77 items, in the Working-Storage Section, and fewer than three characters long). The native COBOL compiler checkpoints only those data items that one or more CHECKPOINT statements specify explicitly.
Converting COBOL Programs Removal Optional Use of PARAM SYMBOL-BLOCKS Command The TNS/E COBOL compiler requires more space to describe a symbol that does the TNS/R COBOL compiler; thus, the symbol dictionary requires more space on a TNS/E system. If you use a PARAM SYMBOL-BLOCKS command to specify the amount of space to allocate for the symbol dictionary in a TNS/R compilation, you might need to increase the amount specified when compiling with the TNS/E compiler.
Converting COBOL Programs Removal Optional Instead of using the ENV LIBRARY directive to build a TNS user library, use the UL or SHARED directive to build a PIC object file, which can be used by the linker to create a DLL (see the COBOL Manual for TNS/E Programs). • EXTENDED-STORAGE SECTION header Native COBOL does not need an Extended-Storage Section. The native COBOL compiler handles data items that are described in the Extended-Storage Section as if they were described in the Working-Storage Section.
Converting COBOL Programs New Features New Features You can (but need not) add these new features to your COBOL source program before you compile it with the native COBOL compiler. For more information on these features, see the COBOL Manual for TNS/E Programs.
Converting COBOL Programs TNS/E Native Application Conversion Guide —529659-003 4- 12 New Features
5 Converting TAL to pTAL HP TAL is a higher-level, block-structured language used to write system software and transaction-oriented applications for NonStop systems. pTAL is a dialect of TAL with these differences: • • • pTAL does not depend on architecture-specific characteristics of NonStop processors. pTAL has constructs that replace architecture-specific TAL constructs and that take advantage of TNS/E processors. pTAL also enforces stricter rules on using certain TAL constructs and operations.
Required Changes Converting TAL to pTAL • • Remove CODE, STACK, and STORE statements. Rewrite code that uses G, S, or L-relative addresses. pTAL does not support embedded SQL statements. To convert a TAL program with embedded SQL to pTAL, write C functions that contain the embedded SQL statements and call the C functions from pTAL. Many TAL programs require few changes to create valid pTAL programs.
Required Changes Converting TAL to pTAL As an alternative to reading the lengthy pTAL Reference Manual and pTAL Conversion Guide, you can convert the majority of TAL programs by following these steps: 1. Read pTAL Guidelines for TAL Programmers to familiarize yourself with the difference between TAL and pTAL. 2. Process your source files with the pTAL compiler syntax checking option set.
Required Changes Converting TAL to pTAL TNS/E Native Application Conversion Guide —529659-003 5 -4
6 Converting a TNS User Library This section explains how to convert TNS user libraries to TNS/E native user libraries. A user library is an object file that the operating system links to a program file at run time. C, C++, COBOL, TAL, and pTAL programs can have a user library. There are two types of user libraries on H-series systems: TNS user libraries and TNS/E native user libraries. A TNS user library is available to TNS processes in the Guardian environment.
Converting a TNS User Library Building a User Library Building a User Library Building a TNS/E native user library is similar to building a TNS user library. To build a TNS/E native user library: 1. Remove pragmas and directives: • • In C and C++, remove ENV LIBRARY pragmas from source code files and the compiler RUN command line. In COBOL and pTAL, remove ENV LIBRARY directives from source code files. 2.
Specifying a User Library Converting a TNS User Library See the following manuals for more details on building TNS/E native user libraries and DLLs: • • • Compiler manuals eld Manual DLL Programmer’s Guide for TNS/E Systems Specifying a User Library Only one user library can be associated with a program file at any time. Associating a user library with a program file is nearly identical for TNS user libraries and TNS/E native user libraries.
Converting a TNS User Library Specifying a User Library For more information on TNS user libraries, see the Binder Manual. For more information on TNS/E native user libraries and DLLs, see the eld Manual and the DLL Programmer’s Guide for TNS/E Systems.
7 Converting Data Definition Language (DDL) This section describes how to convert Data Definition Language (DDL) host language source files that: • Are shared between TNS and TNS/E native programs written in C, C++, TAL, or pTAL and • Were generated by a pre-D40 product version of the DDL compiler If these criteria apply to your DDL host language source files, follow the instructions in this section to generate new host language source files and recompile your programs with the new files.
Converting Data Definition Language (DDL) Generating New Host-Language Source Code Files compilers or native compilers are used. To ensure the same data alignment, the D4x, G-series, and H-series DDL compilers emit FIELDALIGN SHARED2 pragmas for C and FIELDALIGN SHARED2 directives for TAL and pTAL. Except for COBOL, host-language source files used by TNS/E native programs and shared with TNS programs must be generated using the D4x, G-series, or H-series DDL compiler.
Converting Data Definition Language (DDL) Compiling With New Host-Language Source Code Files See the Data Definition Language (DDL) Reference Manual for complete DDL usage information. Caution. Do not attempt to regenerate a DDL dictionary installed by the Pathmaker product from DDL source code. Pathmaker application design information will be lost. Compiling With New Host-Language Source Code Files HP products that supply DDL host-language files have been generated with H-series DDL.
Converting Data Definition Language (DDL) Compiling With New Host-Language Source Code Files TNS/E Native Application Conversion Guide —529659-003 7 -4
8 Converting Programs That Run in the Common Run-Time Environment The Common Run-Time Environment (CRE) coordinates many run-time tasks on behalf of the language-specific run-time libraries to provide a common environment for all routines in a program, regardless of their languages. Most programs use CRE services implicitly by calling language specific run-time libraries, such as the C run-time library, which in turn call the CRE.
Converting Programs That Run in the Common RunTime Environment Specifying Header Files Specifying Header Files Separate TAL and pTAL header files describe the external declarations of CRE functions.
Converting Programs That Run in the Common RunTime Environment Standard Math Functions Standard Math Functions These CRE standard math functions cannot be called by native programs.Table 8-1 lists the obsolete functions and suggests replacement functions. COBOL programs can call either the COBOL intrinsic functions or the other suggested replacement functions. Table 8-1.
Converting Programs That Run in the Common RunTime Environment Standard Math Functions Table 8-1. Obsolete Standard Math Functions (page 2 of 3) Suggested Replacement Obsolete Function CRE_Mod_Int16_ RTL_Mod_Int16_ CRE_Mod_Int32_ RTL_Mod_Int32_ CRE_Mod_Int64_ RTL_Mod_Int64_ RTL_Mod_Real32_ RTL_Mod_Real64_ COBOL Only All Languages (including COBOL) MOD modf() RTL_Normalize_Real64_ frexp() RTL_Odd_Int32_ Write your own function that determines whether a value is even or odd.
Converting Programs That Run in the Common RunTime Environment String Functions Table 8-1. Obsolete Standard Math Functions (page 3 of 3) Suggested Replacement Obsolete Function COBOL Only RTL_Sign_Int16_ RTL_Sign_Int32_ RTL_Sign_Int64_ RTL_Sign_Real32_ RTL_Sign_Real64_ RTL_Sin_Real32_ RTL_Sin_Real64_ All Languages (including COBOL) Write your own function that returns its first parameter with the sign set according to its second parameter.
Converting Programs That Run in the Common RunTime Environment String Functions Table 8-2. Obsolete String Functions (page 2 of 3) Obsolete Function Suggested Replacement RTL_Stccpy_ RTL_StccpyX_ strcpy() RTL_Stcd_I_ RTL_Stcd_IX_ strtol() in the native C run-time library RTL_Stcd_L_ RTL_Stcd_LX_ strtol() in the native C run-time library RTL_Stch_I_ RTL_Stch_IX_ strtol() in the native C run-time library RTL_Stci_D_ RTL_Stci_DX_ sprintf() with a %d conversion specifier.
Converting Programs That Run in the Common RunTime Environment Memory Block Functions Table 8-2.
Converting Programs That Run in the Common RunTime Environment Exception-Handling Functions Exception-Handling Functions The CRE_Stacktrace_ function has separate TAL and pTAL declarations to support the TNS and native stack architectures. See the CRE Programmer’s Guide for details.
9 Converting Programs That Share Data This section describes the conversion tasks related to: • • Sharing Data Between TNS and TNS/E Native Programs Sharing Data Between pTAL Programs and Native C or C++ Programs on page 9-2 Shared data objects can include parameters, structures, messages, database entries, and disk records. Note. If DDL is used to define shared data objects and generate source code, see Section 7, Converting Data Definition Language (DDL).
Converting Programs That Share Data Sharing Data Between pTAL Programs and Native C or C++ Programs Sharing Data Between pTAL Programs and Native C or C++ Programs The native C and C++ compilers align data for the optimal performance of C and C++ programs on the TNS/E platform by default (pragma FIELDALIGN AUTO). The pTAL compiler aligns data for the optimal performance of pTAL programs on the TNS/E platform by default (directive FIELDALIGN AUTO).
10 Converting Programs With Guardian API Calls This section describes the changes you must make to Guardian application program interface (API) calls in programs you convert to TNS/E native mode.
Converting Programs With Guardian API Calls ADDRTOPROCNAME ADDRTOPROCNAME The ADDRTOPROCNAME procedure takes a P register value and stack marker ENV value and returns the associated symbolic procedure name and various optional items that describe the procedure in detail. Native processes cannot call the ADDRTOPROCNAME procedure because native processes do not have P or ENV registers. Remove calls to ADDRTOPROCNAME from your program.
Converting Programs With Guardian API Calls CHECKPOINT These procedures include sigactioninit(), sigactionrestore(), and sigactionsupplant() in C and SIGACTION_INIT_, SIGACTION_RESTORE_, and SIGACTION_SUPPLANT_ in pTAL. The HP signals extensions are provided as convenience tools that allow native processes to catch signals corresponding to trap conditions in TNS processes. The HP signals extensions provide shortcuts to the same base functions provided by the standard signals API.
Converting Programs With Guardian API Calls CURRENTSPACE CURRENTSPACE The CURRENTSPACE procedure returns the ENV register (as saved in the stack marker) and the space ID of the caller. Native processes do not have the same register and space ID architecture as TNS processes. Remove calls to CURRENTSPACE from your program. If your program’s logic relies on TNS process architecture, significant recoding of your application to support native process architecture is required.
Converting Programs With Guardian API Calls XSTACKTEST XSTACKTEST The XSTACKTEST procedure ensures that adequate stack space is available and returns a set of constants to be used with the XBNDSTEST procedure. If XSTACKTEST is called to return constants passed to the XBNDSTEST procedure, delete the XSTACKTEST procedure, because native programs cannot call the XBNDSTEST procedure. For details, see XBNDSTEST on page 10-4 for more details.
Converting Programs With Guardian API Calls CHECK^FILE CHECK^FILE The CHECK^FILE procedure retrieves the file characteristics of a specified file. There are two versions of the CHECK^FILE procedure: one for TNS programs and one for native programs. Separate TNS and native versions are required because pTAL uses separate data types for passing and returning integer and address parameter values. For TNS programs, the procedure passes integer and address values through a type INT parameter.
Converting Programs With Guardian API Calls Using Procedures Enhanced to Support the Native Architecture Using Procedures Enhanced to Support the Native Architecture These procedures have been enhanced to support native processes, native object files, and DLLs: NEWPROCESS NEWPROCESSNOWAIT OBJECTFILE_GETINFOLIST_ PROCESS_CREATE_ PROCESS_GETINFOLIST_ PROCESSINFO PROCESS_SETINFO_ PROCESS_SPAWN_ Depending on the operations performed by these procedures, you might need to specify new or different parameters.
Converting Programs With Guardian API Calls Using Procedures Affected by KMSF Native processes do not use swap volume or file values specified by these procedures, so those input values are ignored. The PROCESSINFO and PROCESS_GETINFO_ procedures return the volume and file names (if specified). The values returned are the names specified when the process was created, not the actual swap volume managed by KMSF. Note.
Converting Programs With Guardian API Calls Using Procedures With pTAL Address Types Using Procedures With pTAL Address Types These procedures use pTAL data types that support the address types WADDR, BADDR, EXTADDR, and PROCPTR: ADDRESS_DELIMIT_ INITIALIZER SORTERROR AWAITIO MEASWRITE_DIFF_ SORTERRORDETAIL AWAITIOX NUMIN SORTERRORSUM CHECK^FILE POOL_CHECK_ SORTMERGEFINISH DNUMIN PROCESS_SPAWN_ SORTMERGERECEIVE ENFORMSTART SEGMENT_ALLOCATE_ SORTMERGESEND GETPOOL SEGMENT_GETINFO_ SORTME
Converting Programs With Guardian API Calls Adjusting for Increased DCT Limits names. See the H06.nn Software Installation and Upgrade Guide for installation details. Adjusting for Increased DCT Limits This change can affect TAL programs that you are converting to TNS/E pTAL. The destination control table (DCT) contains entries for logical device numbers and named processes. The DCT limit refers to the maximum number of logical device numbers and named processes that the operating system can accommodate.
Adjusting for Increased DCT Limits Converting Programs With Guardian API Calls The recommended solution is to replace the affected procedures with updated procedures that can handle the increased DCT limits.
Converting Programs With Guardian API Calls Adjusting for Increased DCT Limits TNS/E Native Application Conversion Guide —529659-003 10 -12
11 OSS API and Utilities Conversion Tasks The OSS environment provides an industry-standard API and set of utilities for Integrity NonStop servers.. This section describes the OSS API changes required to convert TNS programs to TNS/E native mode. It also describes changes required to the cobol, c89 and c99 utility command lines to run the TNS/E native COBOL and C/C++ compilers.
COBOL Compilation System OSS API and Utilities Conversion Tasks Table 11-1. COBOL Flag Changes Required: TNS to TNS/E Changed TNS cobol Utility Flag Reason for Change Action Required -Waxcel Accelerator unnecessary because TNS/E native compilers generate Itanium instructions. Remove flag. -Wbind eld utility used instead of Binder for TNS/E native programs. Remove flag. Some -Wbind arguments (such as for setting object file attributes) have corresponding ecobol or eld flags.
Native C Compilation System OSS API and Utilities Conversion Tasks Native C Compilation System Table 11-2 shows the c89 flags that must be changed when moving from TNS mode to TNS/E native mode. Table 11-2. c89 Flag Changes Required: TNS to TNS/E Native (page 1 of 2) Changed TNS c89 Utility Flag Reason for Change Action Required -O Accelerator unnecessary because TNS/E native compilers generate Itanium instructions. Flag now specifies native compiler optimization level. Remove flag.
OSS API and Utilities Conversion Tasks Native C Compilation System Table 11-2. c89 Flag Changes Required: TNS to TNS/E Native (page 2 of 2) Changed TNS c89 Utility Flag -Wcfront Reason for Change Action Required cfront function performed by component of TNS/E native compilers. Replace with -WP flag. No arguments can be passed. Most -Wcfront arguments (such as pragmas) have corresponding native c89 or c99 flags. Specify corresponding c89 or c99 flags.
OSS API and Utilities Conversion Tasks Using System Calls Enhanced to Support the Native Architecture Using System Calls Enhanced to Support the Native Architecture These OSS system calls have been enhanced to support native processes, native object files, and DLLs: tdm_execve tdm_execvep tdm_fork tdm_spawn tdm_spawnp Depending on the operations that your TNS programs perform with these functions, you might need to specify new or different parameters.
OSS API and Utilities Conversion Tasks Specifying Files in the Guardian File System (/G) Specifying Files in the Guardian File System (/G) To specify files in the Guardian file system, use OSS pathname syntax (/G/volume/subvol/file). Product versions of the TNS c89 utility prior to D40 do not require files in the Guardian file system to be identified with a suffix. (The OSS file system requires files to be identified with a suffix.
Glossary accelerate. To speed up emulated execution of a TNS object file by applying the Accelerator for TNS/R system execution or the Object Code Accelerator (OCA) for TNS/E system execution before running the object file. accelerated mode. See TNS accelerated mode. accelerated object code.
eld utility Glossary from the main program and other independent libraries. The same DLL can be used by more than one process. Each process gets its own copy of DLL static data. Contrast with shared run-time library (SRL). See also position-independent code (PIC). eld utility. A utility that collects, links, and modifies code and data blocks from one or more TNS/E object files to produce a target TNS/E native loadfile. See also nld utility, ld utility, and Binder. ELF.
Glossary HP NonStop Open System Services (OSS) environment that run in the OSS environment usually use the OSS application program interface. Interactive users of the OSS environment usually use the OSS shell for their command interpreter. See also HP NonStop Open System Services (OSS) environment. Contrast with Guardian. HP NonStop Open System Services (OSS) environment. The HP NonStop™ Open System Services (OSS) application program interface (API), tools, and utilities. HP NonStop™ operating system.
loadfile Glossary address space, and resolves symbol references among them. Synonyms include run-time loader and run-time linker. The loader for TNS and for TNS/R native programs and libraries that are not position-independent code (PIC) is part of the operating system. For PIC loadfiles, a loader called rld works with the operating system to load programs and libraries. loadfile. An executable object code file that is ready for loading into memory and executing on the computer.
Object Code Interpreter (OCI) Glossary file with equivalent Itanium instructions. TNS object code that is accelerated runs faster than TNS object code that is not accelerated. See also Accelerator and Object Code Interpreter (OCI). Object Code Interpreter (OCI). A program that processes a TNS object file and emulates TNS instructions on a TNS/E system without preprocessing the object file. See also Object Code Accelerator (OCA). object file.
pTAL compiler Glossary pTAL compiler. An optimizing native-mode compiler for the pTAL language. public dynamic-link library (public DLL). Optional native-mode executable code modules available to all native user processes. A TNS/E public library is specified in the public library registry, supplied by HP or optionally a user. public library.
TNS Glossary TNS. Fault-tolerant HP computers that support the HP NonStop™ operating system and are based on microcoded complex instruction-set computing (CISC) technology. TNS systems run the TNS instruction set. Contrast with TNS/R and TNS/E. TNS accelerated mode. A TNS emulation environment on a TNS/R or TNS/E system in which accelerated TNS object files are run. TNS instructions have been previously translated into optimized sequences of RISC or Intel® Itanium® instructions.
Glossary TNS shared run-time library (TNS SRL) not, with automatic switching between accelerated and interpreted modes on calls and returns between those parts. Contrast with TNS/R native process and TNS/E native process. TNS shared run-time library (TNS SRL). An SRL available to a TNS process in the OSS environment on TNS/R systems. A TNS process can have only one TNS SRL. A TNS SRL is implemented as a special user library that allows shared global data. TNS user library.
TNS/R Glossary TNS/R. Fault-tolerant HP computers that support the HP NonStop™ operating system and are based on 32-bit reduced instruction-set computing (RISC) technology. TNS/R systems run the MIPS-1 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 native C compiler. The C compiler that generates TNS/R object files.
user library Glossary TNS/E Native Application Conversion Guide —529659-003 Glossary -10
Index Numbers B 16-bit data model 1-6, 1-7, 3-3, 3-18 32-bit data model 1-6, 1-7, 3-3, 3-18 32-bit pointers 3-5 64-bit logical operation functions 8-8 Backup, active 3-14 BADDR data type 10-9 Banners, compiler 3-17 Binder utility 1-8, 3-16, 6-3, 11-2, 11-3 Binding 1-8 BLANK directive 4-6 A Accelerated mode 1-2 Accelerator utility 11-2, 11-3 ACOS function 8-3 Active backup 3-14 ADDRESS_DELIMIT_ procedure 10-4, 10-9 ADDRTOPROCNAME procedure 10-2 alias keyword 3-5 Alignment, data 2-6, 2-8 Allocation, data
C Index user library 6-1 variable keyword 3-5 warnings 3-2, 3-16 #include 3-2 _cc_status keyword 3-5 _lowmem keyword 3-5 _tal keyword 3-5 _variable keyword 3-5 C library functions alternate-model I/O 3-9 close 3-10 creat 3-10 ecvt 3-11 edlseek 3-10 exit 3-11 fcloseall 3-10 fcntl 3-10 fdopen 3-10 fdtogfn 3-10 fileno 3-10 fscanf 3-11 internationalization 1-8 iscsym 3-8 iscsymf 3-8 ISO/ANSI C Standard 3-7 I/O 3-9 lastreceive 3-10 lseek 3-10 memswap 3-8 movmem 3-8 open 3-10 read 3-10 readupdate 3-10 receivein
C Index CALL_SHARED directive 6-2 CALL_SHARED pragma 6-2 CCE macro 3-6 CCG macro 3-6 CCL macro 3-6 CCOMP command 3-2 cc_status keyword 3-5 CEXTDECS 2-3 Cfront 11-3 CHECK pragma 3-17 Checking condition codes 3-6 CHECKMONITOR procedure 10-8 CHECKPOINT procedure 10-3 Checkpointing 10-3 CHECKPOINTMANY procedure 10-3 CHECKPOINTMANYX procedure 10-3 CHECKPOINTX procedure 10-3 CHECK^FILE procedure 10-6, 10-9 Class library, Tools.
C Index GPLDECS file 10-6 maintaining 2-3 Common source, maintaining 10-6 Common Usage C 1-6, 1-7 COMPACT directive 4-9 Compatibility traps 2-8 Compilation system, specifying 11-1 Compilers C 1-6 COBOL 1-7 C++ 1-6 load maps 3-17 pragmas 11-5 pTAL 1-5 SQL 1-12, 3-16, 11-6 TAL 1-5 warnings 3-2 complement function 8-8 Condition codes 3-6 CONSULT directive 4-5, 4-6 Conversion preparation 2-2 strategy 2-1/2-9 Conversion tasks C 3-1/3-18 COBOL 4-1/4-11 CRE 8-1/8-8 C++ 3-1/3-18 DDL 7-1/7-3 Guardian 10-1/10-9 OSS
C Index odd function 8-4 or function 8-8 positive_diff function 8-4 power function 8-4 power2 function 8-4 pTAL procedures 8-1 random_next_ function 8-4 random_set_ function 8-4 remainder function 8-8 round function 8-4 shift_left function 8-8 shift_right function 8-8 sign function 8-5 signal handler 8-2 sin function 8-5 sinh function 8-5 split function 8-5 sqrt function 8-5 stcarg function 8-5 stccpy function 8-6 stcd_i function 8-6 stcd_l function 8-6 stch_i function 8-6 stci_d function 8-6 stcpm functi
D Index data model 1-7, 3-3, 3-18 errors 3-2 external functions 3-5 filebuf class 3-14 fstream class 3-14 HP extensions 3-2 keywords 3-5 memory model 1-7, 3-3, 3-18 messages 3-2, 3-16 NMCMT 1-7 NULL pointer 3-2 preprocessor 11-4 run-time library 3-14 user library 6-1 warnings 3-2, 3-16 #include 3-2 D Data alignment default 2-6 determining 2-6 misaligned data 2-7 performance 2-8 round-down behavior 2-7 shared data 9-1 Data blocks 1-8 Data Definition Language See DDL Data layout 7-1 Data misalignment 2-7,
F Index invoked from c89 utility 11-2, 11-3 overview of 1-8 specifying heap attributes 10-8 using SEARCH pragma 3-16 -libname flag 6-3 -ul flag 6-2 ELF format 1-16 Eliminating compatibility traps 2-8 ENFORMSTART procedure 10-9 enoft utility 1-9, 2-8 ENTER statement 4-5, 4-7 Enterprise Toolkit - NonStop Edition 1-9 ENV directive in COBOL 4-5, 4-9, 6-2 in pTAL 6-2 in TAL 8-1 ENV pragma 6-2 ENV register 10-4 Environments development 1-4 execution 1-2 Environment-specific parameters 3-13 errno 3-13 ERRORS pra
G Index memory block 8-7 string 8-5 G GETPOOL procedure 10-9 GETSYNCINFO 10-8 Global data 1-20 Globals-heap segment 1-15, 1-16 GPLDECS file 10-6 gtacl command 6-3 Guardian conversion tasks 10-1/10-9 Guardian file system 11-6 Guardian procedure condition codes 3-6 Guardian procedures ADDRESS_DELIMIT_ 10-4, 10-9 ADDRTOPROCNAME 10-2 ARMTRAP 10-2 AWAITIO 10-9 AWAITIOX 10-9 CHECKMONITOR 10-8 CHECKPOINT 10-3 CHECKPOINTMANY 10-3 CHECKPOINTMANYX procedure 10-3 CHECKPOINTX procedure 10-3 CHECK^FILE 10-6, 10-9 CLO
H Index H ANSI-model 3-9 Header files CLUDECS 8-2 CLURDECS 8-2 CRE 8-2 CREDECS 8-2 CRERDECS 8-2 crtlnsh 3-14 nonstoph 3-14 RTLDECS 8-2 RTLRDECS 8-2 tal.
M Index Layout, data 7-1 level 2-5 Libraries cnonstop 3-14 crtlns 3-14 See also DLLs supplied by HP 1-18 See also user library LIBRARY directive in COBOL 4-5, 4-6 in TAL 6-3 Linking user library 6-2 with c89 flags 11-2, 11-3 with eld utility 1-8 LMAP directive 4-10 LMAP pragma 3-17 ln function 8-3 Load maps 3-17 LOG function 8-3 LOG10 function 8-3 log10 function 8-3 longjmp() and setjmp() use in inline functions 3-12 lower function 8-3 lowmem keyword 3-5 lseek function 3-10 M Macros CCE 3-6 CCG 3-6 CCL 3
O Index Guardian files 11-6 SQL compilation 11-6 -O flag 11-3 -Weld flag 11-2, 11-4 -Wnolink flag 11-4 -WP flag 11-3 -Wsqlcomp flag 11-4 -Wsqlmx flag 11-4 Native compilers C 1-6, 1-7 COBOL 1-7 C++ compiler 1-6 data alignment of 9-1 DDL data alignment 7-1 default optimization 2-6 object file format 1-16 optimization determining level of 2-5 pTAL 1-5 Native development 1-4 Native Inspect debugging tool 1-12 Native linker 1-8 Native mode benefits of 1-22 compared to accelerated mode 1-4 constraints of 1-23 d
P Index Object files executable 1-16 format of 1-16 relinkable 1-16 OBJECTFILE_GETINFOLIST_ procedure 10-7 Obsolete C functions 3-7 C keywords 3-5 Guardian procedures 10-1/10-5 pragmas 3-17 OCA 1-2, 2-1 odd function 8-4 OLDCALLS pragma 3-17 open function 3-10 Open System Services See OSS conversion tasks and OSS fucntions OPEN^FILE procedure 10-5 Optimization and pTAL 1-5 Optimization level 2-5 OPTIMIZE directive 2-6 OPTIMIZE pragma 2-6, 3-16 or function 8-8 OSS conversion tasks 11-1/11-6 OSS functions td
R Index NOWARN 3-16 NOWIDE 3-3, 3-18 NOXMEM 3-3, 3-18 NOXVAR 3-18 obsolete 3-17 OLDCALLS 3-17 OPTIMIZE 2-6, 3-16 REFALIGNED 2-6, 2-8 SEARCH 3-16 SQL 3-16, 11-4 SQLMEM 3-17 SSV 3-16 STRICT 3-17 SYSTYPE 3-3 TRIGRAPH 3-17 VERBOSE 3-17, 11-4 WARN 3-16 WIDE 3-3, 3-18 XMEM 3-3, 3-18 XVAR 3-18 Pragmas, specifying to c89 11-5 Preparing for conversion 2-2 Preprocessor, C and C++ 11-4 Privileged memory stack 1-15 Privileged RISC stack 1-15 Privileged stack segment 1-20 Procedure optimization 2-6 Process creation fu
S Index RISC stack 1-15 round function 8-4 ROUNDED phrase 4-7 Round-down behavior of misaligned data 2-7 RSE backing store segment 1-15, 1-20 RTLDECS file 8-2 RTLRDECS file 8-2 RTL_ functions See also function name without prefix header files 8-2 RUN command, LIB option of 6-3 RUNNABLE directive 4-11 RUNNAMED directive 4-6 S SAVEABEND directive 4-6 scanf function 3-11 SEARCH directive 4-5, 4-7 SEARCH pragma 3-16 Search subvolume 3-16 Segments, data 10-8 SEGMENT_ALLOCATE_ procedure 10-9 SEGMENT_GETINFO_ p
T Index stccpy function 8-6 stccpy functions 3-8 stcd_i function 8-6 stcd_i functions 3-8 stcd_l function 8-6 stcd_l functions 3-8 stch_i function 8-6 stch_i functions 3-8 stcis functions 3-8 stcisn functions 3-8 stci_d function 8-6 stci_d functions 3-8 stclen functions 3-8 stcpm function 8-6 stcpm functions 3-9 stcpma function 8-6 stcpma functions 3-9 stcu_d function 8-6 stcu_d functions 3-9 stpblk function 8-6 stpblk functions 3-9 stpbrk functions 3-9 stpchr functions 3-9 stpsym function 8-6 stpsym func
U Index replaced by ETK 1-9 tanh function 8-5 tdm_execve function 11-5 tdm_execvp function 11-5 tdm_fork function 11-5 tdm_spawn function 11-5 tdm_spawnp function 11-5 terminate_program function 3-11 32-bit data model 1-6, 1-7, 3-3, 3-18 Threads, using 10-9 tmpfile function 3-13 tmpnam function 3-13 TNS accelerated mode 1-4, 1-13 TNS architecture characteristics of 1-4 ENV register 10-4 ’G’ relative address 10-4 TNS c89 utility compiler pragmas 11-5 conversion tasks 11-5/11-6 Guardian files 11-6 SQL compi
V Index V variable keyword 3-5 VERBOSE pragma 3-17, 11-4 Virtual memory 1-19 Visual Inspect symbolic debugger 1-10 Volumes search 3-16 swap 10-7 _cc_status type specifier 3-6 _is_system_trap function 3-8 _lowmem keyword 3-5 _status_eq(x) macro 3-6 _status_gt(x) macro 3-6 _status_lt(x) macro 3-6 _tal keyword 3-5 ’main’ procedure 8-1 W WADDR data type 10-9 WAIT^FILE procedure 10-5 WARN pragma 3-16 Warnings, C and C++ compilers 3-2 WIDE pragma 3-3, 3-18 write function 3-10 writeread function 3-10 WRITE^FIL
Special Characters Index TNS/E Native Application Conversion Guide —529659-003 Index -18
