Technical summary - OpenVMS on Integrity Servers

VSI OpenVMS V8.4-1H1 and later on Integrity Servers

The -i6 family of HPE Integrity Servers based on octo-core "Kittson" is supported by VSI OpenVMS V8.4-2L1 and later.
These consist of the rack-mount rx2800-i6 and three chassis mount blades: the BL860c-i6, the dual-width BL870c-i6 and the quad-width BL890c-i6.

The VSI OpenVMS releases support some earlier generations of HPE Integrity Servers (the -i2 and -i4 families, plus selected earlier models).

• See the VSI software products web page for Quickspecs, SPD, roadmap and further information.

HPE OpenVMS V8.4 and earlier on Integrity Servers

The -i2 family of Integrity Servers based on quad-core "Tukwila" is the latest available hardware platform that will support HPE OpenVMS V8.4.
These consist of the rack-mount rx2800-i2 and three chassis mount blades: the BL860c-i2, the dual-width BL870c-i2 and the quad-width BL890c-i2.

The Integrity Server systems are very different in initial appearance to the VAX and Alpha systems that OpenVMS users are familiar with. These notes are intended to help you understand some of the key differences that you will come across when you first start to use an Integrity Server system.

Migrating a complex set of applications and software from the large AlphaServer systems such as the GS1280 to the large Integrity blades (BL870c-i2 and BL890c-i2) requires a great deal of 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 and later 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 HPE Software Product Description (SPD) for further information.
• All of the HPE 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!

Integrity Server hardware overview

• 64bit EPIC (Explicitly Parallel Instruction set Computer) architecture. Uses memory to gain peformance.
• Itanium Processor Family architecture relies on compiler output to generate an efficient instruction and data flow through the CPU.
• Needs synchronisation issues to be carefully considered and coded. What was a single "atomic instruction" on VAX can be multiple instructions on Integrity, so instruction flow through the CPU can be interrupted. What was PALcode on Alpha is now part of the operating system (the SWIS layer).
• Instructions are packaged in "bundles" of up to three instructions per bundle – which are then processed entirely in parallel.
• The console interface is very different to that used on Alpha and VAX. The console interface is common across the entire hardware range.
• Uses Extensible Firmware Interface (EFI) rather than BIOS. The latest machines use an extended EFI known as UEFI.
• Note that Tukwila, Poulson and Kittson (-i2, -i4 and -i6) based machines are NUMA (Non-Uniform Memory Access) systems.

Integrity Server console interface

The Integrity Server provides a common console interface across the product range, with a few minor changes where partitioning of cell-based systems does not exist on the smaller machines.

There are usually two consoles, the Management Processor (MP) and Baseboard Management Console (BMC).

EFI (extensible firmware interface) and booting OpenVMS

• EFI is a mini operating system
• FAT formatted file system (FAT12, FAT16, FAT32), OpenVMS currently presents a FAT16 partition to EFI (hidden as a container file in the system disc file structure)
• Boot menu and defaults need to be configured for auto boot of systems
• Environment variables (VMS_FLAGS etc.) can be configured
• VMS_LOADER.EFI - finds and loads IPB.EXE (analogous to APB.EXE and VMB.EXE)
• Data is passed to the boot loader (eg: efi> vms_loader –fl 0,0)
• IPB.EXE (the boot loader) understands the OpenVMS file structure, EFI does not
• IPB.EXE loads the executive into memory
• Control passes to the executive – from here on OpenVMS is OpenVMS
• System reads system parameters (enters SYSBOOT> if flags set) and initialises fixed data structures, then startup continues as normal

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 to user mode programs (no system code) and to specific languages due to run-time library support constraints.