VSI OpenVMS x86-64 E9.2-3

VSI OpenVMS x86-64 E9.2-3 does not support cluster common system disks.

VSI OpenVMS x86-64 supports SATA disks across all supported hypervisors.

On Oracle VirtualBox, VSI OpenVMS also supports VirtIO-SCSI disks.

On VMware ESXi, VSI OpenVMS also supports the configuration of up to four (4) LSI Logic Parallel SCSI controllers per virtual machine. Note that the LSI Logic SAS controllers are not supported.

Starting with the E9.2-3 release, VSI OpenVMS x86-64 supports the VMware VMDirectPath I/O feature with the HPE SN1100Q fibre channel HBAs for data disks. For more details, refer to Section 3.1.3

On KVM/QEMU, VSI OpenVMS also supports SCSI disks on a VirtIO controller. Note that only one VirtIO-SCSI adapter can be configured and used on a VSI OpenVMS x86-64 V9.2-x system. This functionality requires QEMU version 6.2 or later.

VSI OpenVMS x86-64 E9.2-3 can be installed as a guest operating system on KVM, VMware, and VirtualBox virtual machines using the X86E923OE.ISO file.

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-3 with KVM on several Linux distributions. The following table includes the Linux distribution, version, and the QEMU version:

VMware

VSI has tested VSI OpenVMS x86-64 E9.2-3 with the following VMware products:

VMware Licenses

Starting with the current release, all VMware license types are supported if you are connecting to your virtual machine using the Guest Console feature (see Section 3.1.4).

Note, however, that if you are using a virtual serial port connection, only the following VMware license types are supported for running VSI OpenVMS x86-64 E9.2-3:

The VMware licenses that are marked as "Supported" work with the Console Guest feature but not with the use of virtual serial lines in a virtual machine.

VirtualBox

VSI tests with VirtualBox V7.0.x and regularly installs patches when they are available.

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

3F330FA890074F3769FD3BC271237A08

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

VSI OpenVMS x86-64 requires that the CPU supports certain features that are not present in all x86-64 processors. When using virtual machines, both the host system and guest virtual machine must have the required features.

Host System Check

Before downloading the VSI OpenVMS x86-64 E9.2-3 installation kit, VSI recommends that you determine whether your host system has the required CPU features to run VSI OpenVMS x86-64. For this purpose, execute a Python script called vmscheck.py on your host system. This script, along with the accompanying PDF document entitled VMS CPUID Feature Check, can be downloaded from the official VSI OpenVMS x86-64 web page.

The VMS CPUID Feature Check document contains instructions on how to run the script and interpret the results and also describes script limitations.

Guest Virtual Machine Check

The OpenVMS Boot Manager performs the CPU feature check on the guest virtual machine. The CPU feature check is performed automatically every time the Boot Manager is launched. If the check has passed successfully, the following message is displayed:

Checking Required Processor Features:     PASSED

In addition, before booting VSI OpenVMS x86-64 E9.2-3, you can issue the following Boot Manager command to list the compatibility details:

BOOTMGR> DEVICE CPU

When you are in the Boot Manager and before proceeding with the installation of VSI OpenVMS x86-64, you are required to access the system either via the new Guest Console feature (see Section 3.1.4) or through a serial port connection with a terminal emulator (such as PuTTY). Read the remainder of this section only if you are using a terminal emulator.

You may need to experiment in order to find the appropriate setting for your emulator. Refer to the VSI OpenVMS x86-64 Boot Manager User Guide and VSI OpenVMS x86-64 E9.2-3 Installation Guide for more details on the emulator settings.

On Windows, VSI recommends using PuTTY. Some PuTTY users have found success with the following settings:

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 (chain loader) 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$MD.COM, keeps the Memory Disk up-to-date.

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 VSI OpenVMS x86-64 E9.2-3 Installation Guide.

VSI OpenVMS x86-64 V9.2-x provides support for the following network stacks:

VSI TCP/IP Services V6.0-25 is part of the OpenVMS x86-64 E9.2-3 installation and will be installed along with the operating system. For more information, refer to VSI TCP/IP Services Version V6.0 Release Notes and other VSI TCP/IP Services documentation available at docs.vmssoftware.com.

During the OpenVMS x86-64 E9.2-3 installation, you will also be offered the option to install either VSI DECnet Phase IV or VSI DECnet-Plus. Note that if you plan to use DECnet, you must choose between VSI DECnet Phase IV and VSI DECnet-Plus. Only one of these products can be installed on your system at a time.

$ @SYS$UPDATE:SYS$MD.COM

$ PURGE SYS$LOADABLE_IMAGES:SYS$MD.DSK

FTP> SET PASSIVE ON
Passive is ON

This section lists features introduced in the current release.

BOOTMGR> OPA0

%GCTERM-E-MEMALOC Bad Canvas

$ MC SYSGEN
SYSGEN> SET NPAGEDYN_S2 8
SYSGEN> SET NPAGEXPVIR_S2 10
SYSGEN> WRITE CURRENT

$ set def sys$system
$ mcr authorize
UAF> show ssh$ssh/br
   Owner    Username   UIC       Account  Privs Pri Directory
   SSH$SSH  SSH$SSH    [3656,1]           All    4  SSH$ROOT:[VAR]

UAF> mod ssh$ssh/account="SSH$SSH"
UAF> show ssh$ssh/br
   Owner    Username   UIC       Account  Privs Pri Directory
   SSH$SSH  SSH$SSH    [3656,1]  SSH$SSH  All    4  SSH$ROOT:[VAR]
UAF>^z
$

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

Before upgrading to VSI OpenVMS E9.2-3, check for multiple versions of SYS$HELP:HELPLIB.HLB and SYS$LIBRARY:STARLET.OLB on your disk. If more than one version of either file exists, there is a chance that the latest version will be lost during the upgrade. To avoid this, purge the files so that only one version remains.

This issue will be fixed in a future release of VSI OpenVMS.

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.

Currently, CLUE$STARTUP can only process the first Dump Off System Disk (DOSD) device in a list of DOSD devices.

This issue will be fixed in a future release.

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.

A BACKUP command of the form:

$ BACKUP/INITIALIZE input-disk:[directories...]*.*; output-disk:save-set.bck/SAVE

where the output volume is a disk that has been mounted /FOREIGN, does not work in VSI OpenVMS x86-64 E9.2-3 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:[directories...]*.*; output-disk:save-set.bck/SAVE

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.

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 you run a VSI OpenVMS x86-64 image on VSI OpenVMS for Integrity Servers, no message from the image activator appears, but an access violation occurs.

This issue will be corrected in a future patch kit for VSI OpenVMS for Integrity Servers.

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

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.

The DEVELOPER boot flag 0x08000000 is reserved for use by VSI, and its function is subject to change. Booting with this flag set can result in an unexpected system behavior.

During VSI OpenVMS x86-64 installation, if you choose to install DECnet Phase IV for OpenVMS x86-64 or TCP/IP Services for OpenVMS x86-64, you will see an output similar to the following:

* Product VSI X86VMS TCPIP Vx.x-x requires a system reboot.
Can the system be REBOOTED after the installation completes? [YES]

If this happens, you must answer YES (the default response), otherwise the installation will be terminated.

Later in the installation, you will see the following messages:

%PCSI-I-SYSTEM_REBOOT, executing reboot procedure ...

Shutdown/reboot deferred when this product is installed as part of the O/S
installation/upgrade

If you are installing both optional products, you will see these messages twice.

These messages may safely be ignored. VSI will address this issue in a future release.

VSI OpenVMS x86-64 has extended file caching (XFC) enabled by default.

The high-performance Sort/Merge utility (HYPERSORT) is available in VSI OpenVMS x86-64. Enable the utility with the following command:

$ DEFINE SORTSHR SYS$LIBRARY:HYPERSORT.EXE

Programs that use the LIB$INITIALIZE startup mechanism must declare a LIB$INITIALIZE PSECT and include the LIB$INITIALIZE module from STARLET.OLB when linking. Traditionally, besides the PSECT, source programs simply declared an external reference to that module, and the linker resolved the reference from STARLET.OLB. However, the LLVM backend used by the cross-compilers removes that external reference from the object file since there were no additional source references to the routine.

The linker was changed to automatically include the required module if it encounters a LIB$INITIALIZE PSECT. For details, see the VSI OpenVMS Linker Utility Manual.

This change does not affect any source module where external references to the LIB$INITIALIZE module were declared. This change also does not affect any existing link commands that explicitly include the LIB$INITIALIZE module from STARLET.OLB.

When the linker encounters writable code sections, with PSECT attributes set to WRT and EXE, it prints the following informational message:

%ILINK-I-MULPSC, conflicting attributes for section <PSECT name>
        conflicting attribute(s): EXE,WRT
        module: <module name>
        file: <obj-or-olb-filename>

When the linker finds unwind data in a module, but no section with the PSECT attribute set to EXE, it prints the following informational message:

%ILINK-I-BADUNWSTRCT, one or more unwind related sections are
missing or corrupted
        section: .eh_frame, there is no non-empty EXE section
        module: <module name>
        file: <obj-or-olb-filename>

These messages are seen mainly with MACRO-32 and BLISS source modules. All code sections must be non-writable. You must have code in sections with the PSECT attribute set to EXE.

When linking applications that use the POSIX Threads Library (PTHREAD$RTL), you can set up the application in such a way that it can receive upcalls from VMS and/or that VMS should map user threads to multiple kernel threads. This behavior can be enabled with the /THREADS_ENABLE qualifier. However, if that qualifier is not specified, the linker automatically enables upcalls and displays an informational message to make the user aware of that. The user can overwrite the default behavior by expliclitly specifying /NOTHREADS_ENABLE.

When porting an application from Itanium to x86-64, be aware that the image layout may change in an incompatible way – although the compile and link commands/options did not change. This is an architectural difference.

On Itanium, the compiler may generate short data which is accessed in an efficient way. The Itanium linker always collects short data to the DEFAULT CLUSTER, no matter where the object module that defines this short data is collected. That is, in a partially protected shareable image, an object module may be collected into a protected linker cluster, but its short data may be collected into an unprotected cluster, and so it is not protected. User-mode code in the shareable image can write to it.

On x86-64, there is no short data. All data defined in an object module will go where the module goes (except the defining PSECT which is moved with an explicit COLLECT option). That is, on x86-64, for partially protected shareable images, all data defined by an object module which is collected into a protected linker cluster will be protected. User-mode code in the shareable image cannot write to it.

If you change anything that affects the boot path or dumping, you must run the command procedure SYS$MD.COM before rebooting. For instance, if you change any files referenced or loaded during booting (up to and including the activation of STARTUP), or any files used by the dump kernel, then you must run SYS$MD.COM.

However, in VSI OpenVMS x86-64 V9.2-x there are two exceptions to the above statement. If you make any of the following changes that affect the boot path or dumping, you do not need to run SYS$MD.COM:

Use the following command exactly as specified here:

$ @SYS$UPDATE:SYS$MD

No parameters are needed, the defaults should apply.

When SYS$MD.COM completes, you must reboot.

When SYS$MD.COM is invoked, the system will display something like the following:

$ @SYS$UPDATE:SYS$MD
        Created memory disk DKE100:[VMS$COMMON.SYS$LDR]SYS$MD.DSK;1
        - using 184064 blocks in 1 extent with 1010 spare blocks
        - mounted on LDM9323: with volume label MD230120DD6A
        - contains OpenVMS V9.2-1

$

After the next system reboot, purge the memory disk with the following command:

$ PURGE SYS$LOADABLE_IMAGES:SYS$MD.DSK

VSI OpenVMS x86-64 does not support swap files. The system’s physical memory should be managed with appropriately sized system memory and page file(s).

The AUTOGEN and SWAPFILES procedures no longer create swap files on the system disk. If a swap file resides on the system disk, it will no longer be installed as part of the system startup.

In the current release, the SYSGEN INSTALL command does not support the /SWAPFILE qualifier. The use of the qualifier will result in a syntax error.

Processes may be seen in the Computable Outswapped (COMO) state. This is a transient state for newly created processes. Processes will never appear in the Local Event Flag Wait Outswapped (LEFO) or Hibernate Outswapped (HIBO) states. All performance counters associated with swapping are still present in the system. Various MONITOR displays will show swapping metrics.

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, MAP. Support for the Symbolic Debugger interface will be added in a future release of VSI OpenVMS x86-64.

The following changes and additions have been made to the SYSGEN Utility for VSI OpenVMS x86-64. For more information about SYSGEN qualifiers and parameters, see VSI OpenVMS System Management Utilities Reference Manual, Volume II: M–Z.

All system parameters are exposed on every platform: x86-64, Integrity, and Alpha. In addition, flags can be set or cleared on any platform using the SYSGEN Utility. However, the flag may not have any effect on a platform for which it is not intended.

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

Interleaved Dumps

Starting with the V9.2-1 release, 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 a Solid State Disk (SSD), the dump can be written much faster, thus allowing the system to be rebooted sooner.

The DUMPSTYLE parameter specifies which dump type is being used. The default value for the parameter is 9 (Compressed Selective Dump). However, if the system has more than one CPU and the SYS$SYSTEM:MODPARAMS.DAT file does not include a value for the DUMPSTYLE parameter, then, when AUTOGEN runs, it will set the value of DUMPSTYLE to 128 (Interleaved Dump).

In OpenVMS x86-64, the only other pertinent bits in the DUMPSTYLE parameter are bit 1 (full console output: registers, stack, and system image layout) and bit 5 (only dump system memory, key processes, and key global pages). Either or both of these bits can be set in addition to the two base values (9 and 128). Bit 2 (dump off system disk) is no longer required.

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.

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 SDA.EXE and 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, 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.

The linker includes sufficient traceback information in the image file for a functional symbolic traceback. As a result, by default, the image file may be larger than in previous versions/updates. This additional debug information is not read by the image activator, so it will not slow down image activation. However, to make image files smaller, the linker was changed to include reduced traceback information. This affects the traceback output, as it no longer prints the routine name. Any other traceback output is unaffected. This feature can be enabled with the LINE_NUMBER keyword for the /TRACE qualifier. For details, see the VSI OpenVMS Linker Manual.

Traceback now prints the image name, routine name, and line numbers much like traceback on OpenVMS Alpha and OpenVMS Integrity server systems, with the following differences:

These differences will be addressed in a future release of VSI OpenVMS x86-64.

Starting with VSI OpenVMS x86-64, the call stack can be viewed in the Pthread debugger. 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

VSI DECram for OpenVMS, also referred to as a RAMdisk, is fully operational in VSI OpenVMS x86-64.

For details of the DECram disk characteristics and configuration, refer to the DECram for OpenVMS User’s Manual.

Symbolic links (symlinks) and POSIX pathnames are documented in the VSI C Run-Time Library Reference Manual for OpenVMS Systems. The release notes in this section augment that documentation.

NOSYMLINKVERS, cannot create multiple versions of a symlink

$ CREATE/SYMLINK=FILE.TXT LINK.TXT
$ COPY FILE2.TXT LINK.TXT
$ COPY FILE2.TXT LINK.TXT
$ COPY FILE2.TXT LINK.TXT

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. In addition, some of the missing features will require future native compilers, as the cross compilers are unable to provide sufficient debug information to the debugger.

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

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

CD audio functionality is not supported on VSI OpenVMS running on x86-64. CD audio functionality has been deprecated for all x86 platforms and beyond.

This does not apply to VSI OpenVMS running on Alpha or Integrity platforms.

SYS$UPDATE:STABACKIT.COM has been been deprecated in VSI OpenVMS x86-64. The STABACKIT functionality originally supported Standalone Backup for VAX systems and has long been replaced by SYS$SYSTEM:AXPVMS$PCSI_INSTALL_MIN.COM for OpenVMS Alpha and SYS$SYSTEM:I64VMS$PCSI_INSTALL_MIN.COM for OpenVMS Integrity systems. The referenced command procedures produce a minimal installation of OpenVMS on a target device which may be booted to allow a full backup of the system disk. STABACKIT would offer to run the appropriate procedure for you.

VSI OpenVMS x86-64 E9.2-3 currently does not support minimal installation of the operating system on a non-system disk. Backup options for virtual machines include the ability to perform backup from the host operating system and the ability to checkpoint or clone within the hypervisor. One may also boot from the installation media and choose the DCL subprocess menu entry to perform a backup of the system device.

Starting with VSI OpenVMS V9.2-1, the default values for the system parameters SMP_SPINWAIT and SMP_LNGSPINWAIT have been increased. This change was made to avoid potential CPUSPINWAIT and CLUEXIT crashes occurring on virtual machines.

When allocating large amounts of system memory such as when allocating a large DECram disk, the operation could take a long time. These operations could result in a CLUEXIT or CPUSPINWAIT crash. Starting with VSI OpenVMS V9.2-1, improvements have been made to the system to improve the efficiency of the system memory allocation.

The SET FILE/ATTRIBUTES command supports the Contiguous Best Try (CBT) keyword.

With CBT enabled, the file system will allocate additional blocks to a file contiguously on a best effort basis. The file system will disable the attribute if the best effort algorithm cannot complete the file extension with at most three additional extents.

To enable CBT, use the following command:

$ SET FILE/ATTRIBUTES=CBT

To disable CBT, use the following command:

$ SET FILE/ATTRIBUTES=NOCBT

The ANALYZE/DISK_STRUCTURE command now supports the /EXTENTS qualifier.

ANALYZE/DISK_STRUCTURE/EXTENTS will produce a report on the fragmentation of free space on a volume. By default, the only output is the number of extents of free space and the total number of free blocks. For additional details, specify one of the following additional qualifiers with the ANALYZE/DISK_STRUCTURE/EXTENTS command:

Consider the following example:

$ ANALYZE/DISK_STRUCTURE/EXTENTS/LARGEST/REQUIRED=20000 LDM9063:

Extent report for _X86VMS$LDM9063:
==================================

The disk has 6 extents of free space for a total of 25262 free blocks.

The extent sizes are:

             17176
              5591
              2469
                15
                 9
                 2

2 extents are required for an allocation of 20000 blocks.

The PRODUCT SHOW PRODUCT command supports the /OPTIONS=keyword qualifier. A keyword is required. Currently, the only defined value is EXTENDED_DISPLAY. If you specify /OPTIONS=EXTENDED_DISPLAY, the system will output an additional line of information for each of the listed products, giving you the DESTINATION that was specified during the product installation. If no alternative destination was used during the product installation, the system disk will be shown as the destination. See the following example:

$ PRODUCT SHOW PRODUCT/OPTIONS=EXTENDED_DISPLAY *VMS
------------------------------------ ----------- ---------
PRODUCT                              KIT TYPE    STATE
------------------------------------ ----------- ---------
VSI X86VMS OPENVMS V9.2-2            Platform    Installed
    Destination: DISK$SYSTEM_DISK:[VMS$COMMON.]
VSI X86VMS VMS V9.2-2                Oper System Installed
    Destination: DISK$SYSTEM_DISK:[VMS$COMMON.]
------------------------------------ ----------- ---------
2 items found

The /OPTIONS qualifier has been available since V8.4-1H1. It can be combined with other qualifiers, for example, /FULL.

In VSI OpenVMS x86-64, the CHECKSUM utility supports the SHA1 and SHA256 secure hash algorithms to calculate file checksums. These algorithms calculate a checksum for all bytes within a file and ignore possible record structures.

Use the CHECKSUM command qualifier /ALGORITHM=option to specify the algorithm for the file checksum calculation.

For information about all supported checksum algorithms, refer to the VSI OpenVMS DCL Dictionary: A-M.

VSI OpenVMS x86-64 V9.2-x includes an updated VSI C Run-Time Library (C RTL). The update provides bug fixes, as well as new functions, including the additional C99 Standard functions, new constants, new and updated header files. For a complete list of changes and additions, refer to the VSI C Run-Time Library Reference Manual for OpenVMS Systems and the release notes provided with your VSI C RTL ECO kit.

VSI OpenVMS x86-64 V9.2-x does not enable Jumbo Packets automatically during boot. You can enable Jumbo Packets manually. Note that after you do so, you must restart the LAN adapter communications.

VSI OpenVMS x86-64 V9.2-x takes advantage of 2 MB hardware pages in limited areas of the operating system. Usage of the larger page size allows for faster memory access. Larger pages are used by parts of the executive code and data along with some internal memory management data.

Even if the hypervisor appears to allow it, do not change the configuration of a VSI OpenVMS virtual machine while it is running, as this may cause it to hang. Before editing the settings, make sure to power off the virtual machine.

$ @SYS$MANAGER:UTC$SET_TIME.COM

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

On KVM/QEMU systems, when a virtual machine is powered on, the system time is set based on the value of the CLOCK OFFSET parameter in the configuration file of that virtual machine. The default value is 'utc'. Depending on the physical location of the host system, this might lead to differences between system times of the VM and the host.

To resolve this problem, use the virsh edit command to edit the XML configuration file of your virtual machine and change the value of the CLOCK OFFSET parameter to 'localtime', like so:

<clock offset='localtime'>

For more information, see the official documentation for your Linux distribution.

Host systems running Windows 10 and 11 that have previously run Microsoft Hyper-V hypervisor may fail the CPU feature checks. The issue is that certain CPU features are supported on the host system (the vmscheck.py script passes), but not on the guest system (the OpenVMS Boot Manager check fails). Primarily, the XSAVE instruction may not be present on the guest system.

This issue persists even if the Hyper-V feature has been removed. This happens because certain Hyper-V services interfere with VirtualBox.

The VirtualBox developers are aware of this issue and are working to improve the interoperability with Hyper-V.

To explicitly disable execution of the Hyper-V services that interfere with VirtualBox, perform the following steps on your Windows host system:

The XSAVE instruction should now be available to your VirtualBox guest.

For more information about the CPU feature checks, see Section 2.4 in the Section 2 section.

Tips on How To Determine If Hyper-V Services Impact Your VirtualBox VM

When you launch a VirtualBox guest, look for the icon in the guest window status bar.

View the log file VBOX.LOG.

When running VSI OpenVMS x86-64 as a guest in a VirtualBox VM, TCP console ports may become unusable after a guest session has been terminated. After that, you cannot connect to your VirtualBox VM again. These ports remain in the LISTEN state even after you have disconnected the remote terminal session.

As a workaround, use the following commands to free your TCP ports and connect to your VirtualBox VM:

vboxmanage controlvm <vmname> changeuartmode1 disconnected
vboxmanage controlvm <vmname> changeuartmode1 tcpserver <port>

The VirtualBox developers have indicated that the fix will be provided in an upcoming VirtualBox maintenance release.

It has been reported that a VMware guest does not boot when a second SATA controller is added to the configuration. In their case, removing the second SATA controller eliminates the issue.

VSI has not observed boot issues when adding a second SATA controller during testing. If you encounter this situation, please report your issue via the VMS Software Service Platform.

If you are running a VMware virtual machine with multiple buses, you may run into a problem with the list of bootable devices displayed by the Boot Manager.

If, after entering the DEVICE command, your Boot Manager display normally looks similar to the following:

but occasionally, upon shutting down your VMware virtual machine, it appears as shown below:

This means, not all of your devices and/or buses have been configured properly. Proceeding to boot your VMware virtual machine from this truncated configuration display may result in an incomplete configuration of your Virtual Machine’s buses and the disk devices on those buses.

This happens because, by default, VMware products do not allow the UEFI Shell to be launched by the platform firmware Boot Option and have the Quick Boot option enabled.

These problems can be resolved by setting the correct values for the efi.shell.activeByDefault and efi.quickBoot.enabled parameters. To do so, follow the procedure described in Section 6.8.

Virtual machines created in VMware hypervisors (ESXi, Workstation Pro, Player, Fusion) may not operate as intended until you manually set the parameters listed in the table below.

Depending on your specific configuration, there may be cases where you may not need to set one or more of these parameters. VSI provides this information in case you experience the issues these parameters address.

To set these parameters for a VMware ESXi virtual machine, follow these steps:

To set these parameters for a virtual machine running under any other VMware product, follow these steps:

On KVM/QEMU, only one VirtIO-SCSI adapter can be configured and used on a VSI OpenVMS x86-64 V9.2-x system. Note that this functionality requires QEMU version 6.2 or later.

VSI OpenVMS x86-64 supports VirtualBox, KVM, and VMware virtual machines in OpenVMS clusters. Virtual disks can be shared in a cluster via MSCP. Starting with the E9.2-3 release, VSI OpenVMS x86-64 supports direct (non-MSCP) shared disk access via the VMware VMDirectPath I/O feature (see Section 3.1.3). Cluster common system disks are not supported.

VSI OpenVMS x86-64 was tested in a clustered configuration using V8.4-1H1, V8.4-2, V8.4-2L1, V8.4-2L2, and V8.4-2L3. VSI has tested 2-node and 3-node clusters with MSCP-served disks where appropriate, CLUSTER_CONFIG_LAN.COM, and many relevant SET, SHOW, and SYSMAN commands. Other configurations will be tested at a later date.

Adding a Node Using a Copy of an Existing System Disk

On VSI OpenVMS x86-64 systems, you must perform an additional step if you use a copy of an existing system disk as the initial system disk of a new node that is being added to a cluster.

In addition to tasks such as modifying the SCSNODE and SCSSYSTEMID parameters and changing the label on the new system disk, you must also change the label for the memory disk. Follow these steps: