HP OpenVMS Systems Documentation

The OpenVMS Frequently Asked Questions (FAQ)

Software-based emulators of the VAX architecture and for specific VAX hardware platforms are available from various sources:

• Stromasys
  http://www.stromasys.com
• Tim Stark's TS10
  http://sourceforge.net/projects/ts10/
• Bob Supnik's Trailing Edge
  http://simh.trailing-edge.com/

VAX emulators that operate on PC systems and/or on OpenVMS Alpha systems are available. For information on an alternative to using a VAX emulator--- on the available DECmigrate VAX executable image translator---please see Section 13.10.

If you are searching for something here, please consider using the text-format FAQ.

In terms of software, very few. As of OpenVMS V6.1, the OpenVMS VAX and OpenVMS Alpha platforms achieved "feature parity". Subsequent work has seen significant enhancements and new features added on OpenVMS Alpha. OpenVMS I64 started with "feature parity" with OpenVMS Alpha at the V8.2 release, and OpenVMS Alpha and OpenVMS I64 are based on and built from the same source pool. (There are low-level platform-specific differences, and there is platform-specific code within the shared source code 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 the Alpha and on the IA-64 architectures is IEEE.
• Data alignment is extremely important for best performance on OpenVMS Alpha and on OpenVMS I64. 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 on OpenVMS I64, and is a direct descendant of Compaq C and DEC C on OpenVMS Alpha. HP C is highly compatible with DEC C on OpenVMS VAX, but does differ somewhat in its syntax and support when compared with the older VAX C compiler most OpenVMS VAX programmers are traditionally familiar with. Read up on the /EXTERN_MODEL and /STANDARD qualifiers to avoid the most common problems, and see the documentation in the DEC C for OpenVMS VAX manuals around migrating from VAX C to DEC C. (In addition to HP C, there have been 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 using the SYI$_PAGE_SIZE itemcode.

There are also a number of manuals which discuss migration to OpenVMS Alpha and to OpenVMS I64 available in the OpenVMS documentation, both in the main documentation and (depending on the age of the manuals involved) in the archived documentation section.

As mentioned earlier, more recent OpenVMS Alpha and OpenVMS I64 releases have added features and support that are not available on OpenVMS VAX. Salient additions include the following:

• 64-bit addressing in OpenVMS Alpha V7.0 and later, and on OpenVMS I64.
• Multi-host SCSI support (SCSI TCQ) in V6.2 and later
• PCI support (platform-dependent)
• OpenVMS Galaxy (vPars) support in OpenVMS Alpha 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 Integrity, Alpha and VAX products, with the VAX information largely accessable via archive-related links at the Alpha-related product web pages:

• http://www.hp.com/go/server/
• http://h18000.www1.hp.com/alphaserver/vax/index.html

The following sites are reachable via the AlphaServer information pages, and contain information on various retired VAX and Alpha products:

• http://h18000.www1.hp.com/alphaserver/archive/index.html
• http://h18000.www1.hp.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.2 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.

On the DEC 2000 series (sometimes incorrectly known by the name of the system as sold for Microsoft Windows NT Alpha; as the DECpc 150 AXP series) on older OpenVMS Alpha releases, COM1 through COM4 are known as OPA0: through OPA3:. On all current OpenVMS releases, these ports are serviced by the terminal driver and not by the console OPDRIVER driver.

Often the easiest way to determine the OpenVMS terminal name assigned to the port is to connect a terminal, log in interactively, and look at the output of SHOW TERMINAL. (Device names can vary by OpenVMS version, as well as by the SRM console environment variable selection.)

For serial console hardware and related information, and for pin-outs and related information, please see Section 14.3 and Section 14.26.

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 series systems and a few Alpha series systems have a switch -- most often labeled S3, largely for historical reasons---that enables one of the serial lines as the system console device; as OPA0:. This disables console output to the graphics display. (For a related behaviour, please see Section 11.10.)

All VAXstation 3100 series systems provide a S3 slide switch, though the oldest may be missing the cut-out through the enclosure that provides access to the switch. The slide switch is located near the diagnostic LED display. (The slide switch is accessable with the cover removed.)

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

The particular port that becomes the console can vary. The printer MMJ connection is used on all VAXstation 3100 series. On VAXstation II, the console DB9 is used, rather than the graphics display. On most (all?) AlphaStation series systems, typically the COM1 serial port becomes the console.

Also see Section 14.3.6, Section 11.10, and Section 14.17. Beware the two different DB9 pin-outs; see Section 14.27 for related details.

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

14.3.3.4 Please explain the back panel of the MicroVAX II

The MicroVAX-series console bulkhead interface was used with the KA630, as well as with the KA650 and 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 pin-out), please see the descriptions of these in section Section 14.26. For available adapters, see Section 14.27.

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 (vPars) 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. These variables allow both vPars (virtual partitions) and lPars and lPars (logical partition) support; vPars is a generic name for soft partitioning constructs such as OpenVMS Galaxy, while lPars is a generic name applied to hard partitioning constructs.

The contents of a core set of SRM console environment variables are accessible from OpenVMS Alpha using the f$getenv lexical and the sys$getenv system service. (These calls are first documented in V7.2, but have been present in OpenVMS Alpha for many releases.) Access to arbitary SRM console environment variables is rather more involved, and not directly available to application software operating outside of kernel-mode.

14.3.5 What are the boot control flag values?

Integrity, 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 among the boot flag implementations for the various architectures.

14.3.5.1 What are the I64 IPB boot flag values?

The OpenVMS I64 primary bootstrap flags are processed within the IA-64 primary bootstrap image IPB.EXE; within the SYS$EFI.SYS structures. The primary bootstrap boot flags are largely parallel to those of OpenVMS Alpha (see Section 14.3.5.2, though the console and the console mechanisms used to specify the boot command, the boot flags, and boot command options do differ markedly.

You can specify the boot flags via an EFI environment variable VMS_FLAGS , or via the boot alias boot options mechanism, or by appending the requested boot flags onto the specification of VMS_LOADER.EFI.

To set the bootstrap flags environment variable at the EFI shell prompt, use:

Shell> SET VMS_FLAGS "0,1"

When you register an EFI boot alias (please see Section 14.4.5 for Intel Itanium terminology), you will be asked if you want to enter boot options, and what type. To add boot flags to a boot alias, select Unicode as the boot options type, and enter an SRM-like options string, such as the conversational bootstrap selected by the following example:

-flages 0,1

For related information on managing EFI boot aliases from OpenVMS I64, please see Section 14.3.10.

When using VMS_LOADER.EFI to request boot flags, you will want to specify the invocation as follows:

fsn:\efi\vms\vms_loader -flags 0,1

The above shows a conversational bootstrap request.

Typical boot flags are listed in Table 14-1.

For a conversational bootstrap of the OpenVMS I64 root SYS4 associated with the fs2: EFI file system device with full bootstrap messaging enabled, specify:

fs2:\efi\vms\vms_loader -flags 4,30001

The flags listed in Table 14-2 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

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

>>> SET BOOT_OSFLAGS 0,1