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.

Gartner report on "Best practices: Migration planning for AlphaServer users" lists XDelta Limited (March 2009)

XDelta Limited is listed as one of eleven companies world-wide that undertake such work.

Migrating to Integrity from the HP Netherlands OpenVMS Technical Update (October 2007)

OpenVMS performance on Integrity Servers from the HPUG London OpenVMS Update (2008)

OpenVMS on Integrity - bare metal install from a HPUG seminar (February 2005)

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.

Developers should make use of the HP DSPP developer licensing programme. See the HP DSPP web site for further information.

There is also a Hobbyist Operating Environment for non-commercial use. See the OpenVMS Hobbyist web site for further information.

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.