TNS/R Native Application Migration Guide Abstract This manual introduces the HP NonStop™ Series/RISC (TNS/R) native development and execution environments and explains how to migrate existing HP NonStop Series (TNS) applications to TNS/R native applications. Product Version NA Supported Release Version Updates (RVUs) This manual supports D44.01 and all subsequent RVUs until otherwise indicated in a new edition.
Document History Part Number Product Version Published 115742 NA December 1995 127640 NA July 1996 136525 NA September 1997 523745-001 NA May 2003
TNS/R Native Application Migration Guide Glossary Index What’s New in This Manual vii Manual Information vii New and Changed Information Examples Figures Tables viii About This Manual Audience ix Purpose x Organization xi Where to Go for More Information Your Comments Invited xiv Notation Conventions xiv xii 1.
1. Introduction to Native Mode (continued) Contents 1. Introduction to Native Mode (continued) Native Architecture Features 1-10 Native Process Environment 1-10 Native Object File Format 1-13 Signals Facility 1-13 Shared Run-Time Libraries (SRLs) 1-14 Kernel-Managed Swap Facility (KMSF) 1-16 Benefits of Native Mode 1-18 Constraints of Native Mode 1-19 2.
3. C and C++ Migration Tasks (continued) Contents 3. C and C++ Migration Tasks (continued) Checking Changed Pragmas 3-18 Removing Obsolete Pragmas 3-19 4. COBOL85 Migration Tasks Migrating COBOL85 Programs 4-1 Changing the Source Program 4-4 General Migration Tasks 4-4 Removal Required 4-4 Possible Changes Required 4-6 Removal Optional 4-8 New Features 4-9 Using the Inspect Debugger for Native COBOL85 Programs 4-10 5. TAL to pTAL Conversion Tasks 6.
9. Guardian API Migration Tasks Contents 9.
Examples Contents Examples Example 3-1. Example 5-1. Examining _cc_status 3-9 pTAL Compiler Listing With Syntax Checking 5-2 Figures Figure 1-1. Figure 1-2. Native Mode Benefits All Programs 1-3 C Run-Time Library Organization 1-15 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 10-1.
Contents TNS/R Native Application Migration Guide —523745-001 vi
What’s New in This Manual Manual Information TNS/R Native Application Migration Guide Abstract This manual introduces the HP NonStop™ Series/RISC (TNS/R) native development and execution environments and explains how to migrate existing HP NonStop Series (TNS) applications to TNS/R native applications. Product Version NA Supported Release Version Updates (RVUs) This manual supports D44.01 and all subsequent RVUs until otherwise indicated in a new edition.
New and Changed Information What’s New in This Manual New and Changed Information • • • • • This publication has been updated to reflect new product names: ° Because product names are changing over time, this publication might contain both HP and Compaq product names. ° Product names in graphic representations are consistent with the current product interface.
About This Manual • • • • • • Audience on page ix Purpose on page x Organization on page xi Where to Go for More Information on page xii Your Comments Invited on page xiv Notation Conventions on page xiv Audience This manual is for people who manage or write applications for HP NonStop servers.
Purpose This document is designed to help you perform the following tasks: • • • • • • • • • • • Learn about the TNS/R native execution and development environment and how it differs from the TNS environment. Determine which programs can be migrated and the effort required to migrate them. Plan a migration strategy. Migrate programs written in HP C for NonStop Systems and HP C++ for NonStop Systems from TNS to native mode. Migrate programs written in HP COBOL85 for NonStop Systems from TNS to native mode.
Organization This manual contains these sections: Section Explains Section 1, Introduction to Native Mode Native development and execution environments, features of native architecture, and benefits and constraints of native mode Section 2, Developing a Migration Strategy How to prepare programs for migration, plan system resources, determine which programs to migrate, maintain common TNS and native source files, and maximize the performance of native programs Section 3, C and C++ Migration Tasks How
Where to Go for More Information Manual Explains (page 1 of 2) Accelerator Manual How to improve performance of TNS programs running on TNS/R systems (migrating them to 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 HP C and HP C++ programming languages, compilers, and run-time libraries COBOL85 for NonStop Systems Manual The COBOL85 programming language, com
Manual Explains (page 2 of 2) Kernel-Managed Swap Facility (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 nld and noft Manual How to use the nld utility to link native object files.
Hypertext Links Your Comments Invited After using this manual, please take a moment to send us your comments. You can do this by: • • • Completing the online Contact NonStop Publications form if you have Internet access. Faxing or mailing the form, which is included as a separate file in Total Information Manager (TIM) collections and located at the back of printed manuals. Our fax number and mailing address are included on the form. Sending an e-mail message to the address included on the form.
General Syntax Notation lowercase italic letters. Lowercase italic letters indicate variable items that you supply. Items not enclosed in brackets are required. For example: file-name computer type. Computer type letters within text indicate C and Open System Services (OSS) keywords and reserved words; enter these items exactly as shown. Items not enclosed in brackets are required. For example: myfile.c italic computer type.
General Syntax Notation … Ellipsis. An ellipsis immediately following a pair of brackets or braces indicates that you can repeat the enclosed sequence of syntax items any number of times. For example: M address [ , new-value ]… [ - ] {0|1|2|3|4|5|6|7|8|9}… An ellipsis immediately following a single syntax item indicates that you can repeat that syntax item any number of times. For example: "s-char…" Punctuation.
Notation for Messages !i:i. In procedure calls, the !i:i notation follows an input string parameter that has a corresponding parameter specifying the length of the string in bytes. For example: error := FILENAME_COMPARE_ ( filename1:length , filename2:length ) ; !i:i !i:i !o:i. In procedure calls, the !o:i notation follows an output buffer parameter that has a corresponding input parameter specifying the maximum length of the output buffer in bytes.
Notation for Management Programming Interfaces { } Braces. A group of items enclosed in braces is a list of all possible items that can be displayed, of which one is actually displayed. The items in the list might 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.
Change Bar Notation Change Bar Notation Change bars are used to indicate substantive differences between this edition of the manual and the preceding edition. Change bars are vertical rules placed in the right margin of changed portions of text, figures, tables, examples, and so on. Change bars highlight new or revised information. For example: The message types specified in the REPORT clause are different in the COBOL85 environment and the Common Run-Time Environment (CRE).
Change Bar Notation TNS/R Native Application Migration Guide —523745-001 xx
1 Introduction to Native Mode HP NonStop Series/RISC (TNS/R) native mode enables you to write programs that are fully optimized for TNS/R systems such as NonStop servers. The term “TNS/R native” means the program uses the process, memory, and instruction set architectures that are native to RISC processors. New native compilers and tools are used to generate native programs. Other tools have been enhanced to support native programs.
Summary of Execution Modes Introduction to Native Mode Summary of Execution Modes A TNS process—a process that runs in TNS mode or accelerated mode—is initiated by running a TNS 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 RISC 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 on page 1-3, because the D20 RVU HP has converted an increasing amount of system code, system library routines, and other products to run in native mode. (Shaded regions in the figure indicate code that runs, at least in part, 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 RISC instructions, most native object code has a significant performance advantage over accelerated object code. The Accelerator cannot produce RISC 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 Native C Compiler The native C compiler accepts C language source files that comply with either the ISO/ANSI C Standard or Common Usage C (sometimes called Kernighan and Ritchie C or K&R C). The native C compiler also accepts HP language extensions. The native C compiler can be run in the Guardian and OSS environments and on the PC as part of ETK or TDS. The NMC command runs the compiler in the Guardian environment.
Introduction to Native Mode Native COBOL85 Compiler The native C++ compiler provides a more powerful and simplified development environment than TNS Cfront. For example, you must run the C preprocessor, Cfront, the TNS C compiler, Binder, and the Accelerator to create an executable accelerated C++ program. In comparison, you run only the native C++ compiler and nld utility to create an executable native C++ program.
Introduction to Native Mode Native Link Editor (nld Utility) Native Link Editor (nld Utility) The native link editor, or nld utility, links one or more native object files (files generated by the native compilers or nld) to produce either an executable or linkable native object file. (For more information, see Native Object File Format on page 1-13.) nld can also modify process attributes, such as HIGHPIN, of executable native object files and strip nonessential information from native object files.
Introduction to Native Mode Inspect and Visual Inspect Symbolic Debuggers and Debug Facility Inspect and Visual Inspect Symbolic Debuggers and Debug Facility The Inspect and Visual Inspect symbolic debuggers and the Debug tool can be used to debug TNS and native processes. The Inspect, Visual Inspect, and Debug products have been enhanced to support native processes. Most Inspect, Visual Inspect, and Debug commands apply to both TNS and native processes.
Introduction to Native Mode Data Definition Language (DDL) Data Definition Language (DDL) The D40 version of the DDL compiler generates host-language source files that can be used with both TNS and native programs. The DDL compiler inserts pragmas in C and directives in pTAL and COBOL85 host-language source files to ensure that the same data alignment is generated, regardless of whether a TNS or native compiler is used. For details, see Section 7, Data Definition Language (DDL) Migration Tasks.
Introduction to Native Mode Native Process Environment Process Organization Executable code for a process is contained in the following objects: • • • • The initial program of the process, called user code. This code is read from the program file. A system library containing system-related procedures. This includes operating system code that is accessible by the process using system procedure calls. Optionally, a user library containing code that can be shared among several applications.
Introduction to Native Mode Native Process Environment Data Spaces When a process is created, several data segments are allocated for its use.
Introduction to Native Mode Native Object File Format Native Object File Format Native object files use a different file format from that of TNS or accelerated object files. Native object files are in Executable and Linking Format (ELF), a standard format used for UNIX object files, with HP extensions. The native object file format is the same in the Guardian and OSS environments and on the PC as part of ETK or TDS. Native object files are type 700 files in the Guardian environment.
Introduction to Native Mode Shared Run-Time Libraries (SRLs) Shared Run-Time Libraries (SRLs) There are two types of shared run-time libraries (SRLs): public and private. HP supplies public SRLs; you cannot create your own. A process can have multiple public SRLs. You can create your own private SRLs. A process can have only one private SRL. A private SRL is a native user library. This subsection describes public SRLs. For details on private SRLs, see Section 6, User Library Migration Tasks.
Shared Run-Time Libraries (SRLs) Introduction to Native Mode Figure 1-2. C Run-Time Library Organization C-Series TNS C Programs D-Series TNS C Programs Native C Programs Application Code Application Code Application Code C Run-Time Library (Model-Dependent) C Run-Time Library (Initialization) C Run-Time Library (Model-Dependent) C Run-Time Library (Model-Independent) Application Program System C Run-Time Library SRL C Run-Time Library (Model-Independent) CRE Library CRE Library SRL VST002.
Introduction to Native Mode Kernel-Managed Swap Facility (KMSF) Kernel-Managed Swap Facility (KMSF) A swap file is a disk file used for copying data between physical memory and disk storage. Pages of memory are swapped to disk when physical memory is needed, and swapped back to physical memory when the data is needed. Beginning with the D4x and Gxx RVUs, the Kernel-Managed Swap Facility (KMSF) manages virtual memory using swap files under its control.
Kernel-Managed Swap Facility (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 Native mode provides many benefits: • General ° ° ° ° • • Native code often runs significantly faster than TNS and 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 1MB (expandable to 32MB), which is significantly larger than the 64K stack limit for TNS processes.
Introduction to Native Mode ° Constraints of Native Mode Native shared run-time libraries (SRLs) are consulted automatically If a TNS COBOL85 program calls utility routines, it must put the libraries that contain those routines (one or more of COBOLLIB, CBL85UTL, and CLULIB) on search lists (using the compiler directives SEARCH, LIBRARY, and CONSULT). For a native COBOL85 program, search lists are optional.
Introduction to Native Mode TNS/R Native Application Migration Guide —523745-001 1- 20 Constraints of Native Mode
2 Developing a Migration Strategy This section describes the decisions you must make to migrate a program to native mode, including: • • • • • • • Determining Which Programs to Migrate Preparing Programs for Migration on page 2-2 Planning System Resources on page 2-2 Maintaining Common Source Code for TNS and Native Compilers on page 2-3 Determining Optimization Levels on page 2-4 Determining Data Alignment on page 2-5 Tuning the Performance of Native Programs on page 2-6 Determining Which Programs to Mi
Developing a Migration Strategy Preparing Programs for Migration Another issue to consider when migrating is the effort required to migrate the program. It is not a trivial matter to migrate programs that rely significantly on TNS hardware and process architecture. For example, a program that explicitly manipulates the P-register probably requires significant changes to migrate to native mode.
Developing a Migration Strategy Maintaining Common Source Code for TNS and Native Compilers Maintaining Common Source Code for TNS and Native Compilers If your program requires few changes to migrate 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 migrate to native mode, maintaining common source code is impractical.
Determining Optimization Levels Developing a Migration Strategy In some cases, two logically equivalent but syntactically different fragments of code might be required: one for the TNS compilers and one for the native compilers. Such code can be isolated within a source file for conditional compilation: Language For conditional compilation, use ... For more information, see ...
Developing a Migration Strategy Determining Data Alignment For C, C++, and pTAL optimization can be set on a module or procedure basis. Thus, native programs can contain modules or procedures compiled at different optimization levels. This hybrid approach can be taken to improve program performance but maintain as much symbolic debugging support as possible. With this hybrid approach, you compile performance-critical code at optimization level 2 and the remainder at optimization level 1.
Developing a Migration Strategy Tuning the Performance of Native Programs Another strategy is to set the FIELDALIGN CSHARED2 and REFALIGNED 2 pragmas or the FIELDALIGN SHARED2 and REFALIGNED 2 directives when you first start migrating a program. Once the program has been migrated to native mode and runs correctly, you can remove the pragmas or directives and recompile the program. You can then resolve any problems caused by data misalignment.
Developing a Migration Strategy Eliminating Compatibility Traps Eliminating Compatibility Traps In most cases, data misalignment in data objects and reference misalignment in pointers cause traps. To eliminate compatibility traps caused by data misalignment in data objects, specify a FIELDALIGN SHARED2 pragma or directive for the misaligned data object.
Developing a Migration Strategy Eliminating Compatibility Traps TNS/R Native Application Migration Guide —523745-001 2 -8
3 C and C++ Migration Tasks This section describes how to migrate C and C++ programs to TNS/R native mode.
Using the Native C and C++ Migration Tool C and C++ Migration Tasks This section assumes your program can be compiled by a D20 or later version of the TNS C compiler or TNS C++ preprocessor. It also assumes your program runs on a D20 or later version of the operating system. See the C/C++ Programmer’s Guide for information on converting C programs from C-series to D-series RVUs.
Running NMCMT in the Guardian Environment C and C++ Migration Tasks listing specifies a Guardian filename to which NMCMT writes the diagnostic listing. The file can be type 101 (edit file) or type 129 (spooler file). If you specify a disk file name and the file does not exist, NMCMT creates a type 101 file. If the specified file exists, NMCMT attempts to purge the file. If you omit the OUT option, NMCMT writes the listing to your current default output file.
Running nmcmt in the OSS Environment C and C++ Migration Tasks Running nmcmt in the OSS Environment The nmcmt utility is located in the /usr/bin directory. The command syntax for nmcmt is a simplified version of the command syntax for the TNS c89 utility, as shown in the following diagram: nmcmt [flag...] source flag is a valid nmcmt flag, where flag is one of the following. -I directory adds directory to the list of directories searched to locate #include files with relative pathnames.
C and C++ Migration Tasks Using the Native C and C++ Compilers Using the Native C and C++ Compilers Both the TNS and TNS/R native C compilers conform to the ISO/ANSI C language standard. Source code that compiles without warnings or errors with the TNS C compiler or C++ preprocessor might get warnings or errors using the native C and C++ compilers. (In most cases, the native compilers are better than the TNS compilers in detecting violations to the ISO/ANSI C standard.
Converting Code to Use 32-Bit Pointers and Integers C and C++ Migration Tasks Converting Code to Use 32-Bit Pointers and Integers The memory model determines the size of pointers. In the TNS C environment, there are two memory models: the small-memory model (16-bit pointers) and the largememory model (32-bit pointers). The data model determines the size of type int. In the TNS C and C++ environments, there are two data models: the 16-bit data model and the 32-bit (or wide) data model.
Replacing Obsolete External Function Declarations C and C++ Migration Tasks • Ensure that the formal and actual parameters of pointer types are matched. The TNS C compiler issues the following warning message if pointers do not match: Warning 30: pointers do not point to same type of object For example: int func1(short *); In the 16-bit data model and the large-memory model, you can pass to func1 a pointer of type short or int and get correct results.
Replacing Obsolete Keywords C and C++ Migration Tasks Replacing Obsolete Keywords D-series TNS C compilers recognize but issue warnings for certain C-series keywords with D-series replacements. The native C compiler does not recognize the C-series keywords. Replace the following C-series keywords with the equivalent D-series keywords: C-Series Keyword D-Series Keyword cc_status _cc_status extensible _extensible extptr See the following paragraph.
Replacing Calls to Obsolete C Library Supplementary Functions C and C++ Migration Tasks Example 3-1. Examining _cc_status Prior to RVU D40 (TNS Programs Only) _tal _extensible _cc_status READX ( ... ); #include ... _cc_status CC; CC = READX ( ... ); if (CC == CCL) { ... } else if (CC == CCG) { ... } RVU D40 and Later (TNS and Native Programs) _tal _extensible _cc_status READX ( ... ); #include ... _cc_status CC; CC = READX ( ... ); if (_status_lt(CC)) { ... } else if (_status_gt(CC)) { .
Replacing Calls to Obsolete C Library Supplementary Functions C and C++ Migration Tasks Table 3-1. Obsolete C Supplementary Functions (page 2 of 3) Obsolete Function Suggested Replacement memswap() Replace memswap() with a series of calls to memcpy() to swap the blocks of memory using a temporary buffer. The order and type of parameters for these two functions are different. movmem() Replace movmem() with a call to memmove(). The order and type of parameters for these two functions are different.
Replacing Calls to Obsolete C Library Guardian Alternate-Model I/O Functions C and C++ Migration Tasks Table 3-1. Obsolete C Supplementary Functions (page 3 of 3) Obsolete Function Suggested Replacement stcu_d() Replace stcu_d() with a call to sprintf() with a %u conversion specifier. stpblk() Replace stpblk() with a call to strspn() with a string of space characters. stpbrk() Replace stpbrk() with a call to strpbrk(). stpchr() Replace stpchr() with a call to strchr().
Replacing Calls to Obsolete C Library Guardian Alternate-Model I/O Functions C and C++ Migration Tasks Table 3-2. Obsolete Guardian Alternate-Model I/O Functions Obsolete Function Suggested Replacement close() Recode in ANSI-model I/O functions or Guardian system procedures. Use OSS versions of function. creat() Recode in ANSI-model I/O functions or Guardian system procedures. Use OSS versions of function. edlseek() Recode in ANSI-model I/O functions or Guardian system procedures.
Checking Calls to Changed C Library Functions C and C++ Migration Tasks Checking Calls to Changed C Library Functions The following functions have changes in ISO/ANSI C standard implementation-defined behavior. These changes affect only Guardian C functions. These changes were made to match the behavior of the TNS OSS environment and the UNIX computer industry.
C and C++ Migration 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().
Changing Code That Relies on Arithmetic Overflow Traps C and C++ Migration Tasks _guardian variant. For example, replace calls to fopen() with either fopen_oss() or fopen_guardian(), as appropriate. Note.
Using Active Backup Programming in C C and C++ Migration Tasks Using Active Backup Programming in C To migrate 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++ Migration Tasks • • On the compiler command line, specify SSV0 $SYSTEM.SYSTEM and SSV1 $SYSTEM.ZRW pragmas to direct the compiler to search for header files first in the system library and then in the Tools.h++ subvolume. On the compiler command line, specify a CPATHEQ "PATHEQIN" pragma to specify the default MAPINCLUDE file to map header file names to the Tools.h++ subvolume files. The PATHEQIN file maps the Tools.h++ source file header.
Checking Changed Pragmas C and C++ Migration Tasks Checking Changed Pragmas For the following pragmas, 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++ Migration Tasks Removing Obsolete Pragmas The native C and C++ compilers do not support the pragmas in Table 3-4 on page 3-19. 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++ Migration Tasks Table 3-4. Obsolete Pragmas (page 2 of 2) Pragma Reason pragma is obsolete Action Required [NO]WIDE Native compilers only generate programs that use 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 only programs that use the largememory model. Remove pragma and recode programs that specify NOXMEM to use the large-memory model.
4 COBOL85 Migration Tasks This section describes how to migrate COBOL85 programs to TNS/R native mode. The compilers to which this section applies are: Compiler T Number TNS COBOL85 T9257 TNS cobol T8498 TNS/R NMCOBOL T8107 TNS/R nmcobol T8107 You can have COBOL85 source programs that can be compiled with the D32.00, D42.00, and D44.00 versions of the COBOL85 compilers and the D44.01 version of the NMCOBOL compiler—“common source code.” The code space limit for a TNS COBOL85 program is 128 KB.
Migrating COBOL85 Programs COBOL85 Migration Tasks 3. If necessary, change your source program (see Changing the Source Program on page 4-4). To learn whether you must change your source program, compile it with the NMCOBOL compiler, which will issue warnings when it encounters source constructs that it does not accept. Running the NMCOBOL compiler with the new DIAGNOSE-85 directive is especially recommended.
Migrating COBOL85 Programs COBOL85 Migration Tasks • Data Alignment The COBOL85 and NMCOBOL compilers generate code with the same data alignment. You need not change any data alignment directives before migrating a TNS COBOL85 program to native COBOL85. You need not regenerate Data Definition Language (DDL) source files that TNS COBOL85 and native COBOL85 programs share.
Changing the Source Program COBOL85 Migration Tasks Changing the Source Program Source program changes fall into these categories: • • • • • General Migration Tasks Removal Required Possible Changes Required on page 4-6 Removal Optional on page 4-8 New Features on page 4-9 General Migration Tasks If your COBOL85 program calls obsolete or changed Guardian procedures, replace them.
Removal Required COBOL85 Migration Tasks • USE DEBUGGING statement The 1985 COBOL standard classifies the USE DEBUGGING statement as obsolete, so you are advised not to use it even in TNS COBOL85 programs.
Possible Changes Required COBOL85 Migration Tasks Possible Changes Required The COBOL85 and NMCOBOL compilers handle the following directives, the ENTER statement, and floating-point arithmetic differently. Make any necessary changes to them before compiling your COBOL85 source program with the NMCOBOL compiler. For complete descriptions of the directives, see the COBOL85 for NonStop Systems Manual.
Possible Changes Required COBOL85 Migration Tasks • OPTIMIZE The NMCOBOL compiler handles OPTIMIZE 2 as if it were OPTIMIZE 1, because native COBOL does not support global optimization. OPTIMIZE 0 (no optimization) is recommended the first time you compile a program with the NMCOBOL compiler. OPTIMIZE 1 (most optimizations) is recommended for testing and production.
Removal Optional COBOL85 Migration Tasks Floating-Point Arithmetic The COBOL85 and NMCOBOL compilers can produce slightly different results for floating-point arithmetic. This is most likely to cause problems for exponentiation with a negative or fractional exponent (such as 10**-3 or 2**0.3). You can avoid this problem by including the ROUNDED phrase in statements that perform floating-point arithmetic. With the ROUNDED phrase, both compilers produce the same results.
New Features COBOL85 Migration Tasks • HIGHREQUESTERS directive Native COBOL85 programs can always run as servers that communicate with requesters running at high PINs. • ICODE and NOICODE The NMCOBOL compiler ignores these directives, warning you that it has done so. Use the INNERLIST and NOINNERLIST directives instead (see INNERLIST and NOINNERLIST directives on page 4-10). • LMAP and NOLMAP directives The LMAP and NOLMAP directives determine which load maps the compiler obtains from BINSERV.
Using the Inspect Debugger for Native COBOL85 Programs COBOL85 Migration Tasks • FMAP The FMAP directive causes the NMCOBOL compiler to produce a source file map, which shows the fully qualified name and timestamp of the IN file and each file specified by a SOURCE directive or COPY statement. • INNERLIST and NOINNERLIST directives The INNERLIST and NOINNERLIST directives determine whether the compiler lists the mnemonic version of each source statement immediately after that source statement.
5 TAL to pTAL Conversion Tasks The HP Transaction Application Language (TAL) is a higher-level, block-structured language used to write system software and transaction-oriented applications for NonStop servers. The Portable Transaction Application Language (pTAL) is a dialect of TAL. pTAL does not depend on architecture-specific characteristics of HP NonStop Series (TNS) processors.
TAL to pTAL Conversion Tasks Example 5-1. pTAL Compiler Listing With Syntax Checking PROC myproc; BEGIN INT I; *** Error: ^ --> I is declared to have type INT(16), but is used later as WADDR [error 01023]. INT .p1; I := @p1; In some cases, you can maintain one set of source code for both TAL and pTAL. See Maintaining Common Source Code for TNS and Native Compilers on page 2-3 for details. This manual does not describe the language-specific tasks required to convert from TAL to pTAL.
6 User Library Migration Tasks This section describes how to migrate a TNS user library to a native user library. It describes how to build a native user library and to associate a native user library with a native program file. A user library is an object file that the operating system links to a program file at run time. C, C++, COBOL85, TAL, and pTAL programs can have a user library. There are two types of user libraries: TNS user libraries and native user libraries.
User Library Migration Tasks Building a User Library 2. Add pragmas and directives: • • • In C and C++, add an SRL pragma to the compiler RUN command line or specify the native c89 -Wsrl flag. In COBOL85, add a UL directive to the compiler RUN command line or the source code. In pTAL, add an SRL directive to the compiler RUN command line or the source code. 3. Compile the source files as relinkable files, not as executable files.
Specifying a User Library User Library Migration Tasks 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 and native user libraries.
User Library Migration Tasks TNS/R Native Application Migration Guide —523745-001 6 -4 Specifying a User Library
7 Data Definition Language (DDL) Migration Tasks The Data Definition Language (DDL) defines data objects and translates object definitions into source code for programming languages and other products. Data objects can include parameters, structures, messages, database entries, and disk records. Data objects in host-language source code generated by DDL have the same physical layout, regardless of host language. The native compilers align data for optimal performance on TNS/R systems by default.
Data Definition Language (DDL) Migration Tasks Generating New Host-Language Source Code Files Generating New Host-Language Source Code Files If a program uses host-language source files that HP supplies, you do not need to generate new host-language source files. HP products that supply DDL files have been generated by D40 DDL for you. Proceed to the heading Compiling With New HostLanguage Source Code Files on page 7-3.
Data Definition Language (DDL) Migration Tasks Compiling With New Host-Language Source Code Files Compiling With New Host-Language Source Code Files HP products that supply DDL host-language files have been generated with D40 DDL for you. Depending on the product, the new DDL files are in D40 product versions or D20 and D30 RVU (interim product maintenance) versions.
Data Definition Language (DDL) Migration Tasks Compiling With New Host-Language Source Code Files TNS/R Native Application Migration Guide —523745-001 7 -4
8 Common Run-Time Environment (CRE) Migration Tasks The CRE coordinates many run-time tasks on behalf of the language-specific run-time libraries, thus providing 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. You do not need to change TNS programs that use CRE services implicitly to migrate them to native mode.
Common Run-Time Environment (CRE) Migration Tasks Specifying Header Files Specifying Header Files Separate TAL and pTAL header files describe the external declarations of CRE functions.
Common Run-Time Environment (CRE) Migration Tasks 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. COBOL85 programs can call either the COBOL85 intrinsic functions or the other suggested replacement functions. Table 8-1.
Common Run-Time Environment (CRE) Migration Tasks 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_ COBOL85 Only All Languages (including COBOL85) MOD modf() RTL_Normalize_Real64_ frexp() RTL_Odd_Int32_ Write your own function that determines whether a value is even or odd.
Common Run-Time Environment (CRE) Migration Tasks String Functions Table 8-1. Obsolete Standard Math Functions (page 3 of 3) Suggested Replacement Obsolete Function COBOL85 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 COBOL85) Write your own function that returns its first parameter with the sign set according to its second parameter.
Common Run-Time Environment (CRE) Migration Tasks 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.
Common Run-Time Environment (CRE) Migration Tasks Memory Block Functions Table 8-2.
Common Run-Time Environment (CRE) Migration Tasks 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 Guardian API Migration Tasks This section describes the changes you must make to Guardian application program interface (API) calls in programs you migrate to native mode.
Guardian API Migration Tasks 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.
Guardian API Migration Tasks • CHECKPOINT HP signals extensions to the POSIX.1 standard. These extensions are especially written for applications that focus on handling signals indicating conditions known as traps in TNS processes (those applications that call ARMTRAP). These procedures can be called in pTAL, C, and C++. These procedures include sigactioninit(), sigactionrestore(), and sigactionsupplant() in C and SIGACTION_INIT_, SIGACTION_RESTORE_, and SIGACTION_SUPPLANT_ in pTAL.
Guardian API Migration Tasks 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. Remove calls to CURRENTSPACE from your program. If your program’s logic relies on the TNS process architecture, significant recoding of your application to support the native process architecture is required.
Guardian API Migration Tasks 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. See the XBNDSTEST procedure in this section for more details.
Guardian API Migration Tasks 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 the TNS programs and one for native programs. Separate TNS and native versions are required because pTAL uses separate data types for integer and address values. For TNS programs, the procedure returns integer and address values through the type INT.
Guardian API Migration Tasks Using Procedures Enhanced to Support the Native Architecture Using Procedures Enhanced to Support the Native Architecture The following procedures have been enhanced to support the native processes, native object files, and native shared run-time libraries (SRLs): • • • • • • • • NEWPROCESS NEWPROCESSNOWAIT OBJECTFILE_GETINFOLIST_ PROCESS_CREATE_ PROCESS_GETINFOLIST_ PROCESSINFO PROCESS_SETINFO_ PROCESS_SPAWN_ Depending on the operations performed by these procedures, you m
Guardian API Migration Tasks Using Procedures Affected by KMSF Native processes do not use swap volume or file values specified by these procedures, so they 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.
Guardian API Migration Tasks Using Procedures With pTAL Data Types Using Procedures With pTAL Data Types The following procedures use pTAL data types that the support addresses WADDR, BADDR, EXTADDR, and PROCPTR: • • • • • • • • • • • • • • • • • • • • • • • • • • ADDRESS_DELIMIT_ AWAITIO AWAITIOX CHECK^FILE DNUMIN ENFORMSTART GETPOOL HEAPSORT HEAPSORTX INITIALIZER MEASWRITE_DIFF_ NUMIN POOL_CHECK_ PROCESS_SPAWN_ SEGMENT_ALLOCATE_ SEGMENT_GETINFO_ SEGMENT_USE_ SET^FILE SORTERROR SORTERRORDETAIL SORTERRO
Guardian API Migration Tasks Calling Code You Add to the System Library Calling Code You Add to the System Library If a native program calls code that you have added to the system library, the code added to the system library must be converted to native code. If both TNS processes (running in TNS mode or accelerated mode) and native processes call code you add to the system library, you need two versions of the code: one that has been accelerated and one that has been compiled with a native compiler.
10 Open System Services (OSS) API and Utilities Migration Tasks The NonStop Kernel Open System Services (OSS) environment provides an industrystandard application program interface (API) and set of utilities for NonStop servers. This section describes the OSS API changes required to migrate programs to native mode. It also describes changes required to c89 utility command lines to run the native C and C++ compilers.
Open System Services (OSS) API and Utilities Migration Tasks Specifying Compiler Pragmas Specifying Compiler Pragmas There are two versions of the OSS c89 utility: one version for the TNS compilation system and one version for the native compilation system. By default, the native c89 utility is run on D40 and subsequent operating system RVUs. Note. The TNS c89 utility has been moved to the /nonnative/usr/bin directory on D40 and later RVUs.
Open System Services (OSS) API and Utilities Migration Tasks Specifying Compilation System Components Specifying Compilation System Components The TNS and native compilation systems use different components, as described in Section 1, Introduction to Native Mode. Table 10-1 on page 10-3 describes the changes required to use the native C compilation system components.
Open System Services (OSS) API and Utilities Migration Tasks Specifying SQL Compilation Table 10-1. Changes Required to Use Native C Compilation System (page 2 of 2) Changed TNS c89 Utility Flag -Wcfront Reason for Change Action Required cfront function performed by component of native compilers. Replace with -WP flag. No arguments can be passed. Most -Wcfront arguments (such as pragmas) have corresponding native c89 flags. Specify corresponding c89 flags. See c89(1) reference pages for details.
11 Shared Data Migration Tasks This section describes the migration tasks related to: • • Sharing Data Between TNS and Native Programs Sharing Data Between pTAL Programs and Native C or C++ Programs on page 11-2 Shared data objects can include parameters, structures, messages, database entries, and disk records. Note. If DDL (Data Definition Language) is used to define shared data objects and generate source code, see Section 7, Data Definition Language (DDL) Migration Tasks.
Shared Data Migration Tasks 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 C and C++ programs on TNS/R systems by default (pragma FIELDALIGN AUTO). The pTAL compiler aligns data for the optimal performance of pTAL programs on TNS/R systems by default (directive FIELDALIGN AUTO).
12 Pathway/TS Migration Tasks This section describes migration tasks related to the Pathway/Transaction Services (Pathway/TS) product. The Pathway/TS Terminal Control Program (Pathway/TS TCP) user conversion procedures enable you to make your own validation checks or conversions of data passed between a SCREEN COBOL (SCOBOL) program and a terminal screen or intelligent device. In D40 and subsequent Pathway/TS product versions, the user conversion procedures are in a native user library.
Pathway/TS Migration Tasks TNS/R Native Application Migration Guide —523745-001 12- 2
Glossary accelerate. To use the Accelerator program to generate an accelerated object file. accelerated mode. The operational environment in which Accelerator-generated RISC instructions execute. accelerated object code. The RISC instructions that result from processing a TNS object file with the Accelerator. accelerated object file. The object file that results from processing a TNS object file with the Accelerator.
native object file Glossary native object file. See TNS/R native object file. native object file tool. See noft utility. native process. See TNS/R native process. nld utility. The native link editor (nld) utility collects, links, and modifies code and data blocks from one or more object files to produce a target TNS/R native object file. The nld utility is similar to the Binder program used in the TNS development environment. NMCOBOL compiler. A native compiler for the COBOL85 language. noft utility.
OSS environment Glossary OSS environment. The NonStop Kernel Open System Services (OSS) API, tools, and utilities. process. A program that has been submitted to the operating system for execution. An instance of execution of a program. program file. An executable object file. See object file. pTAL. A machine-independent systems programming language based on TAL. The pTAL language excludes architecture-specific TAL constructs and includes new constructs that replace the architecture-specific constructs.
TNS instructions Glossary TNS instructions. Stack-oriented, 16-bit machine instructions defined as part of the TNS environment. On TNS systems, TNS instructions are implemented by microcode; on TNS/R systems, TNS instructions are implemented by millicode routines or by translation to an equivalent sequence of RISC instructions. Contrast with “RISC instructions.” TNS mode. The operational environment in which TNS instructions execute. TNS object code.
TNS/R native user library Glossary TNS/R native user library. A user library available to TNS/R native processes in the Guardian and OSS environments. A TNS/R native user library is implemented as a special private TNS/R native SRL. Transaction Application Language (TAL). A systems programming language with many features specific to stack-oriented TNS systems. user library. An object file that the operating system links to a program file at run time. A program can have only one user library.
word Glossary TNS/R Native Application Migration Guide —523745-001 Glossary -6
Index Numbers B 16-bit data model 1-6, 3-6, 3-20 32-bit data model 1-6, 3-6, 3-20 32-bit pointers 3-8 64-bit logical operation functions 8-8 Backup, active 3-16 BADDR data type 9-9 Banners, compiler 3-19 Binder product 1-8, 3-18, 6-3, 10-3 Binding 1-8 BLANK directive 4-6 A Accelerated mode 1-2, 1-4, 1-10 Accelerator product 1-2, 2-2, 10-3 ACOS function 8-3 Active backup 3-16 ADDRESS_DELIMIT_ procedure 9-4, 9-9 ADDRTOPROCNAME procedure 9-2 alias keyword 3-8 Alignment, data 2-5, 2-6 Allocation, data objec
C Index C (continued) tal keyword 3-8 user library 6-1 variable keyword 3-8 warnings 3-5, 3-18 #include 3-5 _cc_status keyword 3-8 _lowmem keyword 3-8 _tal keyword 3-8 _variable keyword 3-8 C library functions alternate-model I/O 3-11 close 3-12 creat 3-12 ecvt 3-13 edlseek 3-12 exit 3-13 fcloseall 3-12 fcntl 3-12 fdopen 3-12 fdtogfn 3-12 fileno 3-12 fscanf 3-13 internationalization 1-7 iscsym 3-9 iscsymf 3-9 ISO/ANSI C Standard 3-9 I/O 3-11 lastreceive 3-12 lseek 3-12 memswap 3-10 movmem 3-10 open 3-12 r
C Index c89 utility migration tasks 10-2 overview 3-5 pragma support 3-17 CALL_CHECK^FILE_ADDRESS_ define 9-6 CALL_SET^FILE_ADDRESS_ define 9-6 CCE macro 3-8 CCG macro 3-8 CCL macro 3-8 cc_status keyword 3-8 CEXTDECS 2-3 Cfront 10-3 CHECK pragma 3-19 Checking condition codes 3-8 CHECKMONITOR procedure 9-8 CHECKPOINT procedure 9-3 CHECKPOINT statement 4-4 Checkpointing 9-3 CHECKPOINTMANY procedure 9-3 CHECKPOINTMANYX procedure 9-3 CHECKPOINTX procedure 9-3 CHECK^FILE procedure 9-6, 9-9 Class library, Tools
C Index COBOL85 directives (continued) SAVEABEND 4-7 SEARCH 4-5, 4-7 SQL 4-4 SQLMEM 4-9 SUBTYPE 4-7 TRAP2 4-9 TRAP2-74 4-9 UL 4-8 CODE directive 4-8 Code spaces 1-11 Comments 3-19 Common Run-Time Environment See CRE Common source GPLDECS file 9-6 maintaining 2-3 Common Usage C 1-6, 1-7 COMPACT directive 4-8 Compatibility traps 2-6 Compilation system, specifying 10-3 Compilers C 1-6 C++ 1-6 load maps 3-19 NMCOBOL 1-7 pragmas 10-2 pTAL 1-5 SQL 1-9, 3-18, 10-4 TAL 1-5 complement function 8-8 Condition codes
C Index CRE (continued) normalize function 8-4 obsolete functions 8-2/8-8 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
D Index C++ (continued) common source 2-3 compiler 1-6, 3-5 compiling with Cfront 10-3 condition codes 3-8 data model 1-6, 3-6, 3-20 errors 3-5 external functions 3-7 filebuf class 3-16 fstream class 3-16 HP extensions 3-5 keywords 3-8 memory model 1-6, 3-6, 3-20 messages 3-5, 3-18 migration tasks 3-1/3-17 migration tool 1-7, 3-2 NMCMT 1-7, 3-2 NULL pointer 3-5 preprocessor 10-4 run-time library 3-16 user library 6-1 warnings 3-5, 3-18 #include 3-5 D D30 RVU 2-3 D40 RVU 2-2, 2-3 Data alignment default 2-
F Index Environments development 1-4 execution 1-2 Environment-specific parameters 3-14 errno 3-15 ERRORS pragma 3-17 Errors, compiler 3-5 Exception-handling functions 8-8 Executable and linking format (ELF) 1-13 Executable object files 1-13 Execution modes 1-2 exit function 3-13 exp function 8-3 Exponentiation operator 4-8 EXTADDR data type 9-9 EXTDECS 2-3 Extended data segment 1-12, 9-8 Extended-Storage Section 4-8 extensible keyword 3-8 EXTENSIONS pragma 3-5 External declaration files 8-2 External func
H Index Guardian procedures (continued) affected by KMSF 9-7 ARMTRAP 9-2 AWAITIO 9-9 AWAITIOX 9-9 CHECKMONITOR 9-8 CHECKPOINT 9-3 CHECKPOINTMANY 9-3 CHECKPOINTMANYX procedure 9-3 CHECKPOINTX procedure 9-3 CHECK^FILE 9-6, 9-9 CLOSE^WRITE 9-5 condition codes 3-8 CURRENTSPACE 9-4 DUMIN 9-9 ENFORMSTART 9-9 FORMATDATA 9-4 FORMATDATAX 9-4 GETPOOL 9-9 GETSYNCINFO 9-8 HEADROOM_ENSURE_ 9-5 HEAPSORT 9-9 HEAPSORTX 9-9 INITIALIZER 9-5, 9-9 LASTADDR 9-4 LASTADDRX 9-4 MEASWRITE_DIFF_ 9-9 NEWPROCESS 9-7 NEWPROCESSNOWAIT
I Index Header files (continued) tal.h 3-8 Tools.
M Index LIBRARY directive in COBOL85 4-5, 4-6 in TAL 6-3 LINES pragma 3-17 Linking user library 6-2 with c89 flags 10-3 with nld utility 1-8 LMAP directive 4-9 LMAP pragma 3-19 ln function 8-3 Load maps 3-19 locale.
N Index N Native architecture 1-10, 9-7 Native c89 utility compiler pragmas 10-2 Guardian files 10-2 migration tasks 10-2 SQL compilation 10-4 -O flag 10-3 -Wnld flag 10-4 -Wnolink flag 10-4 -WP flag 10-3 -Wsqlcomp flag 10-4 -Wv flag 10-4 Native compilers alignment 7-1 C 1-6, 1-7 data alignment of 11-1 default optimization 2-4 object file format 1-13 optimization level 2-4 pTAL 1-5 Native C++ compiler 1-6 Native development 1-4 Native link editor 1-8 Native mode benefits of 1-18 constraints of 1-19 defini
O Index NOLMAP directive 4-9 NOLMAP pragma 3-19 NONEST pragma 3-19 NONSTOP directive 4-9 NonStop servers 2-2 NonStop SQL/MP product 1-9, 1-19, 3-18, 3-19 nonstoph header file 3-16 normalize function 8-4 NOSAVEABEND directive 4-7 NOSAVEABEND pragma 3-17 NOSEARCH directive 4-9 NOSQL directive 4-9 NOSTDFILES pragma 3-17 NOSUPPRESS pragma 3-17 NOSYMBOLS pragma 3-17 NOTRAP2 directive 4-9 NOTRAP2-74 directive 4-9 NOWARN pragma 3-18 NOWIDE pragma 3-6, 3-20 NOXMEM pragma 3-6, 3-20 NOXVAR pragma 3-20 NSKCOM utilit
P Index Pragmas (continued) changed behavior 3-18 CHECK 3-19 CPATHEQ 3-16, 3-17 CSADDR 3-19 ENV 6-1 ERRORS 3-17 EXTENSIONS 3-5 FIELDALIGN 2-5, 2-7, 11-1, 11-2 HEAP 3-17 HIGHPIN 3-17 HIGHREQUESTERS 3-17 INLINE 3-17, 3-18 INSPECT 3-17 LARGESYM 3-19 LINES 3-17 LMAP 3-19 MAPINCLUDE 3-16 NEST 3-19 NOCHECK 3-19 NOEXTENSIONS 3-19 NOINLINE 3-17, 3-18 NOINSPECT 3-17 NOLMAP 3-19 NONEST 3-19 NOSAVEABEND 3-17 NOSTDFILES 3-17 NOSUPPRESS 3-17 NOSYMBOLS 3-17 NOWARN 3-18 NOWIDE 3-6, 3-20 NOXMEM 3-6, 3-20 NOXVAR 3-20 obso
R Index Processes (continued) startup message for 9-5 TNS 1-1, 1-2 PROCESSINFO procedure 9-7 PROCESS_CREATE procedure 9-7 PROCESS_CREATE_ procedure 9-7 PROCESS_GETINFOLIST_ procedure 9-7, 9-8 PROCESS_GETINFO_ procedure 9-7 PROCESS_LAUNCH_ procedure 9-7, 9-8 PROCESS_SETINFO_ procedure 9-7 PROCESS_SPAWN_ procedure 9-7, 9-8, 9-9 PROCPTR data type 9-9 pTAL alignment 7-1 common source 2-3 compiler 1-5, 5-1 data types 9-9 definition 5-1 migration tasks 5-1 SOURCE directive 8-2 syntax checking 5-1 user library 6
S Index setmem functions 3-10 setnbuf functions 3-10 SETSYNCINFO procedure 9-8 Setting condition codes 3-8 SET^FILE procedure 9-6, 9-9 Shared data between native programs 11-2 between TNS and native programs 11-1 migration tasks 11-1/11-2 Shared Run-Time Library See SRL SHARED2 2-5, 2-7, 11-1 SHARED8 11-2 shift_left function 8-8 shift_right function 8-8 sign function 8-5 Signal handlers 8-2, 9-2 Signals 1-13, 3-9, 3-11, 3-15, 9-2 SIN function 8-5 sin function 8-5 sinh function 8-5 SIO procedures See Seque
T Index stcpma functions 3-10 stcu_d function 8-6 stcu_d functions 3-11 STDFILES pragma 3-17 stpblk function 8-6 stpblk functions 3-11 stpbrk functions 3-11 stpchr functions 3-11 stpsym function 8-6 stpsym functions 3-11 stptok function 8-6 stptok functions 3-11 strcat function 8-6 strchr function 8-6 strcmp function 8-6 strcpy function 8-6 strcspn function 8-6 Streams, file 3-16 STRICT pragma 3-19 String functions 8-5 String:length parameters 4-2 strlen function 8-6 strncat function 8-6 strncmp function
U Index TNS architecture characteristics of 1-4 ENV register 9-4 ’G’ relative address 9-4 TNS c89 utility compiler pragmas 10-2 Guardian files 10-2 migration tasks 10-2 SQL compilation 10-4 -O flag 10-3 -Waxcel flag 10-3 -Wbind flag 10-3 -Wccom flag 10-3 -Wcfonly flag 10-3 -Wcfront flag 10-4 -Wcprep flag 10-4 -Wnobind flag 10-4 -Wrunlib flag 10-4 -Wsql flag 10-4 -Wverbose flag 10-4 TNS compilers, data alignment of 11-1 TNS mode 1-2, 1-4, 1-10 TNS processes codes spaces 1-11 data spaces 1-12 definition of
V Index V variable keyword 3-8 VERBOSE pragma 3-19, 10-4 Virtual memory 1-16 Visual Inspect symbolic debugger 1-9 Volumes search 3-18 swap 9-7 W /G 10-2 _alias keyword 3-8 _cc_status keyword 3-8 _cc_status type specifier 3-8 _is_system_trap function 3-9 _lowmem keyword 3-8 _status_eq(x) macro 3-8 _status_gt(x) macro 3-8 _status_lt(x) macro 3-8 _tal keyword 3-8 ’main’ procedure 8-1 WADDR data type 9-9 WAIT^FILE procedure 9-5 WARN pragma 3-18 Warnings, compiler 3-5 WIDE pragma 3-6, 3-20 write function 3-
