| Previous | Contents | Index |
Options to collect multiple consoles into a single server are available, with both hardware options and software packages that can provide advanced features and capabilities.
Some of the available console management options for OpenVMS:
Computer Associates is the owner of what was once known as the
VAXcluster Console System (VCS) console management package, and has
integrated this capability into the CA management product suite.
14.4 What platforms will OpenVMS operate on?
For the list of boxes that are officially and formally supported by OpenVMS Engineering, please see the OpenVMS Software Product Description (SPD).
Sometimes a particular and officially unsupported Alpha box or Alpha motherboard will sufficiently resemble a supported box that the platform can effectively mimic and can bootstrap OpenVMS. Alternatively, somebody (usually one or more engineers within the OpenVMS Engineering group) will have put together a bootstrap kit -- such as the kit for the Alpha Multia---which permits OpenVMS to bootstrap on the platform.
Contrary to the assumptions of some folks, there are platform-level differences within the VAX and within Alpha platforms---hardware-level differences that can require moderate to extensive new coding within OpenVMS. Within a platform series, and particularly within Alpha platforms that support Dynamic System Recognition (DSR), OpenVMS can usually bootstrap.
DSR is a mechanism by which OpenVMS Alpha can gather platform-specific information, and DSR is the reason why newer Alpha systems can be more easily and more commonly supported on older OpenVMS Alpha releases. DSR is implemented with OpenVMS Alpha code, with SRM console code, and with platform non-volatile memory.
OpenVMS users with experience on older OpenVMS VAX releases and VAX hardware will recall that then-new VAX systems either required an OpenVMS VAX upgrade, or that earlier releases would mis-identified then-newer VAX systems---such as the case of the VAX 7000 model 800 being (mis)identified as a VAX 7000 model 600 when bootstrapped on OpenVMS VAX V5.5-2. (This (mis)identification was the outcome of a deliberate engineering effort to permit the VAX 7000 model 800 to bootstrap on V5.5-2; the system manager could configure the VAX 7000 model 800 to (mis)identify itself as a model 600, to permit the system to bootstrap on V5.5-2.) OpenVMS VAX and VAX platforms lack DSR support.
OpenVMS I64 (please see Section 14.4.5 for Intel Itanium terminology) supports a platform-level feature similar to the OpenVMS Alpha DSR mechanism, based on the ACPI interface and the byte-code interpreter implemented within OpenVMS, within the EFI console, and particularly within non-volatile memory located on (byte-code interpreter compliant) PCI I/O hardware. ACPI tables provide the information that was formerly retrieved from DSR and from the SRM, and the byte-code interpreter can (theoretically) permit at least limited operations with (compliant) PCI hardware, whether or not OpenVMS has a driver for the particular hardware.
The byte code interpreter may or may not permit operations with any
particular PCI hardware, and may or may not have sufficient performance
for local requirements, and PCI hardware may or may not include the
necessary ROM-based drivers in the PCI hardware non-volatile storage.
(The intent of this Intel platform-level effort is to move the host
software drivers out onto the specific PCI hardware, and to permit the
same byte code to operate regardless of the particular host platform.)
At least the initial releases of OpenVMS I64 will not have
support for the byte code interpreter nor for arbitrary PCI or system
hardware, but will have support for ACPI-based system identification
and system configuration.
14.4.1 on the Alpha Multia?
Yes, there are a set of unsupported images that permit specific OpenVMS Alpha versions to bootstrap on the Multia UDB system. These images and the associated instructions are available at the OpenVMS Freeware website:
Instructions are included IN the kits. READ THE INSTRUCTIONS. PLEASE!
Some of the restrictions involved when running OpenVMS on the Multia system include (but may well not be limited to) the following:
The Multia images are not included on the OpenVMS Freeware V4.0 CD-ROM kit, the kit that was distributed with OpenVMS V7.2. (These images became available after Freeware V4.0 shipped.)
Other sources of information for OpenVMS on Multia include:
OpenVMS Alpha is not supported on the AlphaPC 164LX and 164SX series, though there are folks that have gotten certain of the LX series to load SRM and bootstrap OpenVMS. (The Aspen Durango II variant, specifically.)
One problem has been generally reported: ATA (IDE) bootstraps will fail; SCSI storage and a SCSI CD-ROM device is required.
Also see Section 14.4.2.1.
14.4.2.1 on the NoName AXPpci33 system?
Information on bootstrapping OpenVMS (using the Multia files described in Section 14.4.1) on the (unsupported) NoName AXPpci33 module is available at:
No.
OpenVMS Engineering does not formally support the Alpha XL series, nor will OpenVMS (informally) bootstrap on the Alpha XL series.
OpenVMS can not, will not, and does not bootstrap on the Alpha XL series. The Alpha XL series was targeted for use (only) with the Microsoft Windows NT operating system.
The Alpha XL platform does not resemble other supported platforms.
14.4.4 OpenVMS on the Personal Workstation -a and -au series?
Though OpenVMS is not supported on the Personal Workstation -a series platforms, OpenVMS might or might not bootstrap on the platform.
If you wish to attempt this, you must ensure that all graphics and all
I/O controllers in the system are supported by OpenVMS. You must also
ensure that you have the most current firmware loaded.
14.4.4.1 OpenVMS on the Whitebox Windows-Only series Alpha?
Though OpenVMS is not supported on the "Whitebox" series of Alpha platforms, OpenVMS might or might not bootstrap on the platform. These systems were specifically configured, targeted and supported only for use with the Microsoft Windows NT operating system.
On some of the "Whitebox" systems, the following sequence of console commands can potentially be used to convert the system over to unsupported use by and for OpenVMS Hobbyist users. (But please note that if you wish to attempt this, you must ensure that all graphics and all I/O controllers in the system are supported by OpenVMS, and you must ensure that you have the most current SRM firmware loaded. (For information on locating and downloading the most current Alpha SRM firmware, please see Section 14.3.7.1.) And you must realize that the resulting Whitebox configuration will be entirely unsupported and may or may not be stable and useful.)
set os_type vms cat nvram ! too see what is in this, if anything edit nvram 10 set srm_boot on 20 e init |
If your nvram has other contents, you will need to change the line numbers (10 and 20) to reflect the contents of your configuration. To obtain documentation on the commands of the console editor, enter the ? command within the editor.
The above sequence was reportedly tested on the DIGITAL Server 3300 series, a relative of the AlphaServer 800 series. The DIGITAL Server 3300 is not supported by OpenVMS, though the AlphaServer 800 series is a supported platform. The sequence may or may not work on other platforms, and may or may not work on the DIGITAL Server 3300 platform.
Also see Section 5.32.
14.4.4.2 OpenVMS and Personal Workstation ATA (IDE) bootstrap?
OpenVMS will boot and is supported on the 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.
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.
14.4.5 On the Intel Itanium IA-64 platform?
OpenVMS is being ported to the Intel IA-64 architecture; to HP systems based on the Intel Itanium Processor Family.
The first release of OpenVMS I64 is V8.0, with the first general release of OpenVMS I64 expected to be V8.2.
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 and
HP architecture implementing the VLIW (Very Long Instruction Word)
design known as EPIC (Explicitly Parallel Instruction Computing). I64
is the name of a family of HP computer systems using Intel Itanium
processors.
14.4.5.1 Where can I get Intel Itanium information?
Intel Itanium Processor Family and IA-64 Architecture, Hardware, Software, and related docoumentation materials are available at:
The Intel Extensible Firmware Interface (EFI) console documentation: http://www.pentium.de/technology/efi/index.htm
Please see Section 14.4.5 for Intel Itanium terminology.
14.5 What is the least expensive system that will run OpenVMS?
The cheapest systems that are or have been recently offered by HP that will run OpenVMS Alpha are the AlphaServer DS10 server, the AlphaStation XP900 workstation, the AlphaStation VS10 workstation, and the AlphaStation XP1000 workstation. Other companies sell Alpha-powered systems and Alpha motherboards, some of which will run (and can be purchased with) OpenVMS---see the OpenVMS Software Product Description (SPD) for details on the supported systems and configurations. There are also many used AlphaStation, AlphaServer, and DEC 3000 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.
Depending on the OpenVMS version and configuration, the OpenVMS Software Product Description (SPD) is available at:
When purchasing a system, ensure that the system itself is supported, that the system disk drive is supported or closely compatible, that the CD-ROM drive is supported or is closely compatable and that (in the case of SCSI devices) it also specifically supports 512 byte block transfers; no equivalent requirement exists for IDE devices. Also particularly ensure that the video controller is supported. Use of supported HP hardware will generally reduce the level of integration effort involved.
A CD-ROM, CD-R or DVD drive is required for OpenVMS Alpha installations.
CD-ROM drive compatibility information is available at:
HP operates an AlphaServer information center at:
Software Product Description (SPD) information, including platform support documentation:
Information on Multia hardware is available at:
Information on DEC 3000 series hardware is available at:
Information on current and future Alpha microprocessor designs is also available from AlphaPowered at:
The NetBSD folks maintain useful Alpha hardware information at:
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 instructions.
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:
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:
/ARCHITECTURE=EV56/OPTIMIZE=TUNE=GENERIC |
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 microprocessor.
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 penalty.
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 demonstrates the use of the Alpha AMASK and IMPLVER instructions.
Please see Section 10.22 and Section 14.10 for additional details and
related considerations.
14.8 What is the Accuracy of the Alpha Time of Year (BB_WATCH) Clock?
The specification for maximum clock drift in the Alpha hardware clock is 50 parts per million (ppm), that is less than ±0.000050 seconds of drift per second, less than ±0.000050 days of drift per day, or less than ±0.000050 years of drift per year, etc. (eg: An error of one second over a day-long interval is roughly 11ppm, or 1000000/(24*60*60).) Put another way, this is .005%, which is around 130 seconds per month or 26 minutes per year.
The software-maintained system time can drift more than this, primarily due to other system activity. Typical causes of drift include extensive high-IPL code (soft memory errors, heavy activity at device IPLs, etc) that are causing the processing of the clock interrupts to be blocked.
Also see Section 14.15, Section 4.3.
14.9 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 lid.
14.10 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 bits.
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" (i.e. its actual position within a longword).
The EV56 CPU supports the byte/word instructions however only some EV56 systems support byte/word accesses to I/O space. Even on an EV56 system that supports byte/word accesses to I/O space, the relevant OpenVMS routines do not support byte/word access to I/O space.
EV6 systems (with the exception of the AlphaServer GS60 and AlphaServer GS140 series, for reasons of platform compatability) support a flat, byte addressable I/O space.
If a device driver uses CRAM or IOC$WRITE_IO/IOC$READ_IO, then OpenVMS will do the right thing without changing the driver - OpenVMS will swizzle and unswizzle as needed.
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 doing I/O space access across a range of Alpha systems (like the graphics servers), then the driver will need to know how to do swizzling for old platforms, and byte access for new platforms.
Please see Section 10.22 and Section 14.7 for additional details and related considerations.
| Previous | Next | Contents | Index |