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.

We have hands-on experience with all of the Integrity Server range, from the early rx2600 through to the recent bl890c-i2 quad-width blades. Migrating the large AlphaServer systems such as the GS1280 to the large Integrity blades (BL870c-i2 and BL890c-i2) requires careful planning and experience.

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 historically sold systems and software. OpenVMS V8.4 on Integrity is licenced on a per socket (not per-core) basis and is packaged as follows:

• Base Operating Environment - BOE
• High Availability Operating Environment - HA-OE

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 and host-based volume shadowing (from the HA-OE) to the BOE.

• See the Software Product Description (SPD) for further information.
• All of the OpenVMS related Software Product Descriptions (SPDs) are available at the SPD web page.

Developers should make use of the HP Alliance One developer licensing programme. See the HP Alliance One 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. The boot process via EFI shell is very different from 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.