HP OpenVMS systems documentation

VAX floating-point formats are supported on the Itanium architecture by converting them to IEEE single and IEEE double floating types. By default, this is a transparent process that will not impact most applications. HP is providing compilers for C, C++, Fortran, BASIC, Pascal, and COBOL, all with the same floating-point options. Application developers need only recompile their applications using the appropriate compiler. For detailed descriptions of floating-point options, refer to the individual compilers' documentation.

Because IEEE floating-point format is the default, unless an application explicitly specifies VAX floating-point format options, a simple rebuild for OpenVMS I64 uses native IEEE formats directly. For programs that do not depend directly on the VAX formats for correct operation, this is the most desirable way to build for OpenVMS I64.

2.3 Object File Format

• ELF (executable and linkable format) describes the object file and executable file formats.
• DWARF (debugging and traceback information format) describes the way debugging and traceback information is stored in the object and executable files.

One clear advantage of this decision is that development tools can be ported to OpenVMS more easily in the future. All of the compilers, development tools, and utilities provided with the OpenVMS I64 operating system will utilize and understand these new formats. Application developers will not need to be concerned with these formats unless their applications have specific knowledge of them.

In a typical application scenario in which an application is compiled, linked, debugged, and deployed, the details of the object file format, the executable image file format, and the debugging and traceback information are of no concern to the developer. However, software engineers who develop compilers, debuggers, analysis tools, or other utilities that are dependent on these file formats will need to understand how they are being implemented on OpenVMS.

Typically, porting an application to a new platform involves the following procedure:

1. Assessing porting needs
2. Identifying architecture dependencies and nonstandard coding practices in the application to be ported, and rewriting code accordingly
3. Compiling, linking, and running the application
4. Performing testing before and after porting
5. Recompiling the code and repeating steps 1 through 4, as necessary
6. Shipping the revised application
7. Operating and installing processes or procedures
8. Supporting and maintaining the application

Although you complete these tasks sequentially, you might have to repeat some steps if problems arise.

This chapter addresses the first task --- assessing porting needs. Subsequent chapters discuss the remaining tasks. This chapter describes the responsibilities and issues that developers should consider in planning to port an application. In particular, it sets the context for porting applications from an OpenVMS Alpha to an OpenVMS I64 environment and provides the information necessary to help developers evaluate needs, plan, and begin porting software.

Appendix A provides a checklist to guide you through the planning and porting process.

3.1 Overview

Most applications running on OpenVMS Alpha today can easily be ported to OpenVMS I64 with few changes. The Alpha and I64 variants of OpenVMS are produced from a single source-code base, enabling developers to incorporate features (that are independent of the hardware) into both versions without requiring multiple changes to the source code. This minimizes the time required to perform qualification testing and helps to ensure the availability of critical applications on both OpenVMS platforms.

HP intends to maintain a strict policy of ensuring and maintaining forward source compatibility so that "well-behaved" applications that run on recommended versions of OpenVMS Alpha will also run successfully on OpenVMS I64 systems. For the most part, if an application takes advantage of published system services and library interfaces, the application should be portable (as is) to the latest version of OpenVMS I64. However, some published system and library interfaces available on OpenVMS Alpha will not be available or will behave differently on OpenVMS I64. In addition, the Linker utility does not support all qualifiers supported on OpenVMS Alpha. For more information about these exceptions, see Chapter 4 and Chapter 5.

OpenVMS I64 has the same look and feel familiar to OpenVMS customers. Minor changes were needed to accommodate the new architecture, but the basic structure and capabilities of OpenVMS are the same.

3.2 Evaluating the Application

The first step to porting an application is to evaluate and identify the steps necessary to port the application to OpenVMS I64. The evaluation process culminates in a porting plan that answers the following questions:

• How do you port the application?
• How much time, effort, and cost does porting require?
• Do you require support from HP services?

The evaluation process has the following four steps:

1. Identifying applications to be ported
2. Identify dependencies on other software
3. Selecting a porting method
4. Analyzing operational tasks

Completing these steps yields the information necessary to write an effective porting plan. Sections 3.2.1 through 3.2.4 suggest the steps for an initial, rudimentary evaluation, after which you can perform a more detailed evaluation of each module, image, and all dependencies.

After you complete the evaluation steps described in the following sections, compare your results with the supported product, procedures, and functionality of the target platform. Research any deviations for schedule mismatches, missing functionality, procedural conflicts, and supportability. To complete your porting plan, include all costs and time impacts.

3.2.1 Selecting the Porting Method

After you complete the evaluation process described in the following sections, you will have to port your application and your development environment. In addition to the source modules, you might have to port other components, such as build procedures, test suites, and in some cases, the application data structures. You must decide on the best method for porting each part of the application. Usually the issue is whether to rebuild your application from sources or to use a binary translator. To make this decision, you need to know which methods are possible for each part of the application, and how much work is required for each method. To help answer those questions, you should answer the series of questions and perform the tasks shown in Figure 3-1.

The majority of applications can be ported by recompiling and relinking them. If your application runs only in user mode and is written in a standard high-level language, it is most likely in this category.

Figure 3-1 Porting an Application

The first step in evaluating an application for porting is to identify exactly what has to be ported. This includes not only the application itself, but everything that the application requires to run properly. To begin evaluating your application, identify and locate the following items:

• Source modules for the main program
• Shareable images
• Object modules
• Libraries (object module, shareable image, text, or macro)
• Data files and databases
• Message files
• Scripts and procedures (build files)
• Application documentation (if any)

Consider the differences between OpenVMS Alpha and OpenVMS I64 described in Chapter 2 and the consequent changes that are necessary for application components prior to porting. In addition, consider the processor-related development issues, as described in Chapter 7.

Evaluate the time and costs required for these changes. Any code that depends specifically on the OpenVMS Alpha architecture must be changed. For example, an application may require changes if it includes code that:

• Deals with specific machine instructions or that makes assumptions about the number of registers or the functions of specific registers.
• Relies on particular elements of the OpenVMS Alpha calling standard. (For differences between OpenVMS Alpha and OpenVMS I64 Calling Standards, see Section 2.1.1.)
• Relies on unpublished system services and library interfaces, or certain system and library interfaces that are not available or will behave differently on OpenVMS I64. (For more information about the availability and divergent behavior of certain system and library interfaces, see Chapter 4 and Chapter 5.)
• Relies on the OpenVMS Alpha object file format, the executable image file format, or the debug symbol table format.
• Is conditionalized or includes logic that assumes it is running on either an OpenVMS VAX or an OpenVMS Alpha system which might not be able to handle a third platform.
• Depends on OpenVMS Alpha or VAX internal data structures; for example:
  • Floating-point formats that are not IEEE standard. (IEEE floating-point formats are the default for OpenVMS I64 and should be used where VAX floating-point formats are not required; for more information, see Section 3.2.4 and Section 4.8.4.)
  • The mechanism array data structure on OpenVMS I64 differs significantly from that on OpenVMS Alpha (see Section 4.8.3.3).

  Note HP recommends that you align your data naturally to achieve optimal performance for data referencing. On both OpenVMS Alpha and OpenVMS I64 systems, referencing data that is unaligned degrades performance significantly. In addition, unaligned shared data can cause a program to execute incorrectly. You must align shared data naturally. Shared data might be between threads of a single process, between a process and ASTs, or between several processes in a global section. For more information about data alignment, see Section 4.8.7 and the HP OpenVMS Programming Concepts Manual.

• References terminal drivers that do not use the call interface; for example, those using jump to subroutine (JSB) macros need to be revised to use the call interface
• Contains user-written threading-like, such as code that performs direct stack switching, that implements a co-routine or tasking model, or that depends on the nature of the procedure call stack frames. For more details, see Section 4.8.6.
• Incorporates nonstandard or undocumented code practices or interfaces.

In addition any source code that does not have a supported compiler on OpenVMS I64 must be rewritten or translated. (For a list of supported compilers, see Chapter 6.) Note also that certain language capabilities of OpenVMS Alpha are not supported on OpenVMS I64; for more information, see the HP OpenVMS Version 8.2 Release Notes. In addition, applications that run in privileged mode might require changes.

For more details about changes required in your source modules prior to porting them, see Chapter 4.

3.2.3 Assessing Dependencies

The next step is to assess the software and environment on which your application depends.

3.2.3.1 Software Dependencies

Software dependencies might include such components as:

• Run-time libraries
• HP layered products
• Third-party layered products
• Tools

Many of these items have already been migrated to OpenVMS I64, including the following:

• HP software bundled with the OpenVMS operating system, including:
  • Run-time libraries
  • Other shareable libraries, such as those supplying callable utility routines and other application library routines
• HP layered products, including:
  • Compilers and compiler RTLs
  • Database managers
  • Networking environment
• Third-party products
  Many third-party products now run on OpenVMS I64. To determine whether a particular application has been migrated, contact the application vendor.

  Important The availability of third-party software can be the biggest obstacle for a porting project. You must determine the availability and cost of third-party software for the target operating system. This might include build environment tools, third-party libraries, and automated testing tools. For information about tools that are freely available on OpenVMS, see Chapter 5.

Consider the development environment upon which your application depends, including the operating system configuration, hardware, development utilities, build procedures (including HP tools such as Code Management System [CMS] and Module Management System [MMS]), and so forth.

3.2.3.3 Operating Environment

Consider the following issues regarding the operating environment:

• System characteristics
  What sort of system is required to run and maintain your application? For example, how much memory is required, how much disk space, and so on?
• Test suite
  Your tests should confirm that the ported application runs correctly, and they should evaluate its performance. Regression testing is crucial to the development of any new product, especially to the porting of an application to a new system. Regression tests aid in testing software on new versions of the operating system and platform. The regression tests can be any one or combination of the following:
  • A software program written by your development team to exercise all possible code paths and functions
  • A series of DCL command procedures
  • Interactive testing conducted manually (instead of automatically by software)
  • HP Digital Test Manager or an equivalent Open Source tool

Evaluate the responsibilities for and needs for operational tasks required to port and maintain the applications, for example:

• Installation requirements
• Compilation requirements
  • Is the compiler that you use for your application also supported on this version of OpenVMS I64?
  • Prior to porting your application, HP recommends that you compile your application on an OpenVMS Alpha system using the latest version of the OpenVMS Alpha compiler. In this way, you can uncover problems that you might encounter when you compile the ported application on OpenVMS I64. Some newer versions of compilers apply a stricter interpretation of existing compiler standards or enforce newer, stricter standards. For more information about compilers supported on this version of OpenVMS I64, see Chapter 6.
  • After testing with a compile on the OpenVMS Alpha system and resolving any problems, you need to port the application to your OpenVMS I64 system, recompile, relink, and requalify. Plan for these activities accordingly.
  • Can you switch to IEEE floating point data types from VAX floating-point data types? In general, applications can still use VAX floating point-format on OpenVMS I64. Use VAX floating point formats when access to previously generated binary floating-point data is required. VAX floating point is achieved on OpenVMS I64 systems in software. HP compilers automatically generate the code necessary to convert VAX floating-point values to the IEEE floating-point format and perform the mathematical operation; however, they then convert the value back to VAX floating-point. This additional conversion adds execution overhead to the application. For this reason, consider switching your application to use IEEE floating-point format.
    Applications on OpenVMS Alpha can be switched to use IEEE floating point with no performance penalty because IEEE floating-point is supported by the Alpha hardware. This will make migration of your application to OpenVMS I64 easier. IEEE floating-point is the only floating-point format supported by the Itanium hardware. In addition, your application will perform better.
    You can test an application's behavior with IEEE floating-point values by compiling it on an OpenVMS Alpha system with an IEEE qualifier. (For many compilers, specify the compiler option /FLOAT=IEEE. If using I64 BASIC, use the /REAL_SIZE qualifer.) If that produces acceptable results, you should simply build the application on the OpenVMS I64 system (and on Alpha, if you wish) using the same qualifier.
    For more information, see Section 4.8.4 and the "OpenVMS Floating-Point Arithmetic on the Intel® Itanium® Architecture" white paper. See the Related Documents section in the Preface for the web location of this white paper.
• Backup and restore functionality
• Operator interface look and feel
• System administration

No single organization has expertise in all phases of a porting process. Therefore, HP has gathered a set of resources that can assist you through the process. These resources can provide everything from porting guides to teams of personnel with equipment that handles the entire porting task. For more information, consult your local HP representative and the Alpha Retain Trust services web site at:

http://www.hp.com/products1/evolution/alpha_retaintrust/services.html

A sampling of other resources available include the following:

• Developer and Solution Partner Program (DSPP)

  http://www.hp.com/go/dspp

• Test Drive Program

  http://www.testdrive.hp.com/

• HP Services

  http://www.hp.com/go/services/

As the HP strategy on the Itanium architecture continues to develop, Sales Resources and Global Services will assess the impact to the long-term plans of HP customers and ISVs. HP will create and document template and custom service offerings to address generic and unique situations of each customer. HP will tailor each service offering to support your needs by making available the tools and resources needed to assist with crucial changes during the transition.

3.4 Additional Considerations

HP recognizes that not all layered software and middleware supplier products will port to OpenVMS I64 at first release. HP is committed to assist software vendors with information, hardware, support, and tools that will facilitate this process. Each vendor should monitor the progress of the supplier of their prerequisite software to ensure that the required components are in place for their development schedules.

HP intends to implement a tool suite on the existing OpenVMS Alpha platform that will make porting to the new OpenVMS I64 platform transparent for most developers in terms of the code base, commands, and process. Nothing will replace the testing that accompanies any quality product release. Rather, this tool suite will reduce the time required for product porting.