Porting Applications from HP OpenVMS Alpha to HP
OpenVMS Industry Standard 64 for Integrity Servers
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:
- 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
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.
Assessing Needs for Porting Your Application
Typically, porting an application to a new platform involves the
- Assessing porting needs
- Identifying architecture dependencies and nonstandard coding
practices in the application to be ported, and rewriting code
- Compiling, linking, and running the application
- Performing testing before and after porting
- Recompiling the code and repeating steps 1 through 4, as necessary
- Shipping the revised application
- Operating and installing processes or procedures
- 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
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
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
- 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:
- Identifying applications to be ported
- Identify dependencies on other software
- Selecting a porting method
- 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
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
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
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
- 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
- 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
- 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 126.96.36.199).
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
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
188.8.131.52 Software Dependencies
Software dependencies might include such components as:
- Run-time libraries
- HP layered products
- Third-party layered products
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.
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.
184.108.40.206 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
220.127.116.11 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
- 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
- HP Digital Test Manager or an equivalent Open Source tool
3.2.4 Operational Tasks
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
- 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
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:
- Developer and Solution Partner Program (DSPP)
- Test Drive Program
- HP 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.