Migration planning - OpenVMS on Integrity Servers

The following summary is based on practical experience gained as part of the EFT (Engineering Field Test) programme. We encourage you to discuss your plans with us so that we can help you arrive at a strategy that meets your business requirements and minimises technical risk.

This set of slides is from the recent HP Netherlands OpenVMS Technical Update in October 2007:

2^nd October 2007 - Migrating to Integrity (PDF, 130KB)

Naming Conventions

The HP Integrity Server range introduces some new terminology that long-time users of Alpha and VAX systems might find confusing at first. Now that we have moved to using bought-in Intel processors with HP manufacturing the System Platforms and the Operating Systems the naming conventions have changed:

IA-64 is the Intel processor architecture
Itanium is the Intel microprocessor family, hence IPF (Itanium Processor Family)
Integrity Server is the HP system platform family
OpenVMS I64 is the HP operating system

OpenVMS Packaging

The HP Integrity Server range introduces a different way of packaging the operating system features with licences that conform to the way in which HP have previously sold systems and software. OpenVMS on Integrity is packaged as follows:

Foundation Operating Environment
Enterprise Operating Environment
Mission-Critical Operating Environment

Higher-tier operating environments enables the use of features not included in the lower tiers. It is possible to add specific features to the lower tiers, for example one can choose to add clustering (from the MCOE) and host-based volume shadowing (from the EOE) to the Foundation Operating Environment.

There is also a Hobbyist Operating Environment for non-commercial use.

Developers should make use of the DSPP developer licensing programme.

OpenVMS software shipments

The OpenVMS installation media for Integrity Servers is shipped on DVD, not on CD. The compiler and linker formats generate much larger image files than on Alpha, so the operating system no longer fits onto a CD. The installation process and mechanisms are the same as on Alpha.

Typical migration and porting considerations

What to look for when porting from your current platform

Take advantage of new features and new ways to do things. In some cases there may be no direct equivalents of the way things are currently implemented.
Direct "bug for bug" port or re-implement your application?
Expansion & growth
Adaptability & flexibility
Overall system design issues

Typical system-wide issues that need to be considered

IO device support
Multiprocessing requirements
Network interconnects
Storage subsystems
Run-time environment and development environment
Availability (uptime, disaster recovery etc.)
Performance (bandwidth, latency etc.)

Application software issues that need to be considered

Synchronisation and serialisation of access to data structures
Data alignment is important for maximum performance
Floating Point format on IA-64 is IEEE. VAX format is supported by software emulation, not in hardware. So, for best performance ensure that you use IEEE floating point formats.
Search out all implicit assumptions of architecture types and architecture specific features. A typical example is code such as "if .not. alpha then assume vax". That will create some interesting results!
Leave it to the compilers on Integrity. The key to performance with IA-64 is the way that the compilers generate the code and data streams to be fed to the CPU.
OpenVMS contains many more system services with documented interfaces than before. Use them rather than implementing your own mechanisms.
The OpenVMS calling standards have changed. This is only an issue if you have code that directly manipulates data structures such as the stack and frame pointers.
Executable image file sizes are significantly larger than on Alpha, primarily due to the standardised ELF and DWARF object module and image file formats
MACRO-32 (VAX assembler) is a compiled language on Integrity and Alpha
There is a binary translator for Alpha executable images to convert them to Integrity executable images, just as there was for VAX to Alpha. Even images translated from a VAX original to an Alpha image can be translated. Binary translation is limited to user mode programs (no system code) and to specific languages due to run-time library support constraints.