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.03 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.
H-Series Application Migration Guide Glossary Index Figures What’s New in This Manual vii Manual Information vii New and Changed Information About This Manual ix Organization of This Manual Notation Conventions x Tables vii ix 1.
3. TNS/E Native Architecture Features Contents TNS/E Native Development Tools (continued) TNS/E Native Linker and Loader 2-7 Native Object File Tool 2-9 TNS/E Native Mode Debugging Tools 2-9 H-Series Common Run-Time Environment (CRE) Changes 2-15 New Memory Block Functions 2-16 New Memory Allocation Function 2-16 Developing TNS/R Native Programs on H-Series Systems 2-16 Setting Up a Cross-Platform Development Environment on the PC 2-17 3.
. Native C and C++ Migration Tasks Contents 5.
. Native COBOL Migration Tasks (continued) Contents 6. Native COBOL Migration Tasks (continued) Files Renamed 6-5 ecobol Command Line Flags Changed 6-6 7.
10. Where to Go for Assistance Contents 10. Where to Go for Assistance HP Services 10-1 Assessment Services 10-1 Pilot (Proof of Concept) Service 10-1 Global Customer Support Center (GCSC) 10-1 A. Independent Product Migration Tasks Migrating NonStop CORBA Applications A-1 General Considerations A-1 Product-Specific Considerations A-1 Migrating NonStop Server for Java 4 Applications Migrating NonStop Tuxedo Applications A-3 General Considerations A-3 Product-Specific Considerations A-3 A-1 B.
Glossary Contents Glossary Index Figures Figure 2-1. Figure 2-2. Figure 2-3. Figure B-1. Figure B-2. Figure B-3. Project Properties Screen 2-19 ETK Solution With One Project 2-19 ETK Solution With Two Projects 2-20 Native Mode Benefits TNS Programs B-2 OCA Acceleration Process B-8 Creating an Object File Accelerated for Both TNS/R and TNS/E Systems B-9 Tables Table 2-1. Table 2-2. Table 2-3. Table 2-4. Table 2-5. Table 2-6. Table 3-1. Table 3-2. Table 3-3. Table B-1. Table B-2. Table B-3.
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.03 and all subsequent H-series RVUs until otherwise indicated in a replacement publication.
What’s New in This Manual New and Changed Information H-Series Application Migration Guide —429855-006 viii
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 G-Series-to-H-Series Migration Paths Both the G-series and the H-series RVUs support TNS execution modes (interpreted and accelerated) and native execution mode.
Migration Overview Converting TNS Programs to TNS/E Native Mode the RISC and Itanium processors, TNS/R native programs must be recompiled before they can be executed on an H-series system. TNS/R native object code cannot be executed on an H-series system, and no interpreter or accelerator is provided to emulate RISC instructions on the H-series system. Migrating a TNS/R native application to TNS/E native mode requires, in most cases, no source code changes.
TNS Environment Migration Overview TNS Environment The H-series RVUs provide the same compilers and tools as the G-series RVUs. Major differences in the G-series and H-series TNS environments are: • • • • A new accelerator tool is provided. The H-series Object Code Accelerator (OCA) is used instead of Accelerator. (Accelerator is still available on H-series systems for accelerating TNS object files to be executed on a TNS/R system.
Developing TNS/R Applications on a TNS/E System Migration Overview For additional details on these topics, see Section 2, The TNS/E Native Development Environment. Developing TNS/R Applications on a TNS/E System TNS/R development tools are supported on TNS/E systems. You can compile and link TNS/R native programs on a TNS/E system, and you can debug TNS/R native snapshot files on a TNS/E system. However, TNS/R native object files, which consist of RISC instructions, cannot be executed on a TNS/E system.
G-Series TNS Mode to H-Series TNS Mode Migration Overview 6. Compile and link the program using the appropriate TNS/E native compiler and linker. (The TNS/E native compilers and linker have different names but support most of the same parameters.) See the following for details: • • • • C/C++ Programmer’s Guide COBOL Manual for TNS/E Programs pTAL Reference Manual eld Manual 7. If necessary, debug the program using a TNS/E native debugger. The debuggers have changed on H-series systems.
Migration Overview G-Series TNS Mode to H-Series TNS Mode H-Series Application Migration Guide —429855-006 1 -8
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 pTAL compiler can be run in the Guardian environment and on the PC either at the Windows command prompt or as part of ETK.
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 exception handling). 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 ETK (TDS is not supported in the H-series RVUs).
Cross-Compiling on the PC The TNS/E Native Development Environment From the Windows Command Prompt From the PC, you can target compilation for either the TNS/R native or TNS/E native environment, then copy the object files to the appropriate NonStop system and execute them in the Guardian and OSS environments. Table 2-2 shows the PC-based cross compilers. Table 2-2. PC-Based Development Tools Tool Target Platform TNS/R Target Platform TNS/E Native C or C++ compiler c89.
TNS/E Native Run-Time Libraries The TNS/E Native Development Environment projects to equivalent ETK projects. The tool plugs into TDS. It can be obtained from IPM Scout at no charge. Note. The TDS-to-ETK migration tool runs as part of TDS; therefore, you must install the tool and perform the migration on a G-series system with TDS installed. The migration tool does not require ETK to perform the migration. The terminology used by TDS and ETK differs somewhat.
TNS/E Native Linker and Loader The TNS/E Native Development Environment Table 2-3. G-Series and H-Series Run-Time Libraries G-Series SRL Name H-Series DLL Name Library Guardian PC Guardian PC C++ VERSION2 standard runtime library ZRWSLSRL ZCPLSRL libstd.srl libC.srl ZCPPCDLL ZCPP2DLL libcppc.so libcpp2.so C++ VERSION3 standard runtime library ZSTDSRL libstl.srl ZCPPCDLL ZCPP3DLL libcppc.so libcpp3.so Tools.H++ 7.0 ZTLHSRL libtlh.srl ZTLH7DLL libtlh7.
The TNS/E Native Development Environment TNS/E Native Linker and Loader eld has some additional functionality compared to ld. One significant difference is that eld has the combined functionality of ld and the TNS/R native non-PIC linker nld. For example, eld can create relinkable object files (linkfiles) as well as loadfiles, whereas ld can create only loadfiles. See the eld Manual for details. The TNS/E run-time loader rld is identical to the TNS/R run-time loader rld.
The TNS/E Native Development Environment • Native Object File Tool An option to specify treatment of unresolved symbols. Options are to treat them as errors, to issue warnings, or to ignore them. See the eld Manual for details on these and other enhancements, as well as options used in building DLLs. 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).
The TNS/E Native Development Environment TNS/E Native Mode Debugging Tools H-series systems. The Inspect debugger is available on H-series systems, but can be used only for debugging TNS processes. Visual Inspect Visual Inspect is the primary application debugging tool in the TNS/E native environment. The H-series version of Visual Inspect debugger includes the same functionality as the G-series version.
The TNS/E Native Development Environment TNS/E Native Mode Debugging Tools intended as a replacement for the G-series Debug facility and the G-series Inspect debugger for native mode debugging. The command name for Native Inspect is eInspect. Note. Native Inspect cannot currently be used to debug COBOL programs. Visual Inspect is the recommended debugger for H-series COBOL programs. Native Inspect provides most of the functionality of Inspect and Debug.
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 S kill T bt, tn 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 in the H-series RVUs. The ability to switch debuggers can be useful in situations such as: • • A native mode program enters the debug state under control of Inspect or Native Inspect, but you want to use Visual Inspect instead. A TNS mode program automatically enters the debug state under control of Native Inspect.
The TNS/E Native Development Environment New Memory Block Functions New Memory Block Functions The following new memory block functions are defined: wmemchr Searches for a wide character in a block of memory wmemcmp Compares two blocks of wide-character memory wmemcpy Copies a block of wide-character memory wmemmove Moves a block of wide-character memory wmemset Initializes a block of wide-character memory to a specified character value New Memory Allocation Function CRE has a new memory allocat
The TNS/E Native Development Environment Setting Up a Cross-Platform Development Environment on the PC Table 2-6. TNS/R Tools in H-Series Tool Description nld TNS/R native non-PIC linker noft TNS/R native object file utility Visual Inspect Use the H-series version to debug TNS/R snapshot files on a TNS/E platform In addition to these tools, all required TNS/R native run-time libraries and header files are also available on the H-series.
The TNS/E Native Development Environment Setting Up a Cross-Platform Development Environment on the PC 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 Setting Up a Cross-Platform Development Environment on the PC 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 Setting Up a Cross-Platform Development Environment on the PC 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-6 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-006 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-4 Native C and C++ Run-Time Library and Tools.h++ Migration Issues on page 5-7.
Possible Source Code Changes Native C and C++ Migration Tasks See the C/C++ Programmer’s Guide for details on compiling and linking TNS/E native C and C++ programs. Possible Source Code Changes The following paragraphs describe changes you might need to make to applications that use certain features.
Native C and C++ Migration Tasks Check Programs With Variable-Length Parameter Lists Check Programs With Variable-Length Parameter Lists The TNS/E native C and C++ compilers use 64-bit containers for passing parameters, instead of the 32-bit containers used by the TNS/R compilers. Programs that directly manipulate parameter arguments in functions that have a variable-length parameter list must be changed to manipulate the 64-bit containers. You should use the standard macros in
Native C and C++ Migration Tasks Check Use of Feature Test Macro Check Use of Feature Test Macro The _TNS_E_TARGET feature test macro replaces the _TNS_R_TARGET macro in the TNS/E native C and C++ compilers. This macro identifies the platform on which a program is being compiled to run. It can be used to conditionally compile code, as in this example: #ifdef _TNS_E_TARGET /* TNS/E-specific code goes here. */ #else /* Other code goes here.
Changed Pragmas Native C and C++ Migration Tasks Changed Pragmas These pragmas that have changed in the H-series RVUs: Pragma Reason for Change Recommended Action (for execution on Hseries system) EXTERNDATA GP_OK GP-relative addressing not supported in H-series. Pragma ignored, warning issued INSPECT Selects different debuggers. No change required (see INSPECT/NOINSPECT Pragmas Select Different Debuggers on page 5-5) NON_SHARED Non-PIC not supported in H-series.
C89 Flags Changed Native C and C++ Migration Tasks NOINSPECT selects: G-Series (PIC and Non-PIC) H-Series Debug Native Inspect C89 Flags Changed These flags are changed in the H-series OSS and PC environments: Flag Reason for Change Action Required -Wld H-series has new PIC linker Replace with -Weld -Wnld Non-PIC linker not supported Replace with -Weld -Wnld_obey (the corresponding pragma is LINKFILE, which is unchanged but submits commands to eld instead of nld).
Native C and C++ Migration Tasks Native C and C++ Run-Time Library and Tools.h++ Migration Issues Similarly, the following sequence also has unintended results when used in a TNS/E compilation: #ifndef TNS_R_TARGET printf ("Code intended for TNS"); printf ("Unintentionally compiled for TNS/E"); #endif In this case, the statement #ifndef TNS_R_TARGET also evaluates to true on a TNS/E platform. In general, you should avoid using #ifndef for conditional compilation.
Library Names Changed Native C and C++ Migration Tasks The following C++ library migrations should require no additional source code changes: • • C++ VERSION2 on G-series to C++ VERSION2 on H-series C++ VERSION3 on G-series to C++ VERSION3 on H-series The following migrations will likely require source code changes: • • C++ VERSION1 on G-series to C++ VERSION2 or VERSION3 on H-series C++ VERSION2 on G-series to C++ VERSION3 on H-series For this migration, It is recommended that you first convert to C
Native C and C++ Migration Tasks Migrating to the C++ Standard Library VERSION2 Migrating to the C++ Standard Library VERSION2 Migrating from C++ VERSON1 to C++ VERSION2 should require few or no source code changes. In most cases, simply specify the VERSION2 directive (or the -Wversion2 flag) when you compile the program. If you are linking the program as a separate step (rather than allowing the C++ driver to perform the link), you must also specify the ZCPPCDLL and ZCPP2DLL DLLs on the eld command.
Native C and C++ Migration Tasks LIBCOBEY and libc.obey Files Replaced LIBCOBEY and libc.obey Files Replaced The run-time libraries required for H-series C and C++ programs are different from those required for G-series programs. The G-series obey files used to link these libraries— LIBCOBEY (Guardian) and libc.obey (OSS and PC)— are replaced by new files that list the DLLs required for H-series programs. The names of these new obey files are LIBTXT (Guardian) and lib.txt (OSS and PC).
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-7 for more information. MAXALIGN Aligns composite objects to the maximum alignment (16byte alignment). See Maximum Data Alignment on page 5-12 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.
Native COBOL Migration Tasks Symbol Dictionary Requires More Space error is not diagnosed and, in fact, the program executes normally. The TNS/E COBOL compiler does detect this error. Therefore, if a TNS/R COBOL program uses a 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).
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: • • When t
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.
Procedures Having New Return Values Guardian API Migration Tasks or native), debugger availability, and the setting of the INSPECT process attribute (see Process Attributes on page 3-2 for details). Note1. It is possible to configure a system with no debuggers. If a system is configured with no debuggers, an event that would have invoked a debugger is, instead, either ignored or generates a signal. Note2. Native Inspect cannot currently be used to debug COBOL programs.
Guardian API Migration Tasks New Return Values for TOSVERSION and REMOTETOSVERSION New Return Values for TOSVERSION and REMOTETOSVERSION The TOSVERSION and REMOTETOSVERSION identify the version of the operating system that is running. On H-series systems, the new return value is 0x5206 is defined, which corresponds to H06. Superseded Procedures The following procedure is superseded by a new procedure in the H-series RVUs. It is still supported, but the new procedure is preferred.
Guardian API Migration Tasks H-Series Application Migration Guide —429855-006 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. Visit the following website for more information about these services: http://www.hp.com/hps/servers/sr_nonstopevol.
Where to Go for Assistance Global Customer Support Center (GCSC) H-Series Application Migration Guide—429855-006 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-006 Glossary -10
Index Numbers 16-byte aligned data in pTAL 7-7 32-bit ELF format 3-5 64-bit data type 5-12 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-10 C C compiler 64
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-15 run-time library 2-6 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-8 implicit 3-2 Dynamic-link libraries See DLLs E ECOBOL co
G Index File-Mnemonic clause 6-5 Floating-point 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 Customer Support Center (GCSC) 10-1 Globals-heap segment 3-5 GP_OK directive 7-3 Guardian procedures affected by increased DCT limits B-15 DEBUG 9-1 DELAY 9-3 GETPOOL 9-1 POOL_GETSPACE_ 9-1 PROCESSORTYPE 9-2 PROCESSOR_GETINFOLIST_ 9-2 PROCESSOR_GETNAME_ 9-2 PROCESS_DEBUG_ 9-1 P
J Index J Java See NonStop Server for Java L LARGEDATA directive 6-2 ld flag 6-6 LD pragma 5-5 ld utility 3-6 ld_obey flag 6-6 LESS-CODE directive 6-2 LIBCOBEY file 5-10 libc.
O Index NON-SHARED directive 6-2 NON_SHARED pragma 5-5 NOOVERFLOW_TRAPS directive 7-3 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-7 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 information C-2 OSS c89 command 2-2, 2-4, 2-16, 5-1 c89 flags 5-6 ecobol
R Index 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-2 PROCESSOR_GETNAME_ procedure 9-2 PROCESSOR_TYPE procedure 9-2 PROCESS_DEBUG_ procedure 9-1 pTAL 16-byte data alignment 7-7 compiler 2-3, 7-1 conditional compilation 7-3, 7-7 d
T Index Snapshot files, debugging TNS 1-1, 1-5, 2-10 TNS/E 1-1, 2-10 TNS/R 1-1, 1-3, 1-6, 2-10, 2-16 SRL as TNS/R user library 8-1 private 3-7 public 3-7 SRL directive 7-3 SRL pragma 5-5 SRLExportMembers pragma 5-5 SRLExports pragma 5-5 SRLName pragma 5-5 Stacks TNS B-4 TNS/R and TNS/E 3-4 String conversion functions strtoll 5-12 strtoull 5-12 wcstoll 5-12 wcstoull 5-12 System Configuration Utility options for detecting misaligned data B-12 System library 3-2, 3-6, 3-7 T TAL compiler B-6 Tandem Developme
V Index 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 V VERSION1 pragma 5-5 VERSION1 standard run-time library 5-7 VERSION2 pragma 5-5 VERSION2 standard run-time library 5-7 VERSION3 pragma 5-5 VERSION3 standard run-time library 5-7 Virtual memory 3-2 Visual Inspect use with TNS programs B-11 use with TNS/E native programs 2-6, 2-6, 2-6, 2-10 Special Character
Special Characters Index H-Series Application Migration Guide —429855-006 Index -10
