VSI OpenVMS x86-64 E9.2-4

The VSI OpenVMS x86-64 E9.2-4 field test build enables the SYSTEM_CHECK, POOLCHECK, and BUGCHECKFATAL system parameters by default.

These settings assist in identifying software defects during field testing. As a result, field test systems may bugcheck in situations that would not normally result in a system crash in a production release. In addition, the SYSTEM_CHECK and POOLCHECK settings may reduce system performance.

Users who find this behavior disruptive in their environment may choose to set these parameters to 0. However, this may reduce the ability of the field test build to detect and report software defects.

For information about supported platforms and configurations, refer to the Supported Platforms page on the VMS Software website.

The following platforms have been tested by VSI with VSI OpenVMS x86-64 E9.2-4.

KVM

For KVM, VSI recommends ensuring that your system is up-to-date with KVM kernel modules and the associated packages necessary for your particular Linux distribution.

VSI has tested VSI OpenVMS x86-64 E9.2-4 with KVM on several Linux distributions. The following table lists the Linux distributions, Linux kernel versions, and QEMU versions used during testing:

VMware ESXi

VSI has tested VSI OpenVMS x86-64 E9.2-4 with VMware ESXi V8.0.x.

VSI recommends that you verify the MD5 checksum of the X86E924OE.ZIP file after it has been downloaded from the VMS Software Service Platform to your target system. The MD5 checksum of X86E924OE.ZIP must correspond to the following value:

A42888ACA06FE2046BD12B1B1F49B856

To calculate the MD5 checksum, you can use any platform-specific utilities or tools that are available for your system.

During the installation, you will be prompted to register Product Authorization Keys (PAKs) for the base operating environment and any layered products that are not included in the base OS.

For more information about licensing, refer to Licensing on OpenVMS x86-64.

This section lists features introduced in the current release.

$ DEFINE/NOLOG SORTSHR SYS$SHARE:SORTSHR

$ ANALYZE/AUDIT/EVENT_TYPE=IMGSEC

This section lists issues that have been fixed with the current release.

%DEBUG-E-ERROR, debugger error or session corruption

%DEBUG-F-INTMEMERR, internal memory-pool error

The following functionalities, products, and commands are not available in VSI OpenVMS x86-64 E9.2-4:

A BACKUP command of the form:

$ BACKUP/INITIALIZE input-disk:[directory-path...]*.*; output-disk:save-set.BCK/SAVE_SET

where the output volume is a disk that has been mounted /FOREIGN, does not work in VSI OpenVMS x86-64 E9.2-4 and may yield the following error:

%BACKUP-F-OPENOUT, error opening DKA200:[000000]DKA200$504.BCK; as output
-SYSTEM-W-BADIRECTORY, bad directory file format

This type of operation was originally developed to allow the backup of a large non-removable disk onto a series of smaller removable disks. The feature, referred to as sequential disk operation, is described in the VSI OpenVMS System Manager's Manual, Volume 1: Essentials.

As a workaround, initialize and mount an output volume of a size sufficient to hold the entire backup save set before issuing the BACKUP command as in the following example:

$ INITIALIZE output-disk: label
$ MOUNT output-disk: label
$ CREATE/DIRECTORY output-disk:[]
$ BACKUP input-disk:[directory-path...]*.*; output-disk:save-set.BCK/SAVE_SET

If a sufficiently large output disk is not available, you can instead create and mount a volume set using multiple disks with the INITIALIZE and MOUNT/BIND commands.

In a mixed-version cluster where at least one node is running VSI OpenVMS x86-64 V9.2, certain conditions might trigger a crash of all x86-64 systems, regardless of which OpenVMS version they run. This can happen when a V9.2 MSCP node that is serving disks to other cluster members gets rebooted. In this case, other x86-64 cluster members will see the disks served by MSCP go into mount verification. Upon the verification completion, the MSCP client node might crash.

The fix for this problem is to upgrade all x86-64 cluster nodes to VSI OpenVMS x86-64 V9.2-1 or later.

In VSI OpenVMS x86-64, a container file can only be connected as a shared LD device accessible to multiple architectures as follows:

This limitation will be addressed in a future update for OpenVMS Alpha and OpenVMS IA-64 systems.

If DECnet is installed, network traffic may be blocked after DECnet changes the MAC address of a network interface. This can affect all network traffic, including TCP/IP.

Many hypervisors block traffic when a virtual machine begins transmitting with a MAC address that differs from the address configured for the virtual network interface.

If this issue occurs, consider one of the following actions:

For information about calculating DECnet MAC addresses and configuring DECnet-Plus, refer to the relevant section in the VSI DECnet-Plus for OpenVMS Installation and Configuration Manual.

DECnet Phase IV will not work over a Wi-Fi connection. To be able to use DECnet Phase IV on an x86-64 virtual machine and communicate with other systems, you must have the host machine connected via an Ethernet cable.

DECnet-Plus will work over a Wi-Fi connection, but it must be tunnelled through TCP/IP. For information on DECnet over TCP/IP, refer to the relevant section in the VSI DECnet-Plus for OpenVMS Network Management Guide.

Most operations with the ENCRYPT utility return the following error:

%ENCRYPT-F-ILLALGSEL, algorithm selection unknown, unavailable, or unsupported

This issue will be addressed in a future release of VSI OpenVMS x86-64.

When a LAN Failover device is created and enabled, the LAN Failover driver changes the MAC address by replacing the first four bytes with "AA-00-04-00" while preserving the final two bytes of the original MAC address.

Some hypervisors block network traffic when a virtual machine transmits using a MAC address different from the one configured for the virtual network interface. As a result, network traffic to and from a LAN Failover device may be blocked.

If this issue occurs, configure the hypervisor to allow MAC address changes. For instructions on how to do this, refer to the hypervisor documentation. Typically, this involves enabling settings such as Promiscuous Mode, MAC Address Spoofing, MAC Address Changes, or Forged Transmits on the virtual network interface, a virtual switch, or both. The required settings vary between hypervisors and may also differ between versions of the same hypervisor.

Some MACRO-32 calls leave the stack unaligned. Usually, this does not cause any issues. However, if the called routine (usually from C) attempts to save floating registers on the stack, the instruction requires an aligned stack. This results in a hardware fault.

The suggested workaround for this issue is to save the argument pointer or stack pointer to a temporary register and then use that during the argument push sequence.

To ensure that boot options are applied and recorded consistently, VSI strongly recommends setting up and managing firmware boot options using the built-in platform firmware utilities, as opposed to the SYS$MANAGER:BOOT_OPTIONS.COM procedure.

VSI recommends that any privileged images linked using the LINK/SYSEXE command in VSI OpenVMS V9.2 or earlier be relinked for the current release because data structures and interfaces are subject to change between releases.

Note that the images linked using LINK/SYSEXE in VSI OpenVMS V9.2-1 do not need to be relinked for the current release.

VSI OpenVMS x86-64 includes an initial implementation of the Symbolic Debugger. While many features work, there are some that do not work. These are listed in the following sections. VSI will address these issues in a future release.

break at DANCE\pause_actions\%LINE 138517
%DEBUG-I-NOTORIGSRC, original version of source file not found
       file used is SYS$SYSDEVICE:[DEBUG.BLUEY]DANCE.C;1
%DEBUG-W-UNAREASRC, unable to read source file SYS$SYSDEVICE:[DEBUG.BLUEY]DANCE.C;1
-RMS-E-EOF, end of file detected

The Pthread debugger on VSI OpenVMS x86-64 supports viewing thread call stacks. To show the call stack, use the -o C option in the THREADS command. For example, if the debugger runs in the PTHREAD SDA extension, the command to show the call stack for thread id 3 is the following:

SDA> PTHREAD THREADS -o "C" 3
Process name: SECURITY_SERVER   Extended PID: 0000008F  Thread data:
"threads -o "C" 3"
-----------------------------------------------------------------------------
thread 3 (blocked, timed-cond) "Process_Proxy_Task", created by pthread
  Stack trace:
     0xffff83000c83b1a5 (pc 0xffff83000c83b1a5, sp 0x00000000024e3228)
     0xffff83000c87b53a (pc 0xffff83000c87b53a, sp 0x00000000024e3230)
     0xffff83000c858493 (pc 0xffff83000c858493, sp 0x00000000024e32e0)
     0xffff83000c852b04 (pc 0xffff83000c852b04, sp 0x00000000024e33f0)
     0xffff83000c8499a3 (pc 0xffff83000c8499a3, sp 0x00000000024e34d0)
     0xffff83000c844e9a (pc 0xffff83000c844e9a, sp 0x00000000024e3800)
     0x0000000080004ad8 (pc 0x0000000080004ad8, sp 0x00000000024e3900)
     0x0000000080007fe6 (pc 0x0000000080007fe6, sp 0x00000000024e3950)
     0xffff83000c8887df (pc 0xffff83000c8887df, sp 0x00000000024e3bd0)
     0xffff83000c83b0ea (pc 0xffff83000c83b0ea, sp 0x00000000024e3f00)

However, the output of the THREADS -o u Pthread debugger command that shows an SDA SHOW CALL command cannot yet be used in SDA.

SDA> PTHREAD THREADS -o u 3
Process name: SECURITY_SERVER   Extended PID: 0000008F  Thread data:
"threads -o u 3"
------------------------------------------------------------------------
thread 3 (blocked, timed-cond) "Process_Proxy_Task", created by pthread
  Unwind seed for SDA SHOW CALL 00000000024e2e40
SDA> SHOW CALL 00000000024e2e40
00000000.024E2E40 is no valid handle for a call stack start of
00000000.00000000

If the FTP service does not work after it has been started, switch to passive mode with the following command:

FTP> SET PASSIVE ON
Passive is ON

In passive mode, the FTP client always initiates a data connection. This is useful in virtual machine environments when there is network address translation (NAT) in your network.

To run this command automatically when you invoke FTP, put it into SYS$LOGIN:FTPINIT.INI. For the full description of the SET PASSIVE command, refer to the VSI TCP/IP Services for OpenVMS User’s Guide.

VSI OpenVMS x86-64 uses a boot method called Memory Disk that simplifies the boot process by eliminating boot complexity and decoupling the VSI OpenVMS Boot Manager from a specific device or version of VSI OpenVMS x86-64. Memory Disk is created and deployed automatically during the installation process.

The Memory Disk contains all files that are required to boot the minimum OpenVMS kernel and all files needed to write system crash dumps. Changes such as file modifications or PCSI kit/patch installations require the operating system to execute a procedure to update the Memory Disk container, thus assuring that the next boot will use the new images. A command procedure, SYS$UPDATE:SYS$MD.COM, keeps the Memory Disk up-to-date.

If any changes are made that affect the boot path or dump processing, the SYS$MD.COM command procedure must be run before rebooting. This includes modifications to files referenced or loaded during the boot process (up to and including activation of STARTUP) and files used by the dump kernel.

However, there are two exceptions to the above requirement. If you take either of the following actions that affect the boot path or dump processing, you do not need to run SYS$MD.COM:

Use the following command exactly as specified:

$ @SYS$UPDATE:SYS$MD.COM

After SYS$MD.COM completes, you must reboot the system.

Running SYS$MD.COM produces output similar to the following:

$ @SYS$UPDATE:SYS$MD.COM
Updating the system memory disk. Please do not interrupt this procedure...

Created memory disk $60$DKD1:[VMS$COMMON.SYS$LDR]SYS$MD.DSK;8
        - using 171216 blocks in 6 extents with 18965 spare blocks
        - mounted on $60$LDM9823: with volume label MD26228A50FH
        - contains OpenVMS E9.2-4

After the next system reboot, purge obsolete versions of the Memory Disk using the following command:

$ PURGE SYS$LOADABLE_IMAGES:SYS$MD.DSK

VSI OpenVMS x86-64 provides support for process dumps. The only method currently available for analyzing process dumps is using the System Dump Analyzer (SDA). Most SDA commands that display data about a process can be used to examine the state of the process. For example, SHOW PROCESS, SHOW CRASH, SHOW EXCEPTION, SHOW CALL, EXAMINE, and MAP. Support for the Symbolic Debugger interface will be added in a future release of VSI OpenVMS x86-64.

VSI OpenVMS x86-64 system crash dumps are written using a minimal VMS environment called the Dump Kernel. All files used by the Dump Kernel are included in the Memory Disk described in Section 4.1, ''Memory Disks''.

Interleaved Dumps

VSI OpenVMS x86-64 supports two system crash dump types: Compressed Selective Dump and Interleaved Dump.

A Compressed Selective Dump is written using only the primary CPU running in the Dump Kernel, while an Interleaved Dump makes use of the available secondary CPUs. If the dump device is backed by Solid State Disk (SSD) storage, the dump can be written much faster, allowing the system to be rebooted sooner.

The DUMPSTYLE parameter specifies which dump type is used. Unless overridden in SYS$SYSTEM:MODPARAMS.DAT, AUTOGEN selects a default value based on the number of CPUs in the system: 9 (Compressed Selective Dump) for single-CPU systems and 128 (Interleaved Dump) for systems with more than one CPU.

In OpenVMS x86-64, the only additional DUMPSTYLE bits that affect dump content are bit 1 (value 2), which enables full console output (registers, stack, and system image layout), and bit 5 (value 32), which limits the dump to key processes and global pages. Either or both of these values may be added to the default DUMPSTYLE values (9 for Compressed Selective Dump and 128 for Interleaved Dump). Bit 2 (value 4), which historically controlled Dump Off System Disk (DOSD) operation, is ignored on x86-64. Use the SET DUMP/DEVICE command to specify an alternate dump device.

Dump Off System Disk

Crash dumps can be written to the system disk or to an alternate disk which is specifically designated for this purpose.

Dumps to the system disk are written to SYS$SYSDEVICE:[SYSn.SYSEXE]SYSDUMP.DMP which can be created or extended using the SYSGEN utility.

Dumps to an alternate device can be set up as described in the example below:

You can view the setting by using the SHOW DUMP_OPTIONS command. The change is effective immediately, a reboot is not required.

For additional information, refer to the VSI OpenVMS x86-64 Boot Manager User Guide.

Changes in SET DUMP_OPTIONS

A new qualifier, /MAXIMUM=CPUS=n, has been added to the SET DUMP_OPTIONS command. This qualifier sets the number of CPUs used by the Dump Kernel when writing an Interleaved Dump. It has no effect when a Compressed Selective Dump is used. By default, the Dump Kernel will use all eligible secondary CPUs that are available in the system, up to a maximum of 10 (including the primary CPU). Eligible CPUs are those that were halted successfully when the system crashed and that did not trigger the crash with a MACHINECHK or KRNLSTAKNV Bugcheck.

The maximum number of CPUs that can be specified in the command is also 10.

System Dump Analysis

VSI strongly recommends that the version of SYS$SYSTEM:SDA.EXE and SYS$LIBRARY:SDA$SHARE.EXE used to analyze a system dump be exactly the same as the version of OpenVMS that was in use when the system crash occurred. However, it is often possible to use SDA images from a different version of OpenVMS, provided there are no major differences between the versions and the warning messages by SDA are ignored (either %SDA-W-LINKTIMEMISM, or %SDA-W-SDALINKMISM, or both).

New SDA Command Qualifiers in OpenVMS x86-64

The SDA commands below now have new qualifiers that are specific to OpenVMS x86-64. Also, the format of several output messages has been changed to accommodate the architectural differences.

SHOW DUMP Command

The qualifier /PERFORMANCE has been added to display the performance data collected by the Dump Kernel while writing a dump.

Depending on the additional keywords used, the data displayed by the SHOW DUMP/PERFORMANCE command can include system information (/PERFORMANCE=SYSTEM), per-CPU information (/PERFORMANCE=CPU), and per-process information (/PERFORMANCE=PROCESS). If no additional keywords are specified with the command, all information mentioned above will be displayed.

SHOW EXECUTIVE Command

The qualifier /SDA_EXTENSION has been added to limit the list of displayed executive images to those that are paired with SDA extensions. For example, SYS$LOADABLE_IMAGES:SWIS$DEBUG.EXE.

SHOW PAGE_TABLE and SHOW PROCESS /PAGE_TABLE commands

The qualifiers /BPTE, /PDE, /PDPTE, /PML4E, and /PML5E have been added to allow you to display a specific level of page table entries. The default behavior is to display the base page table entry (BPTE).

The qualifier /MODE has been added to display the page tables for a specific mode. The default behavior is to display the page tables for all modes. Valid keywords are: KERNEL, EXECUTIVE, SUPERVISOR, and USER.

SHOW POOL Command

The output for the qualifier /RING_BUFFER is now affected by the additional qualifiers /ALL and /S2_NPP. The default behavior for SHOW POOL /RING_BUFFER is to display all entries in the nonpaged pool ring buffer. If /S2_NPP is specified, then the ring buffer for S2 pool is displayed. If /ALL is specified, then the contents of both ring buffers are displayed, interleaved by their timestamps.

The qualifier /S2_NPP, when used without /RING_BUFFER, displays only the S2 pool. The default behavior is to display all pool types.

The qualifier /USB displays only the nonpaged pool that is reserved for use by USB devices. The default behavior is to display all pool types.

VALIDATE POOL Command

The qualifier /S2_NPP allows validation of only the S2 pool. The default behavior is to validate all pool types.

The qualifier /USB allows validation of only the nonpaged pool that is reserved for use by USB devices. The default behavior is to validate all pool types.

SDA Commands and Qualifiers not Available in VSI OpenVMS x86-64

The following commands and qualifiers are not applicable to VSI OpenVMS x86-64 systems:

Other SDA Command Changes

The COPY command qualifiers /COMPRESS, /DECOMPRESS, and /PARTIAL cannot be used with an Interleaved Dump.

User-written x86-Assembler code must follow the VSI OpenVMS calling standard (see the VSI OpenVMS Calling Standard Manual) to provide exception handling information that is used by the exception handling mechanism to find a handler in one of the callers of the Assembler module. Without that information, exception handling can only call the last chance handler, which means the application will likely not be able to handle the exception.

See the following example of a user-written x86-Assembler module:

        .vms_module "MYTEST","X-01"
        .text
        .globl  MYTESTRTN
        .align 16
        .type   MYTESTRTN,@function

MYTESTRTN:
        .cfi_startproc
        pushq   %rbp                    // Establish a frame pointer
        .cfi_def_cfa_offset 16          // Record distance to saved PC
        .cfi_offset %rbp, -16
        movq    %rsp,%rbp
        .cfi_def_cfa_register %rbp

        // function body

        movq    %rbp,%rsp               // Restore stack and return
        popq    %rbp
        .cfi_def_cfa %rsp, 8            // Adjust distance to saved PC
        retq
        .size MYTESTRTN, .-MYTESTRTN
        .cfi_endproc

VSI provides freeware utilities for managing ZIP archives on OpenVMS x86-64 systems. In VSI OpenVMS x86-64 E9.2-4, the installation procedure automatically puts these files in the following directories on the system disk: