In terms of software, very few. As of OpenVMS V6.1, the VAX and Alpha platforms are very close to "feature parity". OpenVMS on IA-64 is expected to have "feature parity" with OpenVMS Alpha, and is based on the same source pool. Most applications can just be recompiled and run. Some differences to be aware of:

• The default double-precision floating type on OpenVMS Alpha is VAX G_float, whereas on VAX it is usually D_float. D_float is available on Alpha, but D_float values are converted to G_float for computations and then converted back to D_float when stored. Because the G_float type has three fewer fraction bits than D_float, some applications may get different results. IEEE float types are also available on OpenVMS Alpha.
• The preferred floating point format on Alpha and IA-64 is IEEE.
• Data alignment is extremely important for best performance on Alpha. This means that data items should be allocated at addresses which are exact multiples of their sizes. Quadword alignment will offer the best performance, especially for character values and those smaller than 32 bits. Compilers will naturally align variables where they can and will issue warnings if they detect unaligned data items.
• HP C is the only C compiler HP offers on OpenVMS Alpha, and is a direct descendant of Compaq C and DEC C on OpenVMS Alpha. HP C is compatible with DEC C on OpenVMS VAX, but is somewhat different from the older VAX C compiler most people are familiar with. Read up on the /EXTERN_MODEL and /STANDARD qualifiers to avoid the most common problems. In additon to HP C, there are open-source ports such as Gnu C available for OpenVMS.
• The page size on Alpha and IA-64 systems is variable, but is at least 8 kilobytes. This can have some effect on applications which use the $CRMPSC system service as well as on the display of available memory pages. The page size is available from $GETSYI(SYI$_PAGE_SIZE).

There are also a number of manuals which discuss migration to OpenVMS Alpha available on the documentation CD-ROM media, both in the main documentation and in the archived documentation section.

On more recent OpenVMS Alpha versions, OpenVMS Alpha has begun to add features and support not available on OpenVMS VAX. Salient new areas include the following:

• 64-bit addressing in OpenVMS Alpha V7.0 and later
• Multi-host SCSI support (SCSI TCQ) in V6.2 and later
• PCI support (platform-dependent)
• OpenVMS Galaxy support in V7.2 and later

Please see Section 14.4.5 for Intel Itanium terminology.

14.2 Seeking performance information for Alpha (and VAX) systems?

HP makes a wide range of performance documents available through its FTP and WWW Internet servers (see Section 3.2).

The following contain information on current Alpha and VAX products:

• http://www.compaq.com/alphaserver/servers.html
• http://www.compaq.com/alphaserver/vax/index.html

The following sites contain information on various retired VAX and Alpha products:

• http://www.compaq.com/alphaserver/archive/index.html
• http://www.compaq.com/alphaserver/performance/perf_tps.html

Also see CPU2000:

• http://www.spec.org/osg/cpu2000/
• http://www.spec.org/osg/cpu2000/results/cpu2000.html

This section contains information on VAX and Alpha consoles, and details related to console commands, serial lines, and configuration settings.

14.3.1 What commands are available in the Alpha SRM console?

In addition to the normal BOOT commands and such (see Section 14.3.5.1 for some details) and the normal contents of the console HELP text, operations such as I/O redirection and floppy disk access are possible at the SRM console prompt:

1. Format a FAT floppy, and insert it into the AlphaStation floppy drive.
2. Perform the following at AlphaStation SRM Console :

   >>> show * > env.dat >>> show conf > conf.dat >>> cat env.dat > fat:env.dat/dva0 >>> cat conf.dat > fat:conf.dat/dva0

3. You may use the SRM "ls" command to display the contents of the floppy.

   >>> ls fat:env.dat/dva0 >>> ls fat:conf.dat/dva0

4. You can now transfer the FAT-format floppy to another system.

The abbreviation SRM is derived from the Alpha System Reference Manual, the specification of the Alpha architecture and the associated firmware.

PALcode is a name assigned to a particular set of functions provided by the SRM firmware. PALcode is used to provide low-level functions required by higher-level operating system or application software, functions which may not be directly available in Alpha hardware. PALcode is implemented using available Alpha instructions and using the Alpha processor, though PALcode operates in a mode which simplifies programming. PALcode is also permitted access to processor-specific and otherwise internal features of a particular Alpha microprocessor implementation; microprocessor-specific features which are not easily accessable to operating system or application code.

14.3.3 Alpha COM ports and VAX console serial line information?

This section contains information on the Alpha COM communication ports, and related settings, as well as on the VAX console bulkhead and VAX console serial line connection.

14.3.3.1 Which terminal device name is assigned to the COM ports?

COM2 is normally TTA0:. COM1 is normally TTB0: if the Alpha workstation is booted with the SRM console environment variable set to graphics, and is OPA0: if the console is set to serial.

14.3.3.2 Which serial port is the console on the MicroVAX 3100?

Just to keep life interesting, the MicroVAX 3100 has some "interesting" console ports behaviours based on the setting of the BREAK enable switch. When the console is not enabled to respond to BREAK, MMJ-1 is the console port. MMJ-3 will (confusingly) output the results of the selftest in parallel with MMJ-1. When the console is enabled to respond to BREAK, MMJ-3 becomes the console port, and MMJ-1 will (confusingly) output the results of selftest in parallel with MMJ-3.

14.3.3.3 How can I set up an alternate console on a VAXstation?

Most VAXstation systems have a switch---often labeled S3---that enables one of the serial lines as the system console.

Various members of the DEC 3000 series Alpha systems also have a similarly-labled S3 switch for selection of the alternate console.

Also see Section 14.3.6, Section 11.11, and Section 14.19.

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

14.3.3.4 Please explain the back panel of the MicroVAX II

The MicroVAX-series console bulkhead was used with the KA630, KA650, KA655 processors.

There are three controls on the console bulkhead of these systems:

Triangle-in-circle-paddle: halt enable. dot-in-circle: halt ([break]) is enabled, and auto-boot is disabled. dot-not-in-circle: halt ([break]) is disabled, and auto-boot is enabled. Three-position-rotary: power-up bootstrap behaviour arrow: normal operation. face: language inquiry mode. t-in-circle: infinite self-test loop. Eight-position-rotary: console baud rate selection select the required baud rate; read at power-up.

There are several different bulkheads involved, including one for the BA23 and BA123 enclosures, and one for the S-box (BA2xx) series enclosure. The console bulkheads typically used either the MMJ serial line connection, or the MicroVAX DB9 (not the PC DB9 pinout), please see the descriptions of these in section WIRES1. For available adapters, see Section 14.28.

Also present on the console bulkhead is a self-test indicator: a single-digit LED display. This matches the final part of the countdown displayed on the console or workstation, and can be used by a service organization to determine the nature of a processor problem. The particular countdown sequence varies by processor type, consult the hardware or owner's manual for the processor, or contact the local hardware service organization for information the self-test sequence for a particular processor module. Note that self-tests 2, 1 and 0 are associated with the transfer of control from the console program to the (booting) operating system.

14.3.4 What are Alpha console environment variables?

Alpha systems have a variety of variables with values set up within the SRM system console. These environment variables control the particular behaviour of the console program and the system hardware, the particular console interface presented to the operating system, various default values for the operating system bootstrap, and related control mechanisms---in other words, "the environment variables provide an easily extensible mechanism for managing complex console state."

The specific environment variables differ by platform and by firmware version---the baseline set is established by the Alpha Architecture:

AUTO_ACTION ("BOOT", "HALT", "RESTART", any other value assumed to be HALT), BOOT_DEV, BOOTDEF_DEV, BOOTED_DEV, BOOT_FILE, BOOTED_FILE, BOOT_OSFLAGS, BOOTED_OSFLAGS, BOOT_RESET ("ON", "OFF"), DUMP_DEV, ENABLE_AUDIT ("ON", "OFF"), LICENSE, CHAR_SET, LANGUAGE, TTY_DEV.

OpenVMS Galaxy firmware can add console environment variables beginning with such strings as LP_* and HP_*, and each particular console implementation can (and often does) have various sorts of platform-specific extensions beyond these variables...

The contents of a core set of environment variables are accessible from OpenVMS using the f$getenv lexical and the sys$getenv system service. (These calls are first documented in V7.2, but have been around for quite a while.) Access to arbitary console environment variables is rather more involved, and not directly available.

14.3.5 What are the boot control flag values?

Both VAX and Alpha primary bootstraps support flag values; a mechanism which permits the system manager to perform specific customizations or site-specific debugging of the OpenVMS system bootstrap. While very similar, there are differences between VAX and Alpha systems in this area.

14.3.5.1 What are the Alpha APB boot flag values?

The following flags are passed (via register R5) to the OpenVMS Alpha primary bootstrap image APB.EXE. These flags control the particular behaviour of the bootstrap:

BOOT -FL root,flags

bit description --- ---------------------------------------------- 0 CONV Conversational bootstrap 1 DEBUG Load SYSTEM_DEBUG.EXE (XDELTA) 2 INIBPT Stop at initial system breakpoints if bit 1 set (EXEC_INIT) 3 DIAG Diagnostic bootstrap (loads diagboot.exe) 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 19 FOREIGN Boot involves a "foreign" disk

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

>>> SET BOOT_OSFLAGS 0,1

14.3.5.2 What are the VAX VMB boot flag values?

The following flags are passed (via register R5) to the OpenVMS VAX primary bootstrap image VMB.EXE. These flags control the particular behaviour of the bootstrap:

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

>>> BOOT/R5:flags Bit Meaning --- ------- 0 RPB$V_CONV Conversational boot. At various points in the system boot procedure, the bootstrap code solicits parameter and other input from the console terminal. If the DIAG is also on then the diagnostic supervisor should enter "MENU" mode and prompt user for the devices to test. 1 RPB$V_DEBUG Debug. If this flag is set, VMS maps the code for the XDELTA debugger into the system page tables of the running system. 2 RPB$V_INIBPT Initial breakpoint. If RPB$V_DEBUG is set, VMS executes a BPT instruction immediately after enabling mapping. 3 RPB$V_BBLOCK Secondary boot from the boot block. Secondary bootstrap is a single 512-byte block, whose LBN is specified in R4. 4 RPB$V_DIAG Diagnostic boot. Secondary bootstrap is image called [SYSMAINT]DIAGBOOT.EXE. 5 RPB$V_BOOBPT Bootstrap breakpoint. Stops the primary and secondary bootstraps with a breakpoint instruction before testing memory. 6 RPB$V_HEADER Image header. Takes the transfer address of the secondary bootstrap image from that file's image header. If RPB$V_HEADER is not set, transfers control to the first byte of the secondary boot file. 7 RPB$V_NOTEST Memory test inhibit. Sets a bit in the PFN bit map for each page of memory present. Does not test the memory. 8 RPB$V_SOLICT File name. VMB prompts for the name of a secondary bootstrap file. 9 RPB$V_HALT Halt before transfer. Executes a HALT instruction before transferring control to the secondary bootstrap. 10 RPB$V_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 RPB$V_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 DIAG is also on, then the diagnostic supervisor enters "AUTOTEST" mode. 12 RPB$V_USEMPM Specifies that multi-port memory should be used in addition to local memory, as though both were one single pool of pages. 13 RPB$V_MEMTEST Specifies that a more extensive algorithm be used when testing main memory for hardware uncorrectable (RDS) errors. 14 RPB$V_FINDMEM Requests use of MA780 memory if MS780 is insufficient for booting. Used for 11/782 installations. <31:28> RPB$V_TOPSYS Specifies the top level directory number for system disks with multiple systems.

14.3.6 How do I boot an AlphaStation without monitor or keyboard?

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, the Alpha system will use the serial terminal.

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

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

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

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

The AlphaStation and AlphaServer series use the PC DIN serial connector for the "COM1" and "COM2" serial lines, see Section 14.27 for details and pinout.

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

14.3.7 Downloading and using SRM console Firmware?

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

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

Firmware updates for HP Alpha systems are available from:

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

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

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

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

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

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

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

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

Also see Section 14.3.7.2.

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

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

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

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

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

Apu-> update srm Answer "y" to the "Are you ready...?" Apu-> quit

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

Also see Section 14.3.7.1.

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

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

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

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

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

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

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

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

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

>>> b -fl 0,A0 ddcu BOOTFILE: firmware_boot_file.exe Apu-> update ARC Apu-> verify Apu-> quit Power-cycle the system

Once you have the SRM loaded, you can directly install OpenVMS or Tru64 UNIX on the system. Do not allow Windows NT to write a "harmless" signature to any disk used by OpenVMS, Tru64 UNIX, or Linux, as this will clobber a key part of the disk. (On OpenVMS, you can generally recover from this "harmless" action by using the WRITEBOOT tool.)

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

>>> set os_type NT

and power-cycle the system.

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

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

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

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