The OpenVMS Frequently Asked Questions (FAQ)


Previous Contents Index

14.3.9 Why do my EFI Boot Aliases Fail?

OpenVMS I64 boot aliases contain signature information referencing the specific volume, meaning that the entries are specific to the disk volume and not the disk device. This also means that certain operations, such as the SET BOOTBLOCK command or the RUN SYS$SETBOOT.EXE operation that can rewrite these volume signatures (signature or GUID values) can render existing boot aliases unusable.

If your boot aliases do not function as expected, first try removing and re-adding them; this will resynchronize the boot aliases with the volume contents. If you are using the SET BOOTBLOCK command or the RUN SYS$SETBOOT.EXE operation to rewrite the disk bootblock, you can request that the current signatures (if any) be preserved, and this will typically maintain the validity of your EFI console boot aliases.

14.3.10 Can OpenVMS access the EFI console Boot Aliases?

For access to the EFI console environment from OpenVMS I64, see the BOOT_OPTIONS.COM command procedure, and the EFI SET, SHOW and BCFG mechanisms. Details on these are in the System Manager's and particularly in the System Manager's Utilities manual.

For related information on boot aliases, please see Section 14.3.5.1.

14.3.11 Downloading and using EFI Console Firmware?

HP Integrity EFI system firmware can be downloaded in the form of a bootable image master, unzipped and then burned onto CD or DVD media (please see Section 9.7 for details of recording optical media directly on OpenVMS), and the system can then generally be booted off the created media to perform the EFI firmware upgrade.

The HP Integrity Server website is accesssable via the following URL, and the available services and support information there has links to the available platform-specific firmware images and upgrade-related materials:

To use the following sequence, you will need a writable or rewritable CD drive and software, and a blank CD-R or CD-RW disk. If you use CD writer software for another platform, you will want to use the block, binary, ISO or raw mode operations appropriate for the particular chosen recording package. The following directions assume use of OpenVMS and native CD-R capabilities, please see Section 9.7 for associated details.

  1. First, you must acquire the Integrity server firmware from the above URL. Select the platform, and navigate to the supporting information and specifically to the Download Drivers and Software link
  2. Select Cross operating system (BIOS, Firmware, etc.)
  3. Locate the appropriate ISO-format firmware file. There are several firmware file formats available and there are also various off-line diagnostic images, choose the ISO-format firmware file.
  4. Read the directions for the firmware file, then download the ISO-format firmware (zip-compressed) file. A binary-mode FTP transfer should be used.
  5. Unzip the file into the corresponding .ISO data file. Somewhat confusingly, the .ISO extension can indicate either a block-oriented raw image of a disk, or a disk with the ISO-9660 volume structure. In this case, the former is intended and this file contains a a block copy or disk image of the firmware disk for the platform, and may or may not be an ISO-9660 volume structure. The unzip tool is available on the OpenVMS Freeware and elsewhere; please see Section 13.11 for details and locations.
  6. Use CDRECORD or other available recording tool (please see Section 9.7 for related details) to burn a CD-R or CD-RW disk, specifying the ISO file as the source for the burn operation.
  7. Shut the Integrity Server system down to the EFI console level.
  8. Unload the recorded CD media from the CD-R drive, label it, and load it into the Integrity console drive. This assuming the disk was not generated directly on an Integrity CD-R/RW-capable drive, of course.
  9. Using the EFI shell, display the current firmware version using the command


    info fw 
    

  10. Exit the EFI shell and select the boot options maintenance menu; create a boot alias for the removable media drive for the CD; for the newly-created firmware disk.
  11. Boot it. Follow the directions displayed by the firmware loader and related documentation, heeding the release notes that were reviewed earlier.
  12. Perform a cold restart of the Integrity server.

For information on Alpha SRM console firmware upgrades, please see Section 14.3.7.

14.4 What platforms will OpenVMS operate on?

For the list of boxes that are officially and formally supported by OpenVMS Engineering, please see the OpenVMS Software Product Description (SPD).

Sometimes a particular and officially unsupported Alpha box or Alpha motherboard will sufficiently resemble a supported box that the platform can effectively mimic and can bootstrap OpenVMS. Alternatively, somebody (usually one or more engineers within the OpenVMS Engineering group) will have put together a bootstrap kit -- such as the kit for the Alpha Multia---which permits OpenVMS to bootstrap on the platform.

Contrary to the assumptions of some folks, there are platform-level differences even within the VAX and within the Alpha platforms--- hardware-level differences that can require moderate to extensive new coding within OpenVMS. Within a platform series, and particularly within Alpha platforms (and those few VAX systems) that support Dynamic System Recognition (DSR), OpenVMS can usually bootstrap.

DSR is a mechanism by which OpenVMS can gather platform-specific information, and DSR is the reason why newer Alpha systems can be more easily and more commonly supported on older OpenVMS Alpha releases. DSR is implemented with OpenVMS Alpha code, with SRM console code, and with platform non-volatile memory.

OpenVMS users with experience on older OpenVMS VAX releases and VAX hardware will recall that then-new VAX systems either required an OpenVMS VAX upgrade, or that earlier releases would mis-identified then-newer VAX systems---such as the case of the VAX 7000 model 800 being (mis)identified as a VAX 7000 model 600 when bootstrapped on OpenVMS VAX V5.5-2. (This (mis)identification was the outcome of a deliberate engineering effort to permit the VAX 7000 model 800 to bootstrap on V5.5-2; the system manager could configure the VAX 7000 model 800 to (mis)identify itself as a model 600, to permit the system to bootstrap on V5.5-2.) OpenVMS VAX and VAX platforms lack DSR support.

OpenVMS I64 (please see Section 14.4.5 for Intel Itanium terminology) supports a platform-level feature similar to the OpenVMS Alpha DSR mechanism, based on the ACPI interface and the byte-code interpreter implemented within OpenVMS, within the EFI console, and particularly within non-volatile memory located on (byte-code interpreter compliant) PCI I/O hardware. ACPI tables provide the information that was formerly retrieved from DSR and from the SRM, and the byte-code interpreter can (theoretically) permit at least limited operations with (compliant) PCI hardware, whether or not OpenVMS has a driver for the particular hardware.

The byte code interpreter may or may not permit operations with any particular PCI hardware, and may or may not have sufficient performance for local requirements, and PCI hardware may or may not include the necessary ROM-based drivers in the PCI hardware non-volatile storage. (The intent of this Intel platform-level effort is to move the host software drivers out onto the specific PCI hardware, and to permit the same byte code to operate regardless of the particular host platform.) At least the initial releases of OpenVMS I64 will not have support for the byte code interpreter nor for arbitrary PCI or system hardware, but will have support for ACPI-based system identification and system configuration.

14.4.1 on the Alpha Multia?

Yes, there are a set of unsupported images that permit specific OpenVMS Alpha versions to bootstrap on the Multia UDB system. These images and the associated instructions are available at the OpenVMS Freeware website:

Look in the Freeware V5.0 /multia/ directory.

Instructions are included IN the kits. READ THE INSTRUCTIONS. PLEASE!

Some of the restrictions involved when running OpenVMS on the Multia system include (but may well not be limited to) the following:

The Multia images are not included on the OpenVMS Freeware V4.0 CD-ROM kit, the kit that was distributed with OpenVMS V7.2. (These images became available after Freeware V4.0 shipped.)

Other sources of information for OpenVMS on Multia include:

14.4.2 on AlphaPC 164LX? AlphaPC 164SX?

OpenVMS Alpha is not supported on the AlphaPC 164LX and 164SX series, though there are folks that have gotten certain of the LX series to load SRM and bootstrap OpenVMS. (The Aspen Durango II variant, specifically.)

One problem has been generally reported: ATA (IDE) bootstraps will fail; SCSI storage and a SCSI CD-ROM device is required.

Also see Section 14.4.2.1.

14.4.2.1 on the NoName AXPpci33 system?

Information on bootstrapping OpenVMS (using the Multia files described in Section 14.4.1) on the (unsupported) NoName AXPpci33 module is available at:

Tips for using the Multia files with the AXPpci33:

14.4.3 on the Alpha XL series?

No.

OpenVMS Engineering does not formally support the Alpha XL series, nor will OpenVMS (informally) bootstrap on the Alpha XL series.

OpenVMS can not, will not, and does not bootstrap on the Alpha XL series. The Alpha XL series was targeted for use (only) with the Microsoft Windows NT operating system. 

The Alpha XL platform does not resemble other supported platforms.

14.4.4 OpenVMS on the Personal Workstation -a and -au series?

Though OpenVMS is not supported on the Personal Workstation -a series platforms, OpenVMS might or might not bootstrap on the platform.

If you wish to attempt this, you must ensure that all graphics and all I/O controllers in the system are supported by OpenVMS. You must also ensure that you have the most current firmware loaded.

Here are some salient differences within the various Personal Workstation series:

For obvious reasons, most folks will prefer and will select a Miata GL system, given the choice between the Miata MX5 and the Miata GL series. And as for your next question, you cannot necessarily nor easily distinguish the Miata MX5 from the Miata GL based solely on the model number.

See Section 14.4.4.2 for related details.

14.4.4.1 OpenVMS on the Whitebox Windows-Only series Alpha?

Though OpenVMS is not supported on the "Whitebox" series of Alpha platforms, OpenVMS might or might not bootstrap on the platform. These systems were specifically configured, targeted and supported only for use with the Microsoft Windows NT operating system.

On some of the "Whitebox" systems, the following sequence of console commands can potentially be used to convert the system over to unsupported use by and for OpenVMS Hobbyist users. (But please note that if you wish to attempt this, you must ensure that all graphics and all I/O controllers in the system are supported by OpenVMS, and you must ensure that you have the most current SRM firmware loaded. (For information on locating and downloading the most current Alpha SRM firmware, please see Section 14.3.7.1.) And you must realize that the resulting Whitebox configuration will be entirely unsupported and may or may not be stable and useful.)


set os_type vms 
cat nvram  ! too see what is in this, if anything 
edit nvram 
10 set srm_boot on 
20 e 
init 

If your nvram has other contents, you will need to change the line numbers (10 and 20) to reflect the contents of your configuration. To obtain documentation on the commands of the console editor, enter the ? command within the editor.

The above sequence was reportedly tested on the DIGITAL Server 3300 series, a relative of the AlphaServer 800 series. The DIGITAL Server 3300 is not supported by OpenVMS, though the AlphaServer 800 series is a supported platform. The sequence may or may not work on other platforms, and may or may not work on the DIGITAL Server 3300 platform.

Also see Section 5.33.

14.4.4.2 OpenVMS and Personal Workstation ATA (IDE) bootstrap?

OpenVMS will boot and is supported on specific Personal Workstation -au series platforms, though OpenVMS will require a SCSI CD-ROM if the Intel Saturn I/O (SIO) IDE chip is present in the configuration--- only the Cypress IDE controller chip is supported by OpenVMS for IDE bootstraps. (Configurations with the Intel SIO are not generally considered to be supported systems.)

If you have an -au series system, you can determine which IDE chip you have using the SRM console command:


  SHOW CONFIGURATION 

If you see "Cypress PCI Peripheral Controller", you can bootstrap OpenVMS from IDE storage. If you see "Intel SIO 82378", you will need to use and bootstrap from SCSI. (A procedure to load DQDRIVER on the Intel SIO---once the system has bootstrapped from a SCSI device---is expected to be included as part of the contents of the DQDRIVER directory on Freeware V5.0 and later.)

Many of the -a series systems will include the Intel SIO, and thus cannot bootstrap from IDE.

See Section 14.4.4 for related details.

14.4.5 On the Intel Itanium IA-64 platform?

OpenVMS has been ported to the Intel IA-64 architecture; to HP Integrity systems based on the Intel Itanium Processor Family.

The first release of OpenVMS I64 was V8.0, with the first general or first production release of OpenVMS I64 known as V8.2. Yes, there was a V8.1 release, too.

Some Intel and HP terminology: Itanium Processor Family is the name of the current implementation; of the current Intel microprocessor family implementing the IA-64 architecture. IA-64 is the name of the Intel architecture implementing the VLIW (Very Long Instruction Word) design known as EPIC (Explicitly Parallel Instruction Computing).

I64 is the name of a family of HP computer systems that use Intel Itanium processors and that are supported by "HP OpenVMS for Integrity Servers" (and itself more commonly known as "OpenVMS I64"); by one of the HP operating systems that runs on HP Integrity hardware.

The Extensible Firmware Interface (EFI) is the name of the console environment for Itanium systems, and the Baseboard Management Console (BMC) and the optional Management Processor (MP) are the most typical hardware interfaces into the system console.

14.4.5.1 Where can I get Intel Itanium information?

Intel Itanium Processor Family and IA-64 Architecture, Hardware, Software, and related docoumentation materials are available at:

Information on the classic Intel Extensible Firmware Interface (EFI) (for IA-64) and of the multi-platform Unified EFI (UEFI) console project documentation are available at the following URLs:

Please see Section 14.4.5 for Intel Itanium terminology.

14.5 What is the least expensive system that will run OpenVMS?

The cheapest systems that are or have been recently offered by HP that will run OpenVMS Alpha are the AlphaServer DS10 server, the AlphaStation XP900 workstation, the AlphaStation VS10 workstation, and the AlphaStation XP1000 workstation. Other companies sell Alpha-powered systems and Alpha motherboards, some of which will run (and can be purchased with) OpenVMS---see the OpenVMS Software Product Description (SPD) for details on the supported systems and configurations. There are also many used AlphaStation, AlphaServer, and DEC 3000 series models available which are quite suitable. For more experienced OpenVMS system managers, the (unsupported) Multia can bootstrap OpenVMS---see Section 14.4.1 for details.

Used Itanium-based systems that a hobbyist could likely use to bootstrap OpenVMS I64 have been seen selling on auction websites for under US$1000. New Integrity rx2620 series systems (officially supported by OpenVMS I64) have been offered as part of a week-long DSPP porting and training package for US$2000. See Section 2.8.3 for details on the DSPP program. Also see the HP Renew used- and/or refurbished-equipment program for any hardware that might be available.

Free and commercial VAX software-based hardware emulators are available for various platforms. See Section 13.12 for details on those.

Hobbyist-related hardware platform selection information---various options and considerations around VAX, Alpha and Integrity systems, and an introduction to hardware emulation---is available at: http://www.hoffmanlabs.org/ )

Depending on the OpenVMS version and configuration, the OpenVMS Software Product Description (SPD) is available at:

When purchasing a system, ensure that the system itself is supported, that the system disk drive is supported or closely compatible, that the optical (CD or DVD) drive is supported or is closely compatable and that (in the case of SCSI devices) it also specifically supports 512-byte block transfers; no equivalent requirement exists for IDE devices. Also particularly ensure that the video controller is supported. Use of supported HP hardware will generally reduce the level of integration effort involved.

A CD-ROM, CD-R or DVD drive is required for OpenVMS Alpha installations, and a DVD-ROM or recordable or rewritable DVD DVD drive is required for OpenVMS I64 installations.

CD-ROM drive compatibility information is available at:


Previous Next Contents Index