hp.com home products and services support and drivers solutions how to buy
cd-rom home
End of Jump to page title
HP OpenVMS systems

Jump to content

Porting Applications from HP OpenVMS Alpha to HP OpenVMS Industry Standard 64 for Integrity Servers

Porting Applications from HP OpenVMS Alpha to HP OpenVMS Industry Standard 64 for Integrity Servers

Previous Contents Index

2.2.2 Impact on OpenVMS Applications

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

Hewlett-Packard has determined that the most efficient way to utilize the compiler technologies developed by Intel is to adopt two industry standards, both of which are used by the Itanium compiler:

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.

Chapter 3
Assessing Needs for Porting Your Application

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:

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

3.2.2 Identifying Applications to Be Ported

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:

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:

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. Software Dependencies

Software dependencies might include such components as:

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

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. Operating Environment

Consider the following issues regarding the operating environment:

3.2.4 Operational Tasks

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

3.3 HP Porting Resources

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:


A sampling of other resources available include the following:

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.

Previous Next Contents Index