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:
2nd 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.

© Copyright

