VSI OpenVMS does not support thin-provisioned volumes on any architecture. Attempting to use thin-provisioned virtual disks may result in loss or corruption of data on the device. VSI currently has no plans to add thin provisioning support on any architecture.

When creating new virtual volumes for VSI OpenVMS, do not enable thin provisioning, even if the hypervisor that you are using supports it.

Note that HPE OpenVMS versions do support thin provisioning. If you are currently using a thin-provisioned disk on your HPE OpenVMS system and you are planning to upgrade to VSI OpenVMS, you must change the provisioning of your virtual disk to thick provisioning.

For information on changing the provisioning of a virtual disk, refer to VMware documentation.

If you have any further questions, please contact VSI support via <support@vmssoftware.com>.

Use this procedure to run VMware vSphere Hypervisor on an ESXi server with a basic license (not Enterprise or Enterprise Plus). You must use serial ports within the same ESX server.

Using the named pipe functionality, map COM1/OPA0: on the VMS virtual machine to a pipe on a management server on which a terminal emulator is installed.

\\.\pipe_name

\\.\pipe_name

The terminal emulator should be set for serial connection at 115200 baud.

The two figures below show how to set up pipes for a local terminal-emulator-based console.

The two figures below show how to set up pipes between two local virtual machines where one plays the role of VMS console. This could be a virtual machine guest running any OS that supports a terminal emulator.

Install either VSI DECnet Phase IV or VSI DECnet-Plus on VSI OpenVMS x86-64 V9.2-2 and then configure the product you have chosen, just as you would for an OpenVMS Alpha or OpenVMS Integrity release.

If you have DECnet Phase IV installed on your system and you want to use DECnet-Plus, you have to uninstall DECnet Phase IV and then install and configure DECnet-Plus.

$ @SYS$UPDATE:SYS$MD.COM

$ PURGE SYS$LOADABLE_IMAGES:SYS$MD.DSK

The OpenVMS x86-64 installation procedure provides an empty file NET$CONFIG.DAT before installing the DECnet-Plus kit.

To understand how to configure your virtual machine network (devices and network configuration), please consult the VirtualBox, KVM, and VMware documentation. Some configurations may be incompatible with the operation of OpenVMS applications. For example, configuring a bridged adapter with a MacVTap device may inhibit the MAC address change done by DECnet, and configuring DECnet on VirtualBox may require allowing promiscuous mode on the NIC.

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.

Previously, the linking process for some of the C++ object files with templates (group sections) would fail with an ACCVIO error in the linker code. This issue has been fixed in the current release.

Previously, there was a possibility that the OpenVMS Librarian utility would fail to insert C++ object modules into an object library (.OLB) file, displaying the error:

%LIBRAR-F-INSERTERR, error inserting <module-name> in <library-name>

This issue has been fixed in 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.

Сurrently, the SET DUMP_OPTIONS/DEVICE command allows you to set non-system shadowed disks as target devices for writing the system dump information in case of a system crash. However, if you do so, the dump kernel will not be able to locate the dump file after a crash, and the system dump information will not be written.

Note that this restriction only applies to non-system shadowed disks. The dump kernel can successfully write dumps to a shadowed system disk. In a future patch kit, the SET DUMP_OPTIONS/DEVICE will be reworked to not accept non-system shadowed disks as dump targets.

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

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.

Before upgrading to VSI OpenVMS V9.2-2, 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.

Any attempt to assign an existing default proxy record as non-default in a network proxy database where the proxy thread is running will render the Security Server unresponsive.

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

When mounting MSCP-served disks during system startup, it may take the system some time to bring all the devices online. To determine whether a device has been configured and therefore can be mounted, VSI suggests using the lexical function F$GETDVI(<disk-name>, "EXISTS") where <disk-name> is the name of the device that you wish to mount. This function should be included in a loop with a short wait between checks and a limit on the number of times through the loop (to skip devices that do not appear in a reasonable amount of time). Once the device has been confirmed to exist, it can be mounted as part of the same script.

Previously, in a cluster with x86-64 nodes running VSI OpenVMS x86-64 V9.2-x and Alpha or Integrity nodes running previous versions of OpenVMS, the SHOW LICENSE/CLUSTER/CHARGE command run from a non-x86-64 node would display the existing x86-64 nodes but would not display the license charge information for x86-64 systems.

This issue has been fixed in the following patch kits:

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 V9.2-2 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 V9.2-2, 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 V6.0-23 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

These messages may safely be ignored.

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

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 3.3.8, “Memory Disks”.

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 V9.2-1, 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 Chapter 13 of 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 V9.2-2 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 V9.2-2 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-2 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.

See Appendix A, VSI C Run-Time Library (C RTL) Notes of this document for more detailed information.

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 1.4, “CPU Compatibility Checks for Virtual Machines” in the Chapter 1, Read These Before You Start 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 3.4.8, “Possible Issues with VMware Virtual Machines”.

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.