HP OpenVMS Systems Documentation

The OpenVMS Frequently Asked Questions (FAQ)

The flags described in Table 14-3 are passed (via register R5) to the OpenVMS VAX primary bootstrap image VMB.EXE. These flags control the particular behaviour of the bootstrap.

The exact syntax is console-specific, recent VAX consoles tend to use the following:

  >>> BOOT/R5:flags

The AlphaStation series will boot without a keyboard attached. To use a serial terminal as the console, issue the SRM console command SET CONSOLE SERIAL followed by the console INIT command. Once this SRM command sequence has been invoked and the CONSOLE environment variable is set to SERIAL, the Alpha system will use the serial terminal. (Set the environment variable to GRAPHICS to select the console display output via the graphics display.)

The DEC 3000 series has a jumper on the motherboard for this purpose. Various older Alpha workstations generally will not (automatically) bootstrap without a keyboard connected, due to the self-test failure that arises when the (missing) keyboard test fails.

The usual settings for the console serial terminal (or PC terminal emulator acting as a serial console are:

9600 baud, 8 bits, no parity, one stop bit (9600 baud, 8N1).

AlphaServer 4100 and derivative series platforms, and AlphaServer GS80, GS160, and GS320 series system consoles are capable of 57600 baud. See the COM2_BAUD console environment variable, and ensure that you have current SRM firmware version loaded.

The AlphaStation and AlphaServer series use a PC-compatible DB9 serial connector for the COM1 and COM2 serial lines (and for the OPA0: console line, if that was configured via SRM), please see Section 14.26 for details and pin-out.

For information on registering software license product authorization keys (PAKs), please see Section 5.6.2.

For a related behaviour of DECwindows, please see Section 11.10. For information on the VAXstation alternate console mechanisms, please see Section 14.3.3.3.

14.3.7 Downloading and using SRM console Firmware?

This section discusses downloading and using Alpha console firmware, sometimes called PALcode.

14.3.7.1 Where can I get updated console firmware for Alpha systems?

Firmware updates for HP Alpha systems are available from:

• ftp://ftp.digital.com/pub/Digital/Alpha/firmware/index.html
• ftp://ftp.digital.com/pub/Digital/Alpha/firmware/
• ftp://ftp.digital.com/pub/Digital/Alpha/firmware/readme.html

The latest and greatest firmware---if updated firmware has been released after the most recent firmware CD was distributed---is located at:

• ftp://ftp.digital.com/pub/Digital/Alpha/firmware/interim/

For information on creating Alpha bootable floppies containing the firmware, and for related tools, please see the following areas:

• ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkboot.txt
• ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkbootarc.txt
• ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkntboot.txt

The SROM firmware loader expects an ODS-2 formatted floppy, see mkboot. As for which image to use, the ROM image uses a header and the file extension .ROM, and the SROM bootable floppy cannot use the .ROM file.

To check the firmware loaded on recent OpenVMS Alpha systems, use the command:

$ write sys$output f$getsyi("console_version")
$ write sys$output f$getsyi("palcode_version")
SDA> CLUE CONFIG

Also see Section 14.3.7.2. For information on HP Integrity EFI firmware upgrades and for a sequence useful in generating CD-R or CD-RW media containing a firmware disk image, please see Section 14.3.11.

14.3.7.2 How do I reload SRM firmware on a half-flash Alpha system?

Some of the AlphaStation series systems are "half-flash" boxes, meaning only one set of firmware (SRM or AlphaBIOS) can be loaded in flash at a time. Getting back to the SRM firmware when AlphaBIOS (or ARC) is loaded can be a little interesting...

That said, this usually involves shuffling some files, and then getting into the AlphaBIOS firmware update sequence, and then entering "update srm" at the apu-> prompt.

To shuffle the files, copy the target SRM firmware file (as200_v7_0.exe is current) to a blank, initialized, FAT-format floppy under the filename A:\FWUPDATE.EXE

From the AlphaBIOS Setup screen, select the Upgrade AlphaBIOS option. Once the firmware update utility gets going, enter:

     Apu-> update srm

           Answer "y" to the "Are you ready...?"

     Apu-> quit

You've reloaded the flash. Now power-cycle the box to finish the process.

Also see Section 14.3.7.1.

14.3.7.3 How do I switch between AlphaBIOS/ARC and SRM consoles?

The specific steps required vary by system. You must first ensure that the particular Alpha system is supported by OpenVMS (see the SPD), that all core I/O components (graphics, disk controllers, etc) in the system are supported by OpenVMS (see the SPD), and that you have an OpenVMS distribution, that you have the necessary license keys (PAKs), and that you have the necessary SRM firmware loaded.

A typical sequence used for switching over from the AlphaBIOS graphics console to the SRM console follows:

1. Press [F2] to get to the AlphaBIOS setup menu.
2. Pick the "CMOS Setup..." item.
3. Press [F6] to get to the "Advanced CMOS Setup" menu.
4. Change the "Console Selection" to "OpenVMS Console (SRM)".
5. Press [F10], [F10], then [Enter] to save your changes.
6. Power-cycle the system.

Most Alpha systems support loading both the AlphaBIOS/ARC console and the SRM console at the same time, but systems such as the AlphaStation 255 are "half-flash" systems and do not support the presence of both the AlphaBIOS/ARC and SRM console firmware at the same time. If you have a "half-flash" system, you must load the SRM firmware from floppy, from a network download, or from a firmware CD-ROM. Following the normal AlphaBIOS or ARC firmware update sequence to the APU prompt, and then explictly select the target console. In other words, power up the system to the AlphaBIOS or ARC console, use the supplementary options to select the installation of new firmware (typically from CD-ROM), and then rather than using a sequence which updates the current firmware:

    Apu-> update
      -or-
    Apu-> update ARC
    Apu-> verify
    Apu-> quit
    Power-cycle the system

Use the following sequence to specifically update (and load) SRM from AlphaBIOS/ARC on a "half-flash" system:

    Apu-> update SRM
    Apu-> verify
    Apu-> quit
    Power-cycle the system

Use the following sequence to specifically update (and load) the AlphaBIOS/ARC console from SRM on a "half-flash" system:

    >>> b -fl 0,A0 ddcu
    BOOTFILE: firmware_boot_file.exe

    Apu-> update ARC
    Apu-> verify
    Apu-> quit
    Power-cycle the system

Once you have the SRM loaded, you can directly install OpenVMS or Tru64 UNIX on the system. Do not allow Microsoft Windows NT or other operating system(s) to write a "harmless" signature to any disk used by OpenVMS Alpha or OpenVMS VAX, as this will clobber a key part of the disk; this will overwrite the OpenVMS bootblock. (On OpenVMS Alpha and OpenVMS VAX, you can generally recover from this so-called "harmless" action by using the WRITEBOOT.EXE tool.

Using OpenVMS I64 and the EFI console, the bootblock structures are expected to be compatible with those of Microsoft Windows and other Integrity operating systems; please see the discussion of the SET BOOTBLOCK command and the SYS$SETBOOT.EXE image in Section 9.7.3, in Section 14.3.9, and in the OpenVMS documentation for related details.)

If you have a "full-flash" system and want to select the SRM console from the AlphaBIOS or ARC console environment, select the "Switch to OpenVMS or Tru64 UNIX console" item from the "set up the system" submenu. Then power-cycle the system. If you have a "full-flash" system with the SRM console and want to select AlphaBIOS/ARC, use the command:

   >>> set os_type NT

and power-cycle the system.

For information on acquiring firmware, see Section 14.3.7.1. For information on OpenVMS license PAKs (for hobbyist use) see Section 2.8.1. For information on the Multia, see Section 14.4.1.

Information on enabling and using the failsafe firmware loader for various systems---this tool is available only on some of the various Alpha platforms---is available in the hardware documentation for the system. This tool is used/needed when the firmware has been corrupted, and cannot load new firmware.

The full list of AlphaBIOS key sequences---these sequences are needed when using an LK-series keyboard with AlphaBIOS, as AlphaBIOS expects a PC-style keyboard:

         F1   Ctrl/A
         F2   Ctrl/B
         F3   Ctrl/C
         F4   Ctrl/D
         F5   Ctrl/E
         F6   Ctrl/F
         F7   Ctrl/P
         F8   Ctrl/R
         F9   Ctrl/T
        F10   Ctrl/U
     Insert   Ctrl/V
     Delete   Ctrl/W
  Backspace   Ctrl/H
     Escape   Ctrl/[
     Return   Ctrl/M
   LineFeed   Ctrl/J
   (Plus) +   upselect (some systems)
  (Minus) -   downselect (some systems)
        TAB   down arrow
   SHIFT+TAB  up arrow

Options to collect multiple consoles into a single server are available, with both hardware options and software packages that can provide advanced features and capabilities.

Some of the available console management options for OpenVMS:

• Heroix: http://www.robomon.com/
• KI Products: http://www.ki.com/products/clim/
• Global Maintech: http://www.globalmt.com/
• TECsys: http://www.tditx.com/
• CA: http://www.cai.com/products/commandit.htm

Computer Associates is the owner of what was once known as the VAXcluster Console System (VCS) console management package, and has integrated this capability into the CA management product suite.

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:

• http://www.hp.com/go/integrity/

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

• http://h18000.www1.hp.com/info/spd/
  OpenVMS typically uses SPD 25.01.xx, SPD 41.87.xx, and SPD 82.35.xx.

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.