Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z - Internet FAQ Archives

OpenVMS Frequently Asked Questions (FAQ), Part 9/11

( Part1 - Part2 - Part3 - Part4 - Part5 - Part6 - Part7 - Part8 - Part9 - Part10 - Part11 )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Forum ]

See reader questions & answers on this topic! - Help others by sharing your knowledge
Archive-name: dec-faq/vms/part9
Posting-Frequency: quarterly
Last-modified: 02 Sep 2005
Version: VMSFAQ_20050902-09.TXT


                   Hardware Information

          Table 14-2  Alpha Conversational Bootstrap Flags


                   0       CONV              Conversational bootstrap

                   1       DEBUG             Load SYSTEM_DEBUG.EXE

                   2       INIBPT            Stop at initial system
                                             breakpoints if bit 1 set

                   3       DIAG              Diagnostic bootstrap (loads

                   4       BOOBPT            Stop at bootstrap breakpoints
                                             (APB and Sysboot)

                   5       NOHEADER          Secondary bootstrap does not
                                             have an image header

                   6       NOTEST            Inhibit memory test

                   7       SOLICIT           Prompt for secondary
                                             bootstrap file

                   8       HALT              Halt before transfer to
                                             secondary bootstrap

                   9       SHADOW            Boot from shadow set

                   10      ISL               LAD/LAST bootstrap

                   11      PALCHECK          Disable PAL rev check halt

                   12      DEBUG_BOOT        Transfer to intermediate
                                             primary bootstrap

                   13      CRDFAIL           Mark CRD pages bad

                   14      ALIGN_FAULTS      Report unaligned data traps
                                             in bootstrap

                   15      REM_DEBUG         Allow remote high-level
                                             language debugger

                   16      DBG_INIT          Enable verbose boot messages
                                             in EXEC_INIT

                   17      USER_MSGS         Enable subset of verbose boot
                                             messages (user messages)

                   18      RSM               Boot is controlled by RSM


                   Hardware Information

          Table 14-2 (Cont.)  Alpha Conversational Bootstrap Flags



                   If you want to set the boot flags "permanently", use
                   the SET BOOT_FLAGS command, e.g.:

                   >>> SET BOOT_OSFLAGS 0,1

  What are the VAX VMB boot flag values?

                   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.

          Table 14-3  VAX Conversational Bootstrap Flags


                   0       CONV              Conversational boot. At
                                             various points in the system
                                             boot procedure, the bootstrap
                                             code solicits parameter
                                             and other input from the
                                             console terminal. If DIAG
                                             is set, then the diagnostic
                                             supervisor should enter its
                                             menu mode and prompt user for
                                             the devices to test.

                   1       DEBUG             Debug. If this flag is set,
                                             OpenVMS VAX maps the code
                                             for the XDELTA debugger into
                                             the system page tables of the
                                             running system.


                   Hardware Information

          Table 14-3 (Cont.)  VAX Conversational Bootstrap Flags


                   2       INIBPT            Initial breakpoint. If RPB$V_
                                             DEBUG is set, OpenVMS VAX
                                             executes a BPT instruction
                                             immediately after enabling

                   3       BBLOCK            Secondary boot from the boot
                                             block. Secondary bootstrap
                                             is a single 512-byte block,
                                             whose LBN is specified in R4.

                   4       DIAG              Diagnostic boot. Secondary
                                             bootstrap is the Diagnostic
                                             Supervisor image; the image

                   5       BOOBPT            Bootstrap breakpoint. Stops
                                             the primary and secondary
                                             bootstraps with an XDELTA
                                             breakpoint instruction prior
                                             to the memory test.

                   6       HEADER            Image header. Takes the
                                             transfer address of the
                                             secondary bootstrap image
                                             from that file's image
                                             header. If the RPB$V_HEADER
                                             bit is not set, the image is
                                             assumed to have no image
                                             header, and control is
                                             transfered to the first byte
                                             of the secondary boot file.

                   7       NOTEST            Memory test inhibit. Sets a
                                             bit in the PFN bit map for
                                             each page of memory present.
                                             Does not test the memory.

                   8       SOLICT            File name. VMB prompts for
                                             the name of a secondary
                                             bootstrap file.


                   Hardware Information

          Table 14-3 (Cont.)  VAX Conversational Bootstrap Flags


                   9       HALT              Halt before transfer.
                                             Executes a HALT instruction
                                             before transferring control
                                             to the secondary bootstrap.

                   10      NOPFND            No PFN deletion (not
                                             implemented; intended to
                                             tell VMB not to read a file
                                             from the boot device that
                                             identifies bad or reserved
                                             memory pages, so that VMB
                                             does not mark these pages as
                                             valid in the PFN bitmap).

                   11      MPM               Specifies that multi-
                                             port memory is to be used
                                             for the total EXEC memory
                                             requirement. No local memory
                                             is to be used. This is
                                             for tightly-coupled multi-
                                             processing. If the RPB$V_DIAG
                                             bit is also enabled, then the
                                             Diagnostic Supervisor enters
                                             its AUTOTEST mode.

                   12      USEMPM            Specifies that multi-port
                                             memory should be used in
                                             addition to local memory, as
                                             though both were one single
                                             pool of pages.

                   13      MEMTEST           Specifies that a more
                                             extensive algorithm be used
                                             when testing main memory for
                                             hardware uncorrectable (RDS)


                   Hardware Information

          Table 14-3 (Cont.)  VAX Conversational Bootstrap Flags


                   14      FINDMEM           Requests the use of MA780
                                             multiport memory if the main
                                             MS780 memory is insufficient
                                             for booting. This is a
                                             remnant of the support
                                             for the VAX-11/782 series
                                             system and its Asymmetric
                                             Multiprocessing (ASMP)
                                             environment. Support for
                                             the VAX-11/782 and for ASMP
                                             was withdrawn with the V5.0
                                             release; with the advent of
                                             Symmetric Multiprocessing

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

                     >>> BOOT/R5:flags

          14.3.6  How do I boot an AlphaStation without monitor or

                   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.


                   Hardware Information

                   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

          14.3.7  Downloading and using SRM console Firmware?

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

  Where can I get updated console firmware for Alpha

                   Firmware updates for HP Alpha systems are available





                   Hardware Information

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


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




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

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

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


                   Hardware Information

                   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

  How do I switch between AlphaBIOS/ARC and SRM

                   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

                   5  Press <F10>, <F10>, then <Enter> to save your

                   6  Power-cycle the system.


                   Hardware Information

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


                   Hardware Information

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


                   Hardware Information

                            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

          14.3.8  Console Management Options

                   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

                   o  Heroix:

                   o  KI Products:

                   o  Global Maintech:

                   o  TECsys:

                   o  CA:

                   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.


                   Hardware Information

          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

          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


                   Hardware Information

                   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

                   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

                   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.


                   Hardware Information

                   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

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


                      OpenVMS typically uses SPD 25.01.xx, SPD 41.87.xx,
                      and SPD 82.35.xx.


                   Hardware Information

                   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


                   Hardware Information

                   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


          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:

                   o  The PCMCIA support was completely removed, because
                      the Intel chip on the Multia was not compatable with
                      the Cirrus chip on the Alphabook.


                   Hardware Information

                      This means, of course, that you will not see and
                      cannot use any PCMCIA cards on a Multia.

                      The Multia uses shared interrupts, and as a result,
                      a special ZLXp-E series graphics device driver-one
                      that does not use interrupts-is needed. This driver
                      is provided in the kit.

                   o  The serial lines don't work.

                   o  If you have a Multia with a PCI slot, you can't use
                      any PCI card that requires interrupts.

                   o  The SRM console on this system is very old and
                      very fragile. (This SRM console was designed
                      only and strictly for diagnostic use, and was not
                      particularly tested or used with OpenVMS.)

                   o  If things don't work for you, don't expect to see
                      any OpenVMS updates, nor SRM console updates, nor
                      any support.

                   o  Do not expect to see any new versions of OpenVMS
                      on the Multia nor on any other unsupported systems.
                      If such new versions do appear and do work, please
                      consider it as a pleasant surprise.

                   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







                   Hardware Information

          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

  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:

                   o  You have to use the Multia kit and follow the
                      directions in ALPHA8, but do *not* load the Multia
                      SRM firmware into the AXPpci33. Rather, download and
                      use the latest firmware for the AXPpci33 from the HP
                      Alpha firmware website instead.

                   o  64 MB memory is generally necessary.

                   o  you cannot use any PCI cards, and if you plan on
                      networking, you need to find an ISA Ethernet card
                      supported by OpenVMS.

                   o  When the AXPpci33 board bootstraps, it will dump
                      some stuff like a crash dump, but it will continue
                      and-so far-this hasn't caused any particular

                   o  The system shutdown and reboot procedures do not
                      work properly.

                   o  The serial console is reported to not work, though
                      the serial ports apparently do work. The status of
                      the parallel port is unknown.


                   Hardware Information

                   o  Rumour has it that you have one of the AXPpci33
                      motherboards with the PS/2 mouse and keyboard
                      connectors and a VGA card (one that will work
                      under DECwindows) and you can run DECwindows on
                      the system.

          14.4.3  on the Alpha XL series?


                   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

                   The Alpha XL platform does not resemble other supported

          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:

                   o  The -a series was designed and was tested for
                      Windows NT use. Only. It is not supported for use
                      with OpenVMS.

                   o  The -au series was designed and tested for Windows,
                      OpenVMS, and Tru64 UNIX compatibility, and is
                      considered a supported system.


                   Hardware Information

                   o  There are at two different and distinct variants of
                      the family, and usually refered to by their internal
                      hardware project names.

                     o  The Miata MX5. The Miata MX5 variant has no USB
                        ports and no on-board SCSI. The on-board Intel
                        SIO chipset is not supported by OpenVMS, and thus
                        OpenVMS cannot bootstrap ATAPI CD-ROM devices.

                        That said, the Miata MX5 -a series typically came
                        with DEC branded Adaptec 2940UW SCSI controllers,
                        Matrox Millennium graphics cards, no L3 cache
                        module, and an Toshiba IDE CD-Rom. Some came with
                        very high end Powerstorm graphics card if the
                        system was destined to do CAD or movie rendering.

                        Graphics and other I/O can and does vary by

                        The Miata MX5 is not supported by OpenVMS.

                     o  The Miata GL. The Miata GL variant has USB ports
                        and on-board SCSI and bootstraps using the on-
                        board Cypress IDE chipset and an ATAPI CD-ROM
                        are supported by OpenVMS. The Miata GL -a variant
                        is need not be configured with an add-on SCSI
                        controller, given both the ability to bootstrap
                        from ATAPI CD-ROM and the on-board SCSI.

                        Graphics and other I/O can and does vary by

                        Various of the Miata GL systems are supported by

                   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 for related details.


                   Hardware Information

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

                   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.


                   Hardware Information

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


                   Hardware Information

                   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.

  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:

                   o  Intel

                   o  UEFI

                   Please see Section 14.4.5 for Intel Itanium


                   Hardware Information

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

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


                   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


                   Hardware Information

                   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

                   CD-ROM drive compatibility information is available at:


          14.6  Where can I get more information on Alpha systems?

                   HP operates an AlphaServer information center at:


                   Alpha Technical information and documentation is
                   available at:





                   o  Alpha Systems Update:

                   Software Product Description (SPD) information,
                   including platform support documentation:


                      OpenVMS typically uses SPD 25.01.xx, SPD 41.87.xx,
                      and SPD 82.35.xx.

                   Information on Multia hardware is available at:



                   Hardware Information

                   Information on DEC 3000 series hardware is available




                   The NetBSD folks maintain useful Alpha hardware
                   information at:


          14.7  Describe Alpha instruction emulation and instruction

                   The Alpha architecture is upward- and downward-
                   compatible, and newer instructions are emulated on
                   older platforms, for those cases where the compiler
                   is explicitly requested to generate the newer Alpha

                   In particular, OpenVMS Alpha V7.1 and later include the
                   instruction emulation capabilities necessary for the
                   execution of newer Alpha instructions on older Alpha
                   microprocessors. (Instruction emulation capabilities
                   are available for user-mode application code, and
                   are not available to device drivers or other similar
                   kernel-mode code.)

                   Alpha instructions are available in groups (or
                   subsets). Obviously, there is the base instruction set
                   that is available on all Alpha microprocessors. Then,
                   the following are the current instruction extension
                   groups (or subsets) that are available on some of
                   various recent Alpha microprocessors:

                   o  byte/word extension (BWX):
                      LDBU, LDWU, SEXTB, SEXTW, STB, and STW.


                   Hardware Information

                   o  floating-point and square root extension (FIX):
                      FTOIS, FTOIT, ITOFF, ITOFS, ITOFT, SQRTF, SQRTG,
                      SQRTS, and SQRTT.

                   o  count extension (CIX):
                      CTLZ, CTPOP, and CTTZ.

                   o  multi-media extension (MVI):
                      MAXSB8, MAXSW4, MAXUB8, MAXUW4, MINSB8, MINSW4,
                      MINUB8, MINUW4, PERR, PKLB, PKWB, UNPKBL, and

                   The typical instruction subset that provides the
                   biggest win-and of course, your mileage may vary-is
                   typically the instruction set that is provided by the
                   EV56 and later; specifically, the byte-word instruction
                   subset. To select this subset, use the following:


                   The /ARCHITECTURE controls the maximum instruction
                   subset that the compiler will generally use, while
                   the /OPTIMIZE=TUNE controls both the instruction-level
                   scheduling and also the instructions generated inside
                   loops-any code resulting from /OPTIMIZE=TUNE that is
                   specific to an instruction subset will be generated
                   only inside loops and will also be "protected" by
                   an AMASK-based test that permits the execution of
                   the proper code for the particular current Alpha

                   Typically /OPTIMIZE=TUNE=GENERIC is the appropriate
                   choice for tuning, and the /ARCHITECTURE selects the
                   minimum target architecture for general use throughout
                   the generated code.

                   generated for later architectures and instruction
                   subsets will run on older Alpha systems due to the
                   emulation, but if /ARCHITECTURE is a significant
                   benefit, then the emulation might be a performance

                   Please see the OpenVMS Ask The Wizard area for the
                   source code of a (non-privileged) tool that looks at
                   the instruction subsets available on the particular
                   Alpha microprocessor that the tool is run on. This tool


                   Hardware Information

                   demonstrates the use of the Alpha AMASK and IMPLVER

                   Please see Section 10.22 and Section 14.9 for
                   additional details and related considerations.

          14.8  So how do I open up the DEC 3000 chassis?

                   After removing those two little screws, tilt the back
                   end of the top shell upwards-then you can remove the

          14.9  What is byte swizzling?

                   "Swizzling" is the term used to describe the operation
                   needed to do partial longword (i.e. byte or word)
                   accesses to I/O space on those systems that don't
                   support it directly. It involved shifting the offset
                   into an address space by 5 (or 7 for one older system),
                   and ORing this into the base address. It then required
                   the size of the operation to be ORed into the low order

                   That is, because the EV4 and EV5 CPUs did not bring
                   bits 0 and 1 off the chip, to do programmed I/O for
                   bytes/words, the information on the size/offset of the
                   transfer was encoded into the address data. The data
                   itself then had to be shifted into the correct "byte
                   lane" ; into the required offset position within a
                   longword transfer;

                   The EV56 microprocessor supports byte/word instruction
                   references in memory space, however only specific EV56
                   systems can support byte/word accesses into I/O space;
                   device drivers may or may not be able to utilize to
                   byte/word instructions to access device registers.
                   Further, even on an EV56 system with hardware support
                   for byte/word accesses into I/O space, the relevant
                   OpenVMS routines typically do not support byte/word
                   access into I/O space.


                   Hardware Information

                   Systems based on the EV6 microprocessor (with the
                   salient exception of the AlphaServer GS60 and
                   AlphaServer GS140 series, for reasons of platform
                   compatability) support a flat, byte addressable I/O

                   If a device driver uses CRAM or IOC$WRITE_IO/IOC$READ_
                   IO, then OpenVMS will correctly process the swizzling
                   requirements without requiring changes the driver;
                   OpenVMS will transparently swizzle and unswizzle the
                   I/O space references, if needed for the particular
                   target platform. (Access and use of these routines may
                   or may not be feasible within the requirements for a
                   particular device driver, with the decision typically
                   based on the target performance requirements and the
                   expected frequency of device references and thus the
                   expected frequency of calls to these or other similar

                   To use byte/word operations on MEMORY, you need to
                   tell the compiler to use the EV56 or EV6 architecture
                   (/ARCHITECTURE=EV56). Memory operations did not
                   swizzle, but the compiler would do long/quad
                   access, and extract/insert bytes as needed. Using
                   /ARCHITECTURE=EV56 allows smaller, more efficient
                   byte/word access logic to memory.

                   If the application is directly referencing I/O space
                   access across a range of Alpha systems such as is done
                   with the X Windows device drivers, then the driver will
                   need to know how to do swizzling for old platforms,
                   and byte access for new platforms. Device drivers for
                   new graphics controllers can specifically target and
                   specifically require platforms based on EV6 and later
                   Alpha microprocessors because of this requirement, for

                   Please see Section 10.22 and Section 14.7 for
                   additional details and related considerations.


                   Hardware Information

          14.10  What is the layout of the VAX floating point format?

                   The VAX floating point format is derived from one
                   of the PDP-11 FP formats, which helps explain its
                   strange layout. There are four formats defined: F 32-
                   bit single-precision, D and G 64-bit double-precision
                   and H 128-bit quadruple precision. For all formats,
                   the lowest addressed 16-bit "word" contains the sign
                   and exponent (and for other than H, some of the most
                   significant fraction bits). Each successive higher-
                   addressed word contains the next 16 lesser-significant
                   fraction bits. Bit 15 of the first word is the sign, 1
                   for negative, 0 for positive. Zero is represented by
                   a biased exponent value of zero and a sign of zero;
                   the fraction bits are ignored (but on Alpha, non-
                   zero fraction bits in a zero value cause an error.)
                   A value with biased exponent zero and sign bit 1 is
                   a "reserved operand" - touching it causes an error -
                   fraction bits are ignored. There are no minus zero,
                   infinity, denormalized or NaN values.

                   For all formats, the fraction is normalized and the
                   radix point assumed to be to the left of the MSB, hence
                   the following range: 0.5 less than or equal to f and
                   less than 1.0. The MSB, always being 1, is not stored.
                   The binary exponent is stored with a bias varying with
                   type in bits 14:n of the lowest-addressed word.

            FP      Exponent    Exponent    Mantissa (Fraction) bits,
            Type      Bits        Bias        including hidden bit
             F         8           128              24
             D         8           128              56
             G        11          1024              53
             H        15         16384             113

                   The layout for D is identical to that for F except for
                   32 additional fraction bits.

                   Example: +1.5 in F float is hex 000040C0 (fraction of
                   .11[base 2], biased exponent of 129)


                   Hardware Information

          14.11  Where can I find more info about VAX systems?

                   o  HP provides limited VAX platform information via
                      links at the AlphaServer website, itself available

                   o  Jim Agnew maintains a MicroVAX/VAXstation FAQ at:

                   o  The VAXstation 3100 Owner's Guide:

                   o  VAX Console information:

                   o  A field guide to PDP-11 (and VAX) Q-bus and UNIBUS
                      modules can be found at:

                   o  Various VAX historical information (also see
                      Section 2.1) can be found at:

          14.12  Where can I find information on NetBSD for VAX systems?

                   Gunnar Helliesen maintains a NetBSD VAX FAQ at


          14.13  What system disk size limit on the MicroVAX and
                 VAXstation 3100?

                   System disks larger than 1.073 gigabytes (GB)-1fffff
                   hexidecimal blocks - are not supported on any member of
                   the VAXstation 3100 series and on certain older members
                   of the MicroVAX 3100 series, and are not reliable
                   on these affected systems. (See below to identify
                   the affected systems-the more recent members of the
                   MicroVAX 3100 series systems are NOT affected.)


                   Hardware Information

                   Various of the SCSI commands used by the boot drivers
                   imbedded in the console PROM on all members of the
                   VAXstation 3100 series use "Group 0" commands, which
                   allow a 21 bit block number field, which allows access
                   to the first 1fffff hexidecimal blocks of a disk. Any
                   disk references past 1fffff will wrap-this wrapping
                   behaviour can be of particular interest when writing a
                   system crashdump file, as this can potentially lead
                   to system disk corruptions should any part of the
                   crashdump file be located beyond 1.073 GB.

                   More recent systems and console PROMs use "Group 1"
                   SCSI commands, which allow a 32 bit block number field.

                   There was a similar limitation among the oldest of
                   the MicroVAX 3100 series, but a console boot PROM
                   was phased into production and was made available for
                   field retrofits-this PROM upgrade allows the use of the
                   "Group 1" SCSI commands, and thus larger system disks.
                   There was no similar PROM upgrade for the VAXstation
                   3100 series.

                   Systems that are affected by this limit:

                   o  VAXstation 3100 series, all members. No PROM upgrade
                      is available.

                   o  MicroVAX 3100 models 10 and 20. No PROM upgrade is

                   o  MicroVAX 3100 models 10e and 20e. Only systems with
                      console VMB versions prior to V6.4 are affected. A
                      PROM upgrade for these specific systems is (or was
                      once) available.

                   Also see


                   Also see Section 9.5.


                   Hardware Information

          14.14  What are the VAX processor (CPU) codes?

             CPU:    Platform:
             -----   ---------
             KA41-A : MicroVAX 3100 Model 10 and 20
             KA41-B : VAXserver 3100 Model 10 and 20
             KA41-C : InfoServer
             KA41-D : MicroVAX 3100 Model 10e and 20e
             KA41-E : VAXserver 3100 Model 10e and 20e
             KA42-A : VAXstation 3100 Model 30 and 40
             KA42-B : VAXstation 3100 Model 38 and 48
             KA43-A : VAXstation 3100 Model 76
             KA45   : MicroVAX 3100 Model 30 and 40
             KA46   : VAXstation 4000 Model 60
             KA47   : MicroVAX 3100 Model 80
             KA48   : VAXstation 4000 VLC
             KA49-A : VAXstation 4000 Model 90/90A
             KA49-B : VAXstation 4000 Model 95
             KA49-C : VAXstation 4000 Model 96
             KA50   : MicroVAX 3100 Model 90
             KA51   : MicroVAX 3100 Model 95
             KA52   : VAX 4000 Model 100
             KA53   : VAX 4000 Model 105
             KA54   : VAX 4000 Model 106
             KA55   : MicroVAX 3100 Model 85
             KA56   : MicroVAX 3100 Model 96
             KA57   : VAX 4000 Model 108
             KA58   : MicroVAX 3100 Model 88
             KA59   : MicroVAX 3100 Model 98
             KA85   : VAX 8500
             KA86   : VAX 8600
             KA88   : VAX 8800
             KA600  : VAX 4000-50 (aka VAXbrick)
             KA610  : MicroVAX I, VAXstation I (aka KD32)
             KA620  : rtVAX (VAXeln)
             KA62A  : VAX 6000-200
             KA62B  : VAX 6000-300
             KA630  : MicroVAX II, VAXstation II
             KA640  : MicroVAX 3300, MicroVAX 3400
             KA650  : VAXstation 3200, MicroVAX 3500, MicroVAX 3600, MicroVAX III
             KA64A  : VAX 6000-400
             KA655  : MicroVAX 3800, MicroVAX 3900, MicroVAX III+
             KA65A  : VAX 6000-500


                   Hardware Information

             KA660  : VAX 4000-200, VAX 4 upgrade
             KA66A  : VAX 6000-600
             KA670  : VAX 4000-300
             KA675  : VAX 4000-400
             KA680  : VAX 4000-500
             KA681  : VAX 4000-500A
             KA690  : VAX 4000-600
             KA691  : VAX 4000-605A
             KA692  : VAX 4000-700A
             KA693  : VAX 4000-605A
             KA694  : VAX 4000-705A
             KA730  : VAX-11/730
             KA750  : VAX-11/750
             KA780  : VAX-11/780, VAX-11/782
             KA785  : VAX-11/785
             KA7AA  : VAX 7000-600
             KA7AB  : VAX 7000-700
             KA7AC  : VAX 7000-800
             KA800  : VAXrta
             KA820  : VAX 8200, VAX 8300
             KA825  : VAX 8250, VAX 8350
             KA865  : VAX 8650

          14.15  Where can I get software and hardware support

                   Please contact the HP Customer Support Center. Services
                   and information, manuals, guides, downloads, and
                   various other information is available via the support
                   link at:


                   Various hardware and system documentation is available


                   TSM (Terminal Server Manager), DEChub, DECserver, etc.



                   Hardware Information

                   The owner and maintainer of current DECserver and
                   related hardware is DIGITAL Network Products Group


          14.16  Where can I get hardware self-maintenance support

                   The HP Parts Directory and the HP Parts Reference
                   Guide (arguably the most direct descendents of the
                   HP Assisted Services program, of the Compaq Assisted
                   Services program, and of the now-ancient DECmailer
                   program) are available to customers that wish to
                   maintain their own system(s) (self-maintenance),
                   but that wish some level of assistance in acquiring
                   specific parts, hardware diagnostics and hardware
                   manuals for the system(s), and that wish to have
                   access to spares and module-level repairs for customer-
                   performed hardware module swaps:



                   The HP Parts Reference Guide replaces the CAS-Catalog
                   and DAS-Catalog parts catalogs and related resources.

                   Details of the available self-maintenance programs and
                   services can vary by geography and by the particular
                   services channel(s), and current program specifics are
                   available via the above URLs.

          14.17  Why does my system halt when I power-cycle the console

                   Various VAX and Alpha consoles are designed to process
                   the BREAK signal, treating it as a HALT request.

                   A BREAK is a deliberately-generated serial line framing

                   When a serial line device such as a terminal
                   powers up (or sometimes when powering down) it can
                   generate framing errors. These framing errors are
                   indistingushable from a BREAK signal.


                   Hardware Information

                   When a BREAK is received on a serial line console
                   for various VAX systems-including most VAXstation,
                   MicroVAX, and VAX 4000 series-it is typically
                   interpreted as a HALT. Alpha systems will also often
                   process a BREAK in a similar fashion, halting the

                   There is no uniform or generally-available way to
                   disable this behaviour on every VAX or Alpha system. On
                   some systems, BREAK processing can be disabled in favor
                   of [CTRL/P], or [CTRL/P] is the only way to halt the

                   The most common way to avoid these halts is to disable
                   the serial line console or to simply not power-cycle
                   the console terminal. There is certain important
                   system state information that is displayed only on
                   the console, OpenVMS expects to always have access to
                   the system console.

                   Also see Section 5.6.

          14.18  Can I reuse old keyboards, mice and monitors with a PC?

                   Older HP keyboards (those with the DIGITAL logo and
                   the RJ modular jacks), older HP mice (those with the
                   DIGITAL logo and with the RJ modular jacks, or with
                   a DIN connector with pins in a configuration other
                   than the PC-standard DIN connector pin orientation),
                   and older video monitors (with RGB synch-on-green
                   video signaling) all use signaling formats and/or
                   communications protocols that differ from the PC
                   standards, and are not (easily) interchangable nor
                   (easily) compatible with typical PC peripheral device
                   controllers. The LK201 and LK401 keyboards, the VSXXX
                   series mice, the VR260 and VR290 monitors, etc., are
                   incompatible with most PC systems and with most KVM

                   Newer HP (and Compaq) keyboards (those with with PC-
                   style DIN plugs, and the HP, Compaq or DIGITAL logo),
                   newer HP mice (with PC-pin DIN plugs, and the HP,
                   Compaq or DIGITAL logo), and newer video monitors
                   (multi-synch) are often interchangeable with "industry
                   standard" PC systems, and can often be used with


                   Hardware Information

                   most PC peripheral device controllers. LK461, LK463,
                   LK46W, LK471, PC7XS-CA, VRC16, VRC21, TFT-series LCD
                   flat-panel displays, etc., are typically reasonably
                   compatible with most PC systems, and will usually
                   perform as expected within the limits of the hardware.
                   (For details of CRT and LCD display compatibility,
                   please see Section 14.19.)

                   Rule of thumb: if the peripheral device component
                   was sold for use with the DEC 2000 (DECpc 150 AXP),
                   an AlphaServer series, an AlphaStation series, or a
                   more recent Alpha system, it will probably work with a
                   PC peripheral controller or with a PC-compatible KVM
                   switch. If the peripheral device component was sold
                   for use with an VT420 or older terminal, most VAX, most
                   VAXstation, and most Alpha systems with names in the
                   format DEC [four-digit-number], it probably won't work
                   on a PC system or with a PC-compatible KVM.

                   Note that the above is a general guideline, and should
                   not be read to indicate that any particular peripheral
                   device will or will not work in any particular
                   configuration, save for those specific configurations
                   the device is explicitly supported in.

                   Software Integrators sells a video adapter card
                   called Gemini P1 which will drive many of the older
                   HP (DIGITAL-logo) fixed-frequency monitors on a PC


                   The DIGITAL (classic 2-5-2-style) part number 29-
                   32549-01 converts the output from the RGB cable (3 BNC,
                   synch-on-green) that comes with the VAXstation 3100 and
                   VAXstation 4000 series to a female SVGA D connector.
                   You may be able to find third-party converters or
                   adapters (3 BNCs with synch-on-green signaling to 5
                   BNCs with VGA/SVGA, or to 15-pin VGA/SVGA.

                   This adapter will allow PC multisync monitors with
                   the needed frequency specifications to be used with
                   the VAXstation series synch-on-green video connection.
                   It may well also work with a VAXstation 2000 series


                   Hardware Information

                   systems, but specifics and performance of that
                   combination are not immediately known at this writing.

                   The protocol definition for the old DIGITAL keyboard
                   and mouse interfaces is buried at the back of the QDSS
                   section in the old VAXstation II manual, specifically,
                   in the back of the VCB02 Video Subsystem Technical
                   Manual (EK-104AA-TM). The keyboard wiring and protocol
                   is in appendix B, and occupies circa 44 pages. The
                   mouse is in appendix C, circa 12 pages.

                   Also see Section 14.19.

          14.19  Which video monitor works with which graphics controller?

                   To determine the answer to the "will this video monitor
                   or this LCD panel work with this graphics controller?"
                   question, please first locate the resolution(s) and the
                   frequencies that are possible/supported at both ends
                   of the video cable (on the display and on the graphics
                   controller, in other words), and then determine if
                   there are any matching settings available. If there are
                   multiple matches, you will need to determine which one
                   is most appropriate for your needs.

                   You will also need to determine if the video monitor
                   or graphics controller requires the 3 BNC signaling
                   with the synchronization signals on the green wire,
                   or the 5 BNC signaling common on many PCs, or other
                   connections such as the DB15 video connector or USB
                   connector used on various systems. (BNC signaling
                   is comparatively old, but prevalent with many older
                   hobbyist AlphaStation or VAXstation configurations.)

                   If there are no matches, you will likely need to change
                   the hardware at one or both ends of the video cable.

                   The refresh frequencies for many devices have been
                   posted to comp.os.vms and/or other newsgroups. Search
                   the archives for details. Also see:





                   Hardware Information



                   LCD-based and plasma-based flat-panel displays are
                   generally compatible with all recent OpenVMS Alpha
                   systems and supported graphics controllers. For
                   best results, you should generally set the graphics
                   controller to match the native LCD or plasma display
                   resolution and (for LCD displays) also set the
                   controller refresh rate to 60Hz. Check your graphics
                   controller and your display documentation for any
                   device-specific requirements and/or configuration

                   Some of the older graphics controllers around do not
                   necessarily generate stable signals at 60 Hz, if the
                   controller can even generate that refresh rate; you may
                   end up upgrading to a less-old controller. (At least
                   some of the PowerStorm 3D30 and PowerStorm 4D20 series
                   controllers, for instance, are not necessarily the
                   best choice for 60 Hz operations with an LCD, based
                   on empirical testing with an AlphaStation XP1000,
                   PowerStorm 3D30, and a TFT2025 series LCD. Degraded
                   or mismatched signals produce degraded displays,
                   obviously. The newest graphics controllers compatible
                   with your particular system are generally better
                   choices here for use with LCD; the Radeon 7500 series
                   is a good choice for most EV6-class AlphaStation
                   systems, for instance.

                   Also see Section 14.18.

          14.20  Where can I get information on storage hardware?

                   Information on various HP (Compaq, DIGITAL) OpenVMS
                   and other disk storage hardware and controllers, and
                   related technical information on SCSI, device jumpers,
                   etc., is available at:



                      the aquascape website appears to have become
                      unavailable, and the FAQ maintainer is unaware


 ---------------------------- #include <rtfaq.h> -----------------------------
    For additional, please see the OpenVMS FAQ --
 --------------------------- pure personal opinion ---------------------------
        Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

Part1 - Part2 - Part3 - Part4 - Part5 - Part6 - Part7 - Part8 - Part9 - Part10 - Part11

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:

Last Update March 27 2014 @ 02:11 PM