Technical summary - OpenVMS on Integrity Servers

The following technical summary is based on practical experience gained as part of the EFT (Engineering Field Test) programme.

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.

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)

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. The Integrity server has multiple console subsystems:
  • Management Processor (MP);
  • Baseboard Management Console (BMC).
• Uses Extensible Firmware Interface (EFI) rather than BIOS.
• PCI bus based (3.3volt only).

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).

MP console (Management Processor)

• A separate small computer with its own mini-operating system that is in charge of the system box
• The MP runs when base box level power is applied, even with the system off!
• Provides serial (9 pin) and ILO/ILO2 (10/100/1000 LAN) connectivity
• Console configuration (terminal typeVT100+ from terminal emulator). <Ctrl-H> and <Ctrl-B> are used in place of <delete> and <break>, so keymapping is useful for long-time OpenVMS users
• Network configuration (hostname, IP address, etc.) with a private management LAN
• Multiple console sessions (one writer, many readers). Establishes logical connectivity to the BMC console
• Provides ability to copy files over network to local console storage (firmware updates etc.)

BMC console (Baseboard Management Console)

• Runs when main board powered up ( eg: "PC –ON –NC" from MP console)
• Local connectivity (9 pin serial) and logical connectivity (MP console sessions)
• Handles power-up self tests and ACPI device detection
• No graphics console

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