The OpenVMS Frequently Asked Questions(FAQ)


Previous Contents Index

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

14.12 Where can I find more info about VAX systems?

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

Gunnar Helliesen maintains a NetBSD VAX FAQ at http://vaxine.bitcon.no/.

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

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:

Also see http://www.whiteice.com/~williamwebb/intro/DOC-i.html

Also see Section 9.5.

14.15 What is the Accuracy of VAX the Time of Year (TOY) Clock?

The VAX Time-Of-Year (TOY) clock (used to save the time over a reboot or power failure) is specified as having an accuracy of 0.0025%. This is a drift of roughly 65 seconds per month.

The VAX Interval Time is used to keep the running time, and this has a specified accuracy of .01%. This is a drift of approximately 8.64 seconds per day.

Any high-IPL activity can interfere with the IPL 22 or IPL 24 (this depends on the VAX implementation) clock interrupts---activities such as extensive device driver interrupts or memory errors are known to slow the clock.

Also see Section 14.8, Section 4.3.

14.16 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 
   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.17 Where can I get software and hardware support information?

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

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

The owner and maintainer of current DECserver and related hardware is DIGITAL Network Products Group (DNPG):

14.18 Where can I get hardware self-maintenance support assistance?

The HP Assisted Services (CAS) program (a direct descendent of the program once known as DECmailer) is available to customers that wish to maintain their own system(s) (self-maintenance), but that wish some level of assistance in acquiring 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:

14.19 Why does my system halt when I power-cycle the console terminal?

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

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.

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

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

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

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

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

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

The DIGITAL part number 29-32540-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.

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

14.21 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 signalling common on many PCs, or other connections such as the DB15 video connector or USB connector used on various systems.

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:

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

Also see Section 14.20.

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

Note: the above website appears to have become unavailable, and the FAQ maintainer is unaware of a new server. You may or may not have some success looking for this or other now-unavailable sites using the world-wide web archives at:

14.23 Why does my LK401 keyboard unexpectedly autorepeat?

There are several modes of failure:

14.24 Problem - My LK411 sends the wrong keycodes or some keys are dead

Check the firmware revision on the keyboard. Hardware revision B01 introduced an incompatability with the device driver which causes the keyboard to not be recognized correctly. There is a patch available to fix this problem: [AXPDRIV06_061] - the fix is also included in OpenVMS V6.2. The rev A01 keyboard, and the LK450 should work without problems.

If you are working from another operating system platform, please see the DECxterm tool and related information on OpenVMS Freeware V5.0.

14.25 Which DE500 variant works with which OpenVMS version?

Ensure you have a version of the Alpha SRM console with support for the DE500 series device. Apply ALL mandatory ECO kits for the OpenVMS version in use, and also apply the CLUSIO, ALPBOOT, and ALPLAN kits, and apply any available ALPCPU ECO kit for the platform.

To check the DE500 device hardware id from OpenVMS, use the following command:


$ ANALYZE/SYSTEM 
SDA> SHOW LAN/DEVICE=EWcu: 

The "hardware id" will be displayed.

To set the DE500 speed via the Alpha SRM console environment variable:


   EWx0_MODE setting           Meaning 
   --------------------------  -------------------------------- 
   Twisted-Pair                10 Mbit/sec, nofull_duplex 
   Full Duplex, Twisted-Pair   10 Mbit/sec, full_duplex 
   AUI                         10 Mbit/sec, nofull_duplex 
   BNC                         10 Mbit/sec, nofull_duplex 
   Fast                        100 Mbit/sec, nofull_duplex 
   FastFD (Full Duplex)        100 Mbit/sec, full_duplex 
   Auto-Negotiate              Negotiation with remote device 

To override the console setting and use LANCP:


$ RUN SYS$SYSTEM:LANCP 
LANCP> SET DEV EWA0/SPEED=10 
LANCP> SET DEV EWA0/SPEED=100/full_duplex 

Fast Ethernet (100Base, 100 megabit) controllers such as the DE500 series have a pair of connections available---while traditional Ethernet (10Base, 10 megabit) is inherently a half-duplex protocol, Fast Ethernet can be configured to use one or both of the available connections, depending on the controller. Fast Ethernet can thus be half- or full-duplex depending on the configuration and the capabilities of the network controller and the Ethernet network plant. Some Fast Ethernet controllers can also operate at traditional Ethernet speeds, these controllers are thus often refered to as 10/100 Ethernet controllers.

14.26 Third-party disk/tape/controllers/SCSI/widgets on OpenVMS?

A wide variety of third-party widgets---SCSI and ATA (IDE) disks and tapes, graphics controllers, etc---are obviously widely available and are used on various platforms.

If you purchase third-party "generic" SCSI or ATA (IDE) storage devices, you and your device vendor will be responsible for the testing and the support of the devices. In general, you can expect that Compaq will address non-standards-compliance problems within OpenVMS (changes that will also not prevent operations with other supported devices, of course), but you and/or the device vendor and/or the device manufacturer are responsible for finding and fixing problems in the particular third-party device and or controller involved.

In particular, realize that neither SCSI nor ATA (IDE) is a particularly standard interface, these interfaces tend to be a collection of optionally-implemented and standardized interface features. You should not and can not simply assume that all SCSI nor ATA (IDE) storage devices are interchangeable. If you want to try to use a generic SCSI device, use V6.2 or later, or (better) V7.1-2 or later. If you wish to try to use ATA (IDE), use OpenVMS V7.1-2 or later.

On older OpenVMS releases, see the disk capacity limits ( Section 9.5).

With SCSI disks on releases prior to V6.2, ensure that you have the ARRE and ARWE settings configured correctly (disabled). (If not, you will see DRVERR fatal drive errors and error log entries.)

Some SCSI disks set the medium type byte as part of the SCSI size field---this is a SET CAPACITY extension to SCSI specs. This problem also applies to VAX V7.1 and later.

Disks with SCSI disk sizes past 8.58 GB and/or with the SET CAPACITY extension require ALPSCSI07 ECO or the OpenVMS Alpha V7.1-2 or later release. (See Section 9.5 for further details.)

Based on the displays of the (undocumented) SYS$ETC:SCSI_INFO tool; this tool is present in OpenVMS V6.2 and later:


    Issuing 6-byte MODE SENSE QIOW to get current values for page 01h 
           Page Code ................. 01h 
           Page Name ................. Read-Write Error Recovery 
           Saveable .................. Yes 
           Size ...................... 10 
           Hex Data .................. E6 08 50 00 00 00 08 00 
                                       00 00 

The E6 indicates that the AWRE and ARRE bits are set, and this is not acceptable on OpenVMS versions prior to V6.2. Further along in the SCSI_INFO display, if you also see:


    Issuing 6-byte MODE SENSE QIOW to get changeable values for page 81h 
           Page Code ................. 01h 
           Page Name ................. Read-Write Error Recovery 
           Saveable .................. Yes 
           Size ...................... 10 
           Hex Data .................. C0 08 50 00 00 00 08 00 
                                       00 00 

The C0 value means that the AWRE and ARRE values can be changed on this particular SCSI device. (This is not always the case.) Use RZDISK from the OpenVMS Freeware, and reset the E6 flag byte to hexadecimal 26 (or whatever the remaining mask when you remove bits C0) on page one.

Each SCSI and ATA (IDE) host contains non-trivial SCSI and IDE driver software, and each device contains equally non-trivial firmware--- taken together with the mechanical and electronic components, this software and firmware will determine whether or not a particular device will function as expected.

Also note that various devices---such as various SCSI CD-R devices ---can implement and can require vendor-specific protocol extensions, and these extensions can require modifications to OpenVMS or the addition of various utilities. In various of these cases, these devices perform functions that will require them to use SCSI or ATA (IDE) commands that are (hopefully) architecturally-compatible SCSI or ATA (IDE) command extensions. (Also see Section 7.1 and Section 9.7.)

In order for OpenVMS to officially support a particular device, integration and testing work is mandated. There can be no certainty that any particular device will operate as expected in any particular configuration without first performing this (non-trivial) work.

It is quite possible to find two devices---both entirely compliant with applicable standards or interface documents---that will not interoperate.

The same general statement holds for OpenVMS bootstrapping on an unsupported VAX or Alpha platform. It might or might not work. In particular, please see the OpenVMS Software Product Description (SPD) for the list of platforms supported by OpenVMS. OpenVMS is not supported on the Personal Workstation -a series, on the Digital Server series platforms, on the AlphaServer 2100 series 5/375 CPU, on the Multia, on the AlphaServer DS20L, and on a variety of other platforms. (You might or might not see success booting OpenVMS on any of these platforms.)


Previous Next Contents Index