H-Series Application Migration Guide Abstract This guide introduces the H-series application development and execution environments and explains how to migrate existing G-series applications to H-series systems. Product Version N.A. Supported Release Version Updates (RVUs) This manual supports H06.07 and all subsequent H-series RVUs until otherwise indicated in a replacement publication.
Document History Part Number Product Version Published 429855-005 N.A. July 2005 429855-006 N.A. February 2006 429855-007 N.A. August 2006 429855-008 N.A.
H-Series Application Migration Guide Glossary Index Figures Tables What’s New in This Manual vii Manual Information vii New and Changed Information for the 429855-008 Edition New and Changed Information for the 429855-007 Edition About This Manual ix Organization of This Manual ix Notation Conventions x HP Encourages Your Comments vii viii x 1.
2. The TNS/E Native Development Environment (continued) Contents 2.
4. General Programming Issues (continued) Contents 4. General Programming Issues (continued) Creating Unstructured Enscribe Files Might Require Program Changes DDL Dictionary Conversion Required 4-7 setjmp Buffers Have Different Size and Alignment Requirements 4-7 4-6 5.
. Native COBOL Migration Tasks (continued) Contents 6. Native COBOL Migration Tasks (continued) Removal Optional 6-2 Possible Changes Required 6-2 RENAMES Clause Has Different Behavior 6-3 Symbol Dictionary Requires More Space 6-4 TNS/E COBOL Uses IEEE Floating-Point Format 6-5 Alignment of Level-01 and Level-77 Data Items Changed Files Renamed 6-5 ecobol Command Line Flags Changed 6-6 6-5 7.
9. Guardian API Migration Tasks (continued) Contents 9. Guardian API Migration Tasks (continued) New Return Values for PROCESSOR_GETNAME_ 9-2 New Return Values for PROCESSOR_GETINFOLIST_ 9-3 New Return Values for TOSVERSION and REMOTETOSVERSION Superseded Procedures 9-3 DELAY 9-3 New Procedures 9-3 10. Where to Go for Assistance HP Services 10-1 Assessment Services 10-1 Pilot (Proof of Concept) Service 10-1 Global Mission Critical Solution Center (GMCSC) 10-1 A.
C. Reporting Compiler Optimization Problems Contents C. Reporting Compiler Optimization Problems Types of Errors C-1 Information Required for All Error Types C-1 Additional Information Needed for Compiler Errors and Compiler Aborts Additional Information Needed for Incorrect Results Error C-2 Additional Information Needed for Runtime Abort C-3 Tips for Providing Alternative Debugging Information C-3 Creating an Optimize File C-4 C-2 Glossary Index Figures Figure 2-1. Figure 2-2. Figure 2-3. Figure B-1.
What’s New in This Manual Manual Information H-Series Application Migration Guide Abstract This guide introduces the H-series application development and execution environments and explains how to migrate existing G-series applications to H-series systems. Product Version N.A. Supported Release Version Updates (RVUs) This manual supports H06.07 and all subsequent H-series RVUs until otherwise indicated in a replacement publication.
New and Changed Information for the 429855-007 Edition What’s New in This Manual • • ° G-series SRL name of the C++ VERSION3 standard runtime library on page 2-7. ° H-series DLL name of the C run-time library on page 2-7. Added Different Buffer Alignment for POOL_DEFINE_Procedure on page 9-1. Added references to the NonStop Development Environment for Eclipse (NSDEE), which can be used instead of the ETK.
About This Manual The H-series RVUs of the HP NonStop™ software run on the Intel® Itanium® processor-based HP Integrity NonStop NS-series servers. Differences between the H-series and G-series RVUs are due mainly to architectural differences between the HP NonStop Series/RISC (TNS/R) and HP NonStop Series/EPIC (TNS/E) platforms. The Itanium processor uses a different instruction set at the hardware level.
Notation Conventions About This Manual • • • • ° ° ° ° ° Section 5, Native C and C++ Migration Tasks Section 6, Native COBOL Migration Tasks Section 7, pTAL Migration Tasks Section 8, User Library Migration Tasks Section 9, Guardian API Migration Tasks Section 10, Where to Go for Assistance, explains how to get help with application migration issues. This section should be read by all users.
1 Migration Overview This section introduces the H-series development and execution environments, and provides a summary of the tasks required to migrate an application from the G-series environment to the H-series environment.
What is Changing Migration Overview • • Full support for TNS/R native compilers and linkers. You can compile and link, but not execute, TNS/R native applications on an H-series system. Support for FORTRAN and Pascal languages. A TNS FORTRAN compiler is provided, and both FORTRAN and Pascal accelerated object files will run on the TNS/E platform, but they must be accelerated by the H-series Object Code Accelerator (OCA).
G-Series-to-H-Series Migration Paths Migration Overview supported and is enhanced on H-series systems. In addition the NonStop Development Environment for Eclipse (NSDEE) is available for H-series RVUs. CAUTION. If a program does any of the following, additional changes not described in this guide will likely be required: • • • • • • Executes procedures that are not documented in standard HP NonStop documentation. (Most procedures are documented in the Guardian Procedure Calls Reference Manual.
Migration Overview TNS/R Native Mode to TNS/E Native Mode The H-series systems continue to support the Guardian TNS compilers and tools. You can continue to compile, run, and debug TNS applications on an H-series system in a familiar TNS environment. Like G-series systems, H-series systems support both an interpreted mode and an accelerated mode for executing TNS object files. H-series systems provides an interpreter for emulating TNS object code and an accelerator for accelerating TNS code.
H-Series Development Environments Overview Migration Overview 1. Convert the TNS program to native mode on the TNS/R platform following the guidelines given in the TNS/R Native Application Migration Guide. 2. Migrate the TNS/R native program to the TNS/E system following the guidelines given in this guide. In the vast majority of cases, migrating a program from TNS/R native mode to TNS/E native mode is a simple matter, requiring only a recompilation using a TNS/E native compiler.
Developing TNS/R Applications on a TNS/E System Migration Overview that have nearly identical functionality to the TNS/R tools. Following are some general differences: • • • • The TNS/E tools have different names (most of the same directives, flags, and pragmas are supported, and some new ones are added). All libraries are dynamic-link libraries (DLLs). Shared run-time libraries (SRLs) are not supported. The H-series RVUs provide more comprehensive support for DLLs than do the G-series.
G-Series TNS Mode to H-Series TNS Mode Migration Overview area). If it does, extensive rewriting might be required. For assistance with these kinds of operations, consult the resources described in Section 10, Where to Go for Assistance. 3. Determine if the following issues affect execution of your program and make any necessary changes. See the appropriate page for more information. • • Misaligned Data Causes Performance Loss on page 4-2 Adjusting For Increased DCT Limits on page 4-3 4.
Migration Overview G-Series TNS Mode to H-Series TNS Mode that will run in accelerated mode on both the TNS/R and TNS/E platforms. (Likewise, you can run AXCEL on an object file that has been accelerated by OCA.) See Object Code Accelerator Utility on page B-7 for an overview of OCA. See the OCA Manual for details. • The OSS environment does not support TNS execution. All OSS TNS programs must be migrated to TNS/E native mode to run on an H-series system.
2 The TNS/E Native Development Environment The H-series RVUs support TNS/E native development and execution environments.The H-series RVUs also support TNS/R native tools, although you cannot execute TNS/R object files on an H-series system.
TNS/E Native Development Tools The TNS/E Native Development Environment • • • • • • • • COBOL compiler C run-time library linker object file utility SQL compiler Data Definition Language (DDL) debugging tools Common Run-Time Environment (CRE) Table 2-1 compares the specific tools available in the TNS/R and TNS/E native environments. Table 2-1.
The TNS/E Native Development Environment TNS/E pTAL Compiler TNS/E pTAL Compiler H-series systems provide a pTAL compiler that is nearly identical to the pTAL compiler on G-series systems, except that it produces object files consisting of Itanium instructions instead of RISC instructions. It has a new command name: EPTAL. The command line syntax is similar.
The TNS/E Native Development Environment TNS/E Native C++ Compiler TNS/E Native C++ Compiler The TNS/E native C++ compiler accepts C++ language source files. The TNS/E native C++ compiler accepts HP extensions and most C++ features in the ANSI base document for the C++ standard (excluding export templates). The native C++ compiler can be run in the Guardian and OSS environments and on the PC either at the Windows command prompt or as part of NSDEE or ETK (TDS is only supported on G-series RVUs.).
Cross-Compiling on the PC The TNS/E Native Development Environment Cross-Compiling on the PC You can compile and link C, C++, pTAL, and COBOL programs on a PC running the Windows operating system, either within NSDEE or ETK (see the documentation for the development environment you are using) or from the Windows command prompt.
The TNS/E Native Development Environment Cross-Compiling on the PC 2. From the list of manuals, select the NonStop Development Environment for Eclipse User Guide. 3. If you have installed NSDEE Core with Debugging, you can also select the NonStop Development Environment for Eclipse Debugging Supplement from the list of manuals.
TNS/E Native Run-Time Libraries The TNS/E Native Development Environment 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.
The TNS/E Native Development Environment TNS/E Native Linker and Loader TNS/E Native Linker and Loader The TNS/E native linker, eld, links one or more native position-independent code (PIC) linkfiles (object files generated by the TNS/E native compilers or by eld) to produce a PIC loadfile. The loadfile is either a program or a dynamic-link library (DLL), which can be loaded into memory and executed.
The TNS/E Native Development Environment TNS/E Native Linker and Loader eld accepts PIC object files and produces PIC executable object files, whereas nld accepts non-PIC object files and produces non-PIC executable object files. Like nld, eld can be used to produce both linkfiles and loadfiles. (A linkfile can be linked to other linkfiles to produce a loadfile but cannot be loaded for execution. A loadfile cannot be linked but can be loaded for execution.
The TNS/E Native Development Environment Native Object File Tool Native Object File Tool The TNS/E native object file utility, enoft, reads and displays information about TNS/E native object files (linkfiles and loadfiles). enoft has similar syntax and functionality as the TNS/R native object file utility, noft.
The TNS/E Native Development Environment TNS/E Native Mode Debugging Tools Visual Inspect Visual Inspect is an application debugging tool in the TNS/E native environment. The H-series version of Visual Inspect debugger includes the same functionality as the Gseries version. Visual Inspect supports high-level symbolic debugging of native and TNS processes (interpreted and accelerated) through a PC-based graphical user interface.
The TNS/E Native Development Environment TNS/E Native Mode Debugging Tools Native Inspect provides most of the functionality of Inspect and Debug. However, the Native Inspect command syntax differs from that of Inspect and Debug. The Native Inspect syntax is based on the Open Software Foundation GDB debugger, a tool that is widely used throughout the industry and is familiar to many application developers. In most cases, you are encouraged to use Visual Inspect as your primary application debugger.
The TNS/E Native Development Environment TNS/E Native Mode Debugging Tools Table 2-4. Inspect Low-Level Commands and Native Inspect Equivalents Inspect Low-Level Command Equivalent Native Inspect Command VQ vq ? env = eq Table 2-5.
The TNS/E Native Development Environment TNS/E Native Mode Debugging Tools Table 2-5.
The TNS/E Native Development Environment TNS/E Native Mode Debugging Tools Table 2-5.
The TNS/E Native Development Environment • H-Series Common Run-Time Environment (CRE) Changes A TNS mode program automatically enters the debug state under control of Native Inspect. Since Native Inspect does not support TNS mode debugging, you would likely want to switch to Inspect. See the Inspect Manual, the Native Inspect Manual, and the Visual Inspect online help for details. INSPECT Attribute Changes The INSPECT process attribute determines the default debugger for a process.
The TNS/E Native Development Environment New Memory Allocation Function New Memory Allocation Function CRE has a new memory allocation function: malloc_pages(). The behavior of malloc_pages is the same as malloc(), except that the allocated memory is automatically aligned to a page boundary. The number of bytes requested for the space is rounded up to a multiple of the page size so that the allocated space always occupies one or more complete pages.
The TNS/E Native Development Environment Setting Up a Cross-Platform Development Environment on the PC versions. The following command flag and pragma are provided to specify the target G-series RVU: OSS, PC c89 command -WRVU=G06.nn, nn >= 20 Guardian NMC and NMCPLUS commands RVU G06.nn, nn >= 20 The existence of these tools and libraries on H-series systems enables you to use a single platform, the TNS/E platform, to develop both TNS/R and TNS/E applications.
The TNS/E Native Development Environment Using ETK ETK is a Windows-based application development environment that is integrated with Microsoft Visual Studio.NET. ETK enables you to edit, compile, build, and deploy NonStop applications written in a variety of programming languages. ETK works with Microsoft Visual Studio.NET to manage solutions and projects. Solutions are containers for projects, and projects are containers for source files and other items that comprise an application.
The TNS/E Native Development Environment Using ETK A typical solution might look like this: Solution A Project 1 source file source file other items Project 2 ... Using ETK, you can easily set up projects to be deployed on both the TNS/R and TNS/E platforms. You can define a single solution consisting of multiple projects. The projects can share source files or they can consist of exactly the same source code.
The TNS/E Native Development Environment Using ETK Figure 2-1. Project Properties Screen You have now created a solution containing one project. The solution and projects will appear similar to the example in Figure 2-2. Figure 2-2. ETK Solution With One Project (1 project) You can now compile and link the program by choosing the BUILD command, then deploy the executable program or library on the NonStop server by choosing the DEPLOY command.
The TNS/E Native Development Environment Using ETK Figure 2-3. ETK Solution With Two Projects Target platform is TNS/R Target platform is TNS/E Now, use menu commands to build and deploy the solution. These operations will build both applications using the appropriate compilers and linkers, and deploy them on the appropriate NonStop servers, as specified in the Application Settings and Project Properties.
3 TNS/E Native Architecture Features This section describes the TNS/E native architecture features and highlights the differences between the TNS/E native architecture and TNS architecture, and between the TNS/E native architecture and TNS/R native architecture.
Process Attributes TNS/E Native Architecture Features Process Attributes The INSPECT attribute on H-series systems selects one of the H-series debuggers, as shown in the following table. For each process type and INSPECT setting, the table shows the debuggers in the order selected, depending on debugger availability. INSPECT ON INSPECT OFF G-Series Native non-PIC Processes 1. Visual Inspect (see note 1) 2. Inspect 3. Debug Debug G-Series Native PIC Processes 1. Visual Inspect (see note 1) 2.
Code Segments TNS/E Native Architecture Features Code Segments A process has distinct code segments that contain executable code. Table 3-1 compares the code segments on TNS/R and TNS/E processors: Table 3-1. Code Segments Process Type Code Segments TNS/R native process UCr (user code RISC) SRL (shared run-time libraries, including public SRLs and the native user library) SCr (system code RISC) SLr (system library RISC) ordinary DLLs (G06.
Data Segments TNS/E Native Architecture Features Data Segments When a process is created, several data segments are allocated for its use. Table 3-2 compares the data segments for TNS/E and TNS/R processors: Table 3-2.
TNS/E Native Architecture Features TNS/E Object File Format Also on both platforms, the heap can grow to the maximum size of the globals-heap segment less the size of the global data. On the TNS/R platform, the maximum globals-heap size is 1.1 GB. On the TNS/E platform, the maximum globals-heap size is 1.5 GB. See the Guardian Programmer’s Guide for more information on TNS/R and TNS/E native processes.
TNS/E Native Architecture Features Dynamic-Link Libraries (DLLs) contrast, are constructed of non-PIC and are bound to fixed virtual addresses for execution. They cannot have their addresses modified at load time. An important attribute of DLLs is that they can be dynamically loaded; that is, a running program can load a DLL and gain access to its symbols. This capability means that you do not need to load infrequently used DLLs when the application is loaded.
TNS/R Non-PIC Migration Considerations TNS/E Native Architecture Features : Table 3-3. TNS/E and TNS/R Library Comparison Library Type Public library TNS/R Characteristics • • • • • Private library • • Public libraries are implemented as SRLs (pre-G06.20) Public libraries are implemented as hybrid SRLs (G06.
TNS/E Native Architecture Features TNS/R PIC Migration Considerations converted from SRLs to DLLs, such as compiler run-time libraries, have new names, which means that build scripts that reference these libraries must be changed. See TNS/E Native Run-Time Libraries on page 2-7 for the new library names. If your application uses a user library (private SRL), you must rebuild the user library as a DLL. See Section 8, User Library Migration Tasks, for information on migrating user libraries.
4 General Programming Issues This section discusses some general migration issues that apply to all native applications being migrated to an H-series system.
General Programming Issues Misaligned Data Causes Performance Loss addition, avoid using those few features in your TNS/R programs that are not supported in the H-series RVUs. Misaligned Data Causes Performance Loss Programs compiled with the native compilers align data items according to certain rules. 4-byte data items are aligned on boundaries whose addresses are a multiple of 4, and 8-byte data items are aligned on boundaries whose addresses are a multiple of 8.
Misalignments in TNS/E Native Programs General Programming Issues Misalignments in TNS/E Native Programs On TNS/E systems, round-down never occurs in native mode, and no options to change native mode program behavior are supported. Certain misalignments are treated as fatal events, and for those, no tracing is necessary. Nonfatal misalignments can also occur, and on both G-series and H-series systems, they can cause compatibility traps.
Adjusting For Increased DCT Limits General Programming Issues number can have up to 16 bits).
Optimizing on TNS/E Might Expose Errors General Programming Issues Optimizing on TNS/E Might Expose Errors The optimizers for the TNS/E C/C++ and pTAL compilers perform significantly more optimizations that do the TNS/R optimizers. As a result, programs that contain programming errors but still run correctly when compiled at optimization level 2 on a TNS/R system might not run correctly when compiled at optimization level 2 on a TNS/E system.
Examples of Programming Errors General Programming Issues Examples of Programming Errors Here are several examples of programming errors that do not cause problems at optimization level 0, but might cause problems at level 1 or 2. Example 1. Overflowing a String Variable Assume the existence of two procedures, CALLER and CALLEE. CALLER defines a local variable L. CALLEE declares a string S of fixed size T. CALLER then calls CALLEE. CALLEE overflows string S by writing more than T bytes to S.
DDL Dictionary Conversion Required General Programming Issues The system will not allocate less file space than was requested by the file creation values. If the request extent sizes are a multiple of 14, the system allocates the exact file space requested. However, if the requested extent sizes are not a multiple of 14, some additional file space is allocated, allowing the file to grow larger than requested. This situation does not usually require any application changes.
General Programming Issues setjmp Buffers Have Different Size and Alignment Requirements H-Series Application Migration Guide—429855-008 4 -8
5 Native C and C++ Migration Tasks This section describes how to migrate programs written in the G-series TNS/R native HP C and C++ for NonStop systems languages to an H-series system. Topics in this section are: • • • • • • Using the TNS/E Native C and C++ Compilers. Possible Source Code Changes on page 5-2. Changed Pragmas and Flags on page 5-5 Native C and C++ Run-Time Library and Tools.h++ Migration Issues on page 5-8.
Native C and C++ Migration Tasks Possible Source Code Changes 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. It is used to create dynamic-link libraries (DLLs). TNS/E native compilers do not provide an option to generate non-PIC, and do not support SRLs. See the C/C++ Programmer’s Guide for details on compiling and linking TNS/E native C and C++ programs.
Native C and C++ Migration Tasks Avoiding Floating-Point Conflicts For details on which floating-point combinations are valid and which result in errors, see the C/C++ Programmer’s Guide. That manual also provides information on how to specify the floating-point format using compiler pragmas and linker options.
Check C/C++ Main Routine Object File Name Native C and C++ Migration Tasks Check C/C++ Main Routine Object File Name The C and C++ main routine object file, which contains initialization code for the C and C++ run-time libraries, has been renamed in the H-series RVUs. This change will affect build scripts or any other link operation that specifies this file. The new names, along with the equivalent TNS/R PIC and non-PIC names, are: File Type Guardian Name OSS Name TNS/R Non-PIC CRTLMAIN crtlmain.
Native C and C++ Migration Tasks Check Use of Feature Test Macro unsigned short int *array; }arg union semun semopts; semopts.val = 1; if (semctl(semid, 0, SETVAL, semopts) ==-1) On TNS/R systems, you can also pass a value directly, without the use of the semun union (for example, as a simple scalar), as in this example: if (semctl(semid, 0, SETVAL, 1) ==1) A value passed in this way gives the expected results. However, on TNS/E systems, you must define the parameter value as a semun union.
Changed Pragmas Native C and C++ Migration Tasks pragmas and flags are not meaningful or have different behavior on H-series systems. In most cases, obsolete pragmas and flags have no effect if they appear an H-series program. Note. Most pragmas have equivalent flags in the OSS and PC environments.
C89 Flags Changed Native C and C++ Migration Tasks INSPECT selects, in order of precedence and depending on availability: G-Series Non-PIC G-Series PIC H-Series 1. Visual Inspect* 1. Visual Inspect* 1. Visual Inspect* 2. Inspect 2. DEBUG 2.Native Inspect 3. DEBUG *Visual Inspect requires the existence of a matching client connection.
Native C and C++ Migration Tasks Native C and C++ Run-Time Library and Tools.h++ Migration Issues TNS/E platform.
Native C and C++ Migration Tasks Library Names Changed VERSION3 of the native C++ run-time library contains functions conforming to the ISO/ANSI C++ standard. Both VERSION2 and VERSION3 contain functions conforming to the X/OPEN UNIX 95 specification and HP extensions to these standards. See the C/C++ Programmer’s Guide for more information on the differences between the VERSION1, VERSION2, and VERSION3 libraries. VERSION3 is the default library version for G06.
Toolsh++ TLHMAP File Names Changed Native C and C++ Migration Tasks Toolsh++ TLHMAP File Names Changed On H-series systems, the names of certain files listed in the TLHMAP file have changed. The changed files are: G-Series File Name H-Series File Name generich rwgenerh locale3h rwlocalh newh rwnewh regexph rwregexh To avoid compilation errors, make sure you specify the new H-series file names if you are using your own private map file.
Native C and C++ Migration Tasks LIBCOBEY and libc.obey Files Replaced an aid to migrating from VERSION2 to VERSION3. See the C/C++ Programmer’s Guide for details. When migrating to VERSION3 from either VERSION1 or VERSION2, you can omit the VERSIONn directive (or the -Wversionn flag) when you compile the program because VERSION3 is the default version.
Native C and C++ Migration Tasks • • Using the C++ Neutral Dialect NEUTRAL (pragma) BUILD_NEUTRAL_LIBRARY (command line option) The NEUTRAL pragma is used within headers supplied by HP to mark an object as being sharable between VERSION2 and VERSION3 of the standard library. The BUILD_NEUTRAL_LIBRARY option enables you to create a DLL that uses the neutral dialect. This option causes the compiler to check whether or not a compilation will create a DLL that can use the neutral dialect.
Native C and C++ Migration Tasks Undefined Behavior in C and C++ Programs Undefined Behavior in C and C++ Programs The C and C++ International Standards declare certain language behavior to be either unspecified or undefined. These behaviors might differ between TNS/R and TNS/E programs, so any programs that depend on such behavior should be changed to use to eliminate the dependency.
Pragmas Native C and C++ Migration Tasks Pragmas The native TNS/E C and C++ compilers support these new pragmas: Pragma Description NEUTRAL Marks an object as sharable between VERSION2 and VERSION3 of the C++ standard library. See Native C and C++ Run-Time Library and Tools.h++ Migration Issues on page 5-8 for more information. MAXALIGN Aligns composite objects to the maximum alignment (16byte alignment). See Maximum Data Alignment on page 5-14 for more information.
6 Native COBOL Migration Tasks This section describes how to migrate programs written in the TNS/R native HP COBOL for NonStop Systems language to a TNS/E system.
Native COBOL Migration Tasks Directives Changed and TNS/E native COBOL compilers and notes the few changes that might be needed by some programs. Directives Changed Following are descriptions of differences in TNS/R and TNS/E COBOL directives. Some directives can remain in your program and will have no effect, while others can affect program behavior. Removal Optional The following directives are obsolete and are ignored in TNS/E native COBOL. If you remove them, no replacement or recoding is required.
RENAMES Clause Has Different Behavior Native COBOL Migration Tasks: and CALL-SHARED or SHARED in the same compilation unit causes an error. In TNS/E native COBOL, specifying both UL and RUNNABLE directs the compiler to link the object file into a DLL. • SEARCH and CONSULT In TNS/E native COBOL, these directives must specify TNS/E object files. They must not specify TNS/R object files. • OPTIMIZE Both TNS/R native and TNS/E native COBOL accept the same values for the OPTIMIZE directive: 0, 1, and 2.
Symbol Dictionary Requires More Space Native COBOL Migration Tasks RENAMES clause to rename a level-01 data item, you must change the source code as follows before recompiling it with the TNS/E COBOL compiler. If the level-01 data item is elementary, change the RENAMES clause to a REDEFINES clause. For example, change: 01 CARD-COUNTER PIC 9(6). 66 ITEM-COUNT RENAMES CARD-COUNTER. To: 01 CARD-COUNTER 66 ITEM-COUNT PIC 9(6). PIC 9(6) REDEFINES CARD-COUNTER.
Native COBOL Migration Tasks: TNS/E COBOL Uses IEEE Floating-Point Format TNS/E COBOL Uses IEEE Floating-Point Format Both TNS/R native and TNS/E native COBOL use floating-point data values for certain internal calculations. TNS/R native COBOL uses the HP proprietary TNS floating-point format, whereas TNS/E native COBOL uses the IEEE format (no option is provided to use TNS floating-point).
ecobol Command Line Flags Changed Native COBOL Migration Tasks ecobol Command Line Flags Changed The following flags on the OSS and PC ecobol command have changed to invoke the H-series linker eld instead of ld or nld. (These flags do not have corresponding directives. For changes to flags that have corresponding directives, see Directives Changed on page 6-2.
7 pTAL Migration Tasks The H-series RVUs provide a Portable Transaction Application Language (pTAL) compiler that generates Itanium code. This section discusses: • • • • • • • • • Using the TNS/E pTAL Compiler Changed Directives Changed Functions and Procedures on page 7-5 Procedure Attribute Not Supported on page 7-6 Use of Address Types Changed on page 7-6 Using PLATFORM and AUTO Alignment on page 7-4.
Removal Required pTAL Migration Tasks Removal Required The following directives are not supported by the TNS/E pTAL compiler and must be removed or changed as indicated.The pTAL compiler generates an error diagnostic if any of these directives are encountered in a program. Directive Notes SAVEGLOBALS Considered obsolete in TNS/R pTAL. Not supported in TNS/E pTAL. Remove from program. See the paragraph following this table for more information. USEGLOBALS Considered obsolete in TNS/R pTAL.
Removal Optional pTAL Migration Tasks Removal Optional The following directives are obsolete in TNS/E pTAL. The TNS/E pTAL compiler treats them as described under “Notes”. Removing them from your program has no effect and requires no additional code changes. Directive Notes BEGINCOMPILATION This directive is considered obsolete in TNS/R pTAL. It is not supported and is ignored by the TNS/E pTAL compiler. (Do not remove this directive if it is still needed for a TNS/R compilation.
Using PLATFORM and AUTO Alignment pTAL Migration Tasks Using PLATFORM and AUTO Alignment The PLATFORM directive causes the pTAL compiler to use the same data alignment as other compilers on the same platform. That alignment might differ from the alignment produced by the same compiler on a different platform. The AUTO directive allows the compiler to determine data alignment based on what is most efficient.
Changed Functions and Procedures pTAL Migration Tasks 1. Split the procedure into two separate procedures: ° ° One that returns both a traditional function value and a condition code value One that returns only the traditional function value 2. In an external declaration, use a public name clause to map the original pTAL procedure name to a new and different linkage name. 3. Change the aliases of the C/C++ prototypes to the appropriate new pTAL procedure.
Procedure Attribute Not Supported pTAL Migration Tasks $LOCKPAGE Not supported in TNS/E pTAL. Replace with H-series directly-called privileged interface. $READBASELIMIT Not supported in TNS/E pTAL. Replace with H-series directly-called privileged interface. $READSPT Not supported in TNS/E pTAL. Replace with H-series directly-called privileged interface. $STACK_ALLOCATE Performs different rounding and alignment in TNS/E pTAL. See the paragraph following this table.
Conditional Compilation Changes pTAL Migration Tasks Conditional Compilation Changes Programs that perform conditional compilation by testing for TARGET directives in the source code might require changes to ensure correct results on the TNS/E platform.
16-Byte-Aligned Data pTAL Migration Tasks --SHARED8 END; STRUCT A1(A); --The base of A1 is guaranteed to be aligned --on a 16-byte boundary STRUCT B(*) FIELDALIGN(SHARED8); BEGIN INT(16) KK; FILLER 14; STRUCT A2(A); --The base of A2 is guaranteed to be --aligned on a 16-byte boundary END; STRUCT B1(B); --The base of B1 is guaranteed to be aligned --on a 16-byte boundary because the largest --alignment of the components of B1, namely --A2, is 16 bytes Note the following regarding this example: • • Wh
8 User Library Migration Tasks This section explains how to migrate TNS/R native user libraries to TNS/E native user libraries.Topics discussed are: • • • When the User Library is an SRL When the User Library is a DLL on page 8-2 Specifying a User Library on page 8-2 A user library is an object file that the operating system links to a program file at run time. A C, C++, COBOL, TAL, or pTAL program can have a user library.
When the User Library is a DLL User Library Migration Tasks • • For COBOL programs: ° Compile with ECOBOL instead of NMCOBOL (Guardian), or ecobol instead of nmcobol (OSS and PC). ° On the ECOBOL command line or in the source code, specify either the UL directive or the SHARED directive and add the ELD directive. (Retain the RUNNABLE directive). ° On the ecobol command line (OSS and PC), replace the -Wnonshared flag with -Wshared and replace the -Wnld flag with -Weld.
9 Guardian API Migration Tasks This section describes changes in the H-series Guardian and OSS application program interface (API) calls. The calls described in this section have slightly different behavior, have different or additional return values, or have been superseded by a new procedure in the H-series RVUs. This section also lists procedures that are new in the H-series RVUs.
Guardian API Migration Tasks DEBUG and PROCESS_DEBUG_ Procedures Invoke H-Series Debuggers DEBUG and PROCESS_DEBUG_ Procedures Invoke H-Series Debuggers The DEBUG and PROCESS_DEBUG_ procedures are changed to invoke one of the new debugging tools on H-series systems. The H-series debugging tools are Visual Inspect and Native Inspect for TNS/E native processes, and Visual Inspect and Inspect for TNS processes.
New Return Values for PROCESSOR_GETINFOLIST_ Guardian API Migration Tasks New Return Values for PROCESSOR_GETINFOLIST_ New return values are added to the PROCESS0R_GETINFOLIST_ procedure to support the TNS/E platform.
Guardian API Migration Tasks H-Series Application Migration Guide—429855-008 9 -4 New Procedures
10 Where to Go for Assistance HP Services HP NonStop Services provides a suite of services and proprietary service delivery tools to identify software migration issues at your site and to help with the recoding, compiling, testing, and validation of applications. Assistance is provided by a highly skilled and experienced staff. Assessment Services Before you begin migrating your applications, you can contact Assessment Services.
Where to Go for Assistance Global Mission Critical Solution Center (GMCSC) H-Series Application Migration Guide—429855-008 10- 2
A Independent Product Migration Tasks Migrating NonStop CORBA Applications In most respects, the H-series NonStop CORBA application environment is similar to the G-series NonStop CORBA environment. Most of the differences are in the application development environment, which apply to all applications. General Considerations • • All TNS/R native applications must be recompiled using an H-series TNS/E native compiler. TNS/R native object files cannot be executed on a TNS/E system.
Independent Product Migration Tasks Migrating NonStop Server for Java 4 Applications NonStop Server for Java 4 on TNS/E systems has the same Java features and functions as version 2, NonStop Server for Java 4 on TNS/R systems. Differences between NonStop Server for Java 4 on TNS/R systems and TNS/E systems are: • • • • • • • • The NonStop Server for Java 4 installation directory on TNS/E systems is /usr/tandem/nssjava/jdk142_h10.
Independent Product Migration Tasks Migrating NonStop Tuxedo Applications Migrating NonStop Tuxedo Applications In most respects, the H-series NonStop Tuxedo application environment is similar to the G-series NonStop Tuxedo environment. Most of the differences are in the application development environment, which apply to all applications. General Considerations • • All TNS/R native applications must be recompiled using an H-series TNS/E native compiler.
Independent Product Migration Tasks Product-Specific Considerations Floating-Point Considerations The default floating-point format on TNS/E systems is IEEE format, instead of the default proprietary Tandem floating-point format on TNS/R systems. However, the release of NonStop Tuxedo on H-series systems internally uses the Tandem floatingpoint format, as does NonStop Tuxedo on G-series systems.
B Migrating TNS Applications to H-Series Systems The H-series environment for developing and executing TNS programs is nearly identical to the G-series TNS environment. The H-series Guardian environment provides binary compatibility with the G-series for running TNS object files. Most Guardian TNS programs require no source code changes or recompilation to run on an H-series system.
TNS Processes on the TNS/E Platform Migrating TNS Applications to H-Series Systems Figure B-1. Native Mode Benefits TNS Programs TNS Interpreted Object Code (Guardian Only) Transaction Services TNS Accelerated Object Code (Guardian Only) Networking Services Guardian API Database Services Open System Services API NonStop Operating System VST 001.
Migrating TNS Applications to H-Series Systems TNS Processes on the TNS/E Platform Table B-1. TNS Code Spaces Process Type Code Spaces TNS process on TNS/R processor UC (user code) UL (user library) SC (system code) SL (system library) SCr (system code RISC) SLr (system library RISC) TNS process on TNS/E processor UC (user code) UL (user library) SC (system code.
Migrating TNS Applications to H-Series Systems Summary of Changes in the H-Series TNS Environment Table B-2.
H-Series TNS Development Tools Migrating TNS Applications to H-Series Systems • • • The OSS environment does not support the TNS development tools or TNS processes. OSS TNS programs must be converted to TNS/E native mode to run on an H-series system. Changes to debugging tools. ° The G-series system level debugger, Debug, is not supported on H-series systems. ° ° Visual Inspect is enhanced with low-level debugging capabilities. H-series Inspect supports TNS debugging only.
H-Series TNS Compilers Migrating TNS Applications to H-Series Systems Table B-3. G-Series and H-Series TNS Development Environments (page 2 of 2) Development Tool G-Series TNS Tool H-Series TNS Tool Guardian TAL compiler TAL TAL TNS link tool XLLINK Not supported.
Migrating TNS Applications to H-Series Systems Binder Utility The H-series TNS compilers are available only in the Guardian environment. They are not supported in the OSS environment. Binder Utility You can use the Binder utility on TNS/E systems to combine TNS code files into a complete executable application program. The bound application can then be executed in interpreted mode, or you can use the TNS/R or TNS/E accelerator utility to accelerate the application.
Object Code Accelerator Utility Migrating TNS Applications to H-Series Systems OCA augments the object file with an Itanium region that contains the Itanium instructions. The augmented object file is said to be an “accelerated” file. The OCAaccelerated object file not only runs significantly faster than the unaccelerated object file, but it also exhibits improved performance over the same object file accelerated using Accelerator on a G-series system. Figure B-2 shows the OCA acceleration process.
H-Series TNS Debugging Tools Migrating TNS Applications to H-Series Systems Figure B-3. Creating an Object File Accelerated for Both TNS/R and TNS/E Systems TNS Compiler TNS Object Code TNS Object Code Axcel TNS Object Code OCA Accelerated Object Code (RISC) Accelerated Object Code (RISC) Accelerated Object Code (Itanium) vst004.vsd You can use Binder on a TNS/E system to combine TNS code files, then use OCA to Note.
Migrating TNS Applications to H-Series Systems H-Series TNS Debugging Tools Inspect H-series Inspect is similar to G-series Inspect; the syntax is identical and it offers most of the same commands. Its use is limited to accelerated or interpreted TNS programs, including Screen COBOL programs; it cannot be used with TNS/E native programs. Using H-series Inspect, you can do symbolic debugging at the source statement level in either interpreted or accelerated execution modes.
Migrating TNS Applications to H-Series Systems H-Series TNS Debugging Tools See these manuals for more information on TNS debugging, including restrictions on debugging accelerated processes: OCA Manual Inspect Manual Visual Inspect Visual Inspect provides a PC-based graphical user interface for high-level symbolic process and snapshot file debugging.
Migrating TNS Applications to H-Series Systems Handling Misaligned Data in TNS Programs INSPECT Attribute Changes The INSPECT process attribute determines which debugger will be selected by the process. The debugger selected depends on the platform (TNS/R or TNS/E), execution mode (TNS or native), and debugger availability. The debugger selected by the INSPECT attribute for TNS processes is shown in the following table.
Migrating TNS Applications to H-Series Systems Using the Fail Option to Detect Data Misalignments the following actions on a system-wide basis for misaligned addresses that would have been rounded down: • • • Allow execution to continue using the rounded-down address (Round option) Allow execution to continue using the natural (unrounded) address (Noround option) Generate a failure trap (Guardian) or a SIGILL signal (OSS) when a misaligned address is detected (Fail option) In addition, an SCF option is
Migrating TNS Applications to H-Series Systems Using EPTRACE to Detect Data Misalignments The Fail behavior can be selected in one of two ways: • • Through SCF. This sets the default behavior for all programs on the system. Through a Binder option. This method overrides the system default behavior, and applies only to the program being bound. The Binder command to select the Fail behavior is SET MISALIGN FAIL.
Migrating TNS Applications to H-Series Systems GDSX Applications Must Be Recompiled C-Series Procedure Extended DCT limits affects calls that: GETSYSTEMNAME Use the return value as an ldev or check for specific error codes LOCATESYSTEM Use the return value as an ldev or check for specific error codes LOOKUPPROCESSNAME Pass a DCT index in the ppd parameter In the G06.23 and later G-series RVUs, the default setting for extended DCT limits is OFF; that is, the extended limits are not in effect.
Migrating TNS Applications to H-Series Systems GDSX Applications Must Be Recompiled Therefore, the application must be recompiled and rebound using the H-series product version of GDSX.
C Reporting Compiler Optimization Problems C/C++ and pTAL program failures that occur at optimization level 2 but not at level 0 or 1 are usually caused by a programming error. Furthermore, the TNS/E compilers perform significantly more optimizations that do the TNS/R compilers. Thus, programs that contain such programming errors might run correctly when compiled at level 2 on a TNS/R system but not on a TNS/E system.
Reporting Compiler Optimization Problems Additional Information Needed for Compiler Errors and Compiler Aborts Additional Information Needed for Compiler Errors and Compiler Aborts To diagnose a compile-time failure, HP requires a preprocessed version of the file that produced the failure.
Reporting Compiler Optimization Problems Additional Information Needed for Runtime Abort Additional Information Needed for Runtime Abort When reporting a runtime abort error, you should provide the same information as for an incorrect results error. If you cannot provide that information, the problem can sometimes be isolated by examining the compiled object file that contains the error, the dump file produced by the object file, and the preprocessed source file in which the error occurred.
Creating an Optimize File Reporting Compiler Optimization Problems Creating an Optimize File An optimize file is a text file that specifies an optimization level at which a particular routine should be compiled. The optimize file is then specified in a parameter on the compiler run command. All routines not specified in the optimize file are compiled at the level specified on the command line. The format of an optimize file is: procedure optimization-level procedure.
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.
dynamic-link library (DLL) Glossary dynamic-link library (DLL). A collection of procedures whose code and data can be loaded and executed at any virtual memory address, with run-time resolution of links to and from the main program and other independent libraries. The same DLL can be used by more than one process. Each process gets its own copy of DLL static data. Contrast with shared run-time library (SRL). See also position-independent code (PIC). eld utility.
Glossary HP NonStop™ Open System Services (OSS) HP NonStop™ Open System Services (OSS). An open system environment available for interactive or programmatic use with the HP NonStop™ operating system. Processes 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. Synonymous with Open System Services (OSS) environment. Contrast with Guardian. HP NonStop™ operating system.
loadfile Glossary 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 Accelerator (OCA) Glossary Object Code Accelerator (OCA). A program optimization tool that processes a TNS object file and produces an accelerated file for a TNS/E system. OCA augments a TNS object file with equivalent Itanium instructions. TNS object code that is accelerated runs faster on TNS/E systems than TNS object code that is not accelerated. See also Accelerator and Object Code Interpreter (OCI). Object Code Interpreter (OCI).
pTAL Glossary pTAL. Portable Transaction Application Language. A machine-independent system programming language based on Transaction Application Language (TAL). The pTAL language excludes architecture-specific TAL constructs and includes new constructs that replace the architecture-specific constructs. Contrast with HP Transaction Application Language (TAL). pTAL compiler. An optimizing native-mode compiler for the pTAL language. public dynamic-link library (public DLL).
TNS Glossary TNS. Refers to 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 native C compiler Glossary 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. Compare to TNS C compiler and TNS/E native C compiler. TNS/R native COBOL compiler. The COBOL compiler that generates TNS/E object files.
user library Glossary H-Series Application Migration Guide—429855-008 Glossary -10
Index Numbers 16-byte aligned data in pTAL 7-7 32-bit ELF format 3-5 64-bit data type 5-14 64-bit ELF format 3-5 A Accelerated execution mode B-1, B-2, B-6/B-10, B-12 Accelerated object file B-8 Accelerator, use on TNS/E systems B-9 Address types, pTAL CBADDR 7-6 CWADDR 7-6 Alignment of COBOL data items 6-5 Architecture, TNS/E native 3-1 Augmented object file B-8 B BEGINCOMPILATION directive 7-3 Binder utility B-7 buildclient and buildserver utilities A-3 BUILD_NEUTRAL_LIBRARY pragma 5-11 C C 64-bit data
D Index COBOL directives (continued) SEARCH 6-5 UL 6-2 COBOL files ECOBEX0 6-5 ECOBEXT 6-5 EXCOBEX1 6-5 NMCOBEX0 6-5 NMCOBEX1 6-5 NMCOBEXT 6-5 Code segments 3-3 Code spaces, TNS B-2 Common code for G-series and Hseries 7-3 Common Run-Time Environment new functions 2-16 run-time library 2-7 Compatibility traps 4-3 Compilers native C 2-3, 5-1 native COBOL 2-4, 6-1 native C++ 2-4, 5-1 pTAL 2-3, 7-1 TNS C/C++, COBOL, pTAL B-6 Condition codes in C/C++ procedures 7-4 Conditional compilation in C and C++ program
E Index Directives, COBOL (continued) LARGEDATA 6-2 LESS-CODE 6-2 NON-SHARED 6-2 OPTIMIZE 6-3 SEARCH 6-3 UL 6-2 Directives, pTAL BEGINCOMPILATION 7-3 GP_OK 7-3 NOCALL_SHARED 7-2 NOOVERFLOW_TRAPS 7-3 NO_GPOK 7-2 OPTIMIZEFILE 7-3 OVERFLOW_TRAPS 7-3 POPGP_OK 7-3 PUSHGP_OK 7-3 SAVEGLOBALS 7-2 SRL 7-3 TARGET 7-2 USEGLOBALS 7-2 DLLs and COBOL programs 6-2 and NonStop Tuxedo A-3 and PIC 3-5 as user libraries 8-1 compared to SRLs 3-5, 3-7 C++ libraries 5-9 implicit 3-2 Dynamic-link libraries See DLLs E ECOBOL co
G Index File-Mnemonic clause 6-5 Floating-point conflicts between programs and linkfiles/DLLs 5-2 in COBOL programs 6-5 in C/C++ programs 5-2 in NonStop Tuxedo applications A-4 Functions pTAL 7-5 with two return values 7-4/7-5 G GDSX applications B-15 GETPOOL procedure 9-1 Global Mission Critical Solution Center (GMCSC) 10-1 Globals-heap segment 3-5 GMCSC 10-1 GP_OK directive 7-3 Guardian procedures affected by increased DCT limits B-15 DEBUG 9-2 DELAY 9-3 GETPOOL 9-1 POOL_GETSPACE_ 9-1 PROCESSORTYPE 9-2
J Index J Java See NonStop Server for Java L LARGEDATA directive 6-2 ld flag 6-6 LD pragma 5-6 ld utility 3-6 ld_obey flag 6-6 LESS-CODE directive 6-2 LIBCOBEY file 5-11 libc.
O Index NonStop Server for Java A-1 NonStop Tuxedo A-3 NON-SHARED directive 6-2 NON_SHARED pragma 5-6 NOOVERFLOW_TRAPS directive 7-3 NSDEE 2-5, 2-18 O Object Code Accelerator compared to Accelerator B-8 description of B-7 use on TNS/R systems B-9 Object file format 3-5 Object files executable 2-8 relinkable 2-8 OCA See Object Code Accelerator Optimization errors exposed by 4-5 reporting problems with C-1 OPTIMIZE directive COBOL 6-3 pTAL 7-3 Optimize file creating C-4 using to collect debugging informati
R Index Private library DLL 3-7 SRL 3-7 Private SRL 3-7 Privileged RISC stack B-4 Procedures C/C++ 7-4 Guardian 9-1/9-3 See also Guardian procedures 9-1 pTAL 7-5 pTAL, with two return values 7-4/7-5 Process File Segment B-4 Processes code segments 3-3 data segments 3-4 organization of 3-2 TNS B-2 TNS/E native 3-1 PROCESSOR_DELAY_ procedure 9-3 PROCESSOR_GETINFOLIST_ procedure 9-3 PROCESSOR_GETNAME_ procedure 9-2 PROCESSOR_TYPE procedure 9-2 PROCESS_DEBUG_ procedure 9-2 pTAL 16-byte data alignment 7-7 comp
T Index SIGILL signal 3-5 Signals facility 3-5 SIGSEGV signal 3-5 Snapshot files, debugging TNS 1-1, 1-5, 2-11 TNS/E 1-1, 2-11 TNS/R 1-1, 1-3, 1-6, 2-11, 2-17 SRL as TNS/R user library 8-1 private 3-7 public 3-7 SRL directive 7-3 SRL pragma 5-6 SRLExportMembers pragma 5-6 SRLExports pragma 5-6 SRLName pragma 5-6 Stacks TNS B-4 TNS/R and TNS/E 3-4 String conversion functions strtoll 5-14 strtoull 5-14 wcstoll 5-14 wcstoull 5-14 System Configuration Utility options for detecting misaligned data B-12 System
V Index Undefined behavior in C/C++ programs 5-13 unsigned long long data type 5-14 Unstructures files, changes required for 4-6 USEGLOBALS directive 7-2 User code 3-2, 3-7 User data segment B-4 User library converting to DLL 8-1 migration tasks 8-1/8-2 overview 3-2, 3-7 _TNS_E_TARGET 5-5 _TNS_R_TARGET 5-5 V VERSION1 pragma 5-6 VERSION1 standard run-time library 5-8 VERSION2 pragma 5-6 VERSION2 standard run-time library 5-8 VERSION3 pragma 5-6 VERSION3 standard run-time library 5-8 Virtual memory 3-2 Vi
Special Characters Index H-Series Application Migration Guide—429855-008 Index -10
