Technical summary - OpenVMS on VAX

The following technical summary is based on practical experience gained over many years.

These notes are intended to help you understand some of the key aspects that you will come across when working with a VAX 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)

VAX hardware overview

• 32bit CISC. Designed when memory was expensive, so instruction set tries to save space where possible (variable length instructions etc.)
• Includes specific instructions to assist when writing operating system software, such as providing guaranteed synchronisation of access to data structures.
• Early VAXes (VAX-11) included PDP11 instructions. Later VAXes use PDP11 software emulation.
• Support a wide range of IO devices and bus structures.
  • Unibus (shared with PDP11 systems such as 11/34 and 11/44)
  • BI bus
  • XMI bus (shared with early Alpha systems such as 8400s [Turbolaser])
  • Q-bus (shared with PDP11 systems such as 11/23 and 11/73)
  • Turbochannel (shared with early Alpha systems such as DEC 3000s [Sandpiper])
• "Bomb-proof" engineering, especially big VAXes (8000s, 6000s etc.).

VAX console interface

Each VAX implementation had its own specific console interface. In general they are fairly consistent between models, certainly for the later mid-range VAXes based around the N-VAX chipset (3100s, 4000s).

Early VAXes generally had a PDP11 acting as a console subsystem.

• ">>>" prompt (dead sergeant)
• Serial and graphics consoles (VAXstations)
• Power-up self tests
• Device detection. Device naming convention generally matches OpenVMS device naming convention - there can be some slight differences with DSSI devices
• Device configuration (SCSI ID, DSSI ID, access to DSSI controllers over DSSI bus etc.)
• System configuration (language, auto boot, etc.)

Booting OpenVMS

• Loader finds VMB (method varies with platform):
  • On system disc via boot block
  • Console ROM or NVRAM
• Data passed in CPU registers (R5 used for boot flags) to boot loader.
• Reads executive into memory
• Reads system parameters (enters SYSBOOT> if flags set) and initialises fixed data structures
• Passes control to executive

Device detection

• Devices appear as a set of CSRs (Control and Status Registers) in physical memory - the IO space.
• Devices have Interrupt Vectors which connect a device interrupt request to the device driver Interrupt Service Routine.
• CSR addresses and contents indicate device type.
• SYSGEN AUTO ALL will scan IO space to find devices and set up OpenVMS device drivers to communicate with the hardware.