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.

With the VM system in client mode, use the following syntax: \\.\pipe_xxx

With the management system in server mode, use the following syntax: \\.\pipe_xxx, where xxx is a unique string for each VM.

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.

The current version of VSI TCP/IP Services for OpenVMS uses the BIND 9.11.37 Server.

Using Bind 9.11.37 is documented in the VSI TCP/IP Services for OpenVMS Management manual. VSI also recommends that users refer to the Internet Systems Consortium (ISC) website for the latest updates to Bind 9 configurations and resources.

Install either VSI DECnet Phase IV or VSI DECnet-Plus on VSI OpenVMS x86-64 V9.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 now provides an empty file NET$CONFIG.DAT before installing the DECnet-Plus kit.

VSI OpenVMS x86-64 V9.2 includes VSI TCP/IP Services X6.0-16. The following services are available in X6.0-16. Note that many of these services are yet to be qualified by VSI, however based on the testing done so far, they are ready for initial external testing. If you encounter any issues using VSI TCP/IP Services X6.0-16, please report them to VSI via the VMS Software Service Platform.

With VSI TCP/IP Services X6.0-16, VSI introduces security enhancements for FTPS (FTP over SSL). For details, refer to Appendix B, Security Enhancements for VSI TCP/IP Services X6.0-16 FTPS of this document.

Before starting VSI TCP/IP Services, you must run the TCPIP$CONFIG configuration procedure. To start TCPIP$CONFIG, enter the following command:

$ @SYS$MANAGER:TCPIP$CONFIG.COM

To start the network stack after configuring it, enter the following command:

$ @SYS$STARTUP:TCPIP$STARTUP.COM

For detailed information on running the TCPIP$CONFIG configuration procedure, refer to the VSI TCP/IP Services for OpenVMS Installation and Configuration manual.

For a configuration example for FTP and TELNET, refer to the VSI OpenVMS x86-64 V9.2 Installation Guide.

FTP> SET PASSIVE ON
Passive is ON

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.

The notes in this section describe features that are new in VSI OpenVMS x86-64 V9.2 compared to VSI OpenVMS x86-64 E9.2 (the field test version).

$ SET FILE/ATTRIBUTES=CBT

$ SET FILE/ATTRIBUTES=NOCBT

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

$ product show product/options=extended_display *vms
------------------------------------ ----------- ---------
PRODUCT                              KIT TYPE    STATE
------------------------------------ ----------- ---------
VSI X86VMS OPENVMS V9.2              Platform    Installed
    Destination: DISK$SYSTEM_DISK:[VMS$COMMON.]
VSI X86VMS VMS V9.2                  Oper System Installed
    Destination: DISK$SYSTEM_DISK:[VMS$COMMON.]
------------------------------------ ----------- ---------
2 items found

int sys$get_entropy(void * buffer, unsigned __int64 buflen);

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

During the installation of OpenVMS x86-64 V9.2, 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 X6.0-16 requires a system reboot.
Can the system be REBOOTED after the installation completes? [YES]

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

Later in the installation, you will see the following messages, which may be safely ignored:

%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 the system reboot message twice.

VSI will address this issue in a future release.

AUTOGEN issues a warning message during the AUTOGEN Boot portion of the OpenVMS system installation. This message may be safely ignored. The problem will be fixed in a future release of VSI OpenVMS x86-64.

******************
%AUTOGEN-W-REPORT, Warnings were detected by AUTOGEN. Please review the
        information given in the file SYS$SYSTEM:AGEN$PARAMS.REPORT
******************

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 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 INITIALIZE and MOUNT/BIND commands.

With VSI OpenVMS x86-64 V9.2, use the new V9.2-XG9N cross-tools kit (VSI-I64VMS-X86_XTOOLS-V0902-XG9N-1.ZIP).

For details on the changes to the cross-tools in the V9.2-XG9N kit, refer to the release notes bundled with the kit. Before the cross-tools kit installation, the release notes file can be extracted from the PCSI kit with the following command:

$ product extract release_notes x86_xtools /log [/source=ddcu:[dir]]

Refer to the VSI OpenVMS x86-64 Cross-Tools Kit Installation and Startup Guide for complete information on installing the cross-tools kit.

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

This issue will be fixed in a future update for previous VSI OpenVMS versions.

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.

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, which is 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, which 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 now 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 porting an application from IA64 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 IA64, the compiler may generate short data, which is accessed in an efficient way. The IA64 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 can not 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 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, since 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

X86VMS$DKA0:[VMS$COMMON.SYS$LDR]SYS$MD.DSK;3 created (158451 blocks in 1 LBN range),
        mounted on X86VMS$LDM2: (volume label SYS$MD20133C) with 25013 free blocks,
        containing OpenVMS V9.2.

$

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

$ purge sys$loadable_images:sys$md.dsk

VSI OpenVMS x86-64 V9.2 supports VirtualBox, KVM, and VMware virtual machines in OpenVMS clusters. However, shared disk access on virtual machines is not supported. Note that this means no shared data disks or cluster common system disks.

VSI OpenVMS x86-64 V9.2 has been 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:

VSI OpenVMS x86-64 will 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 V9.2 release, the SYSGEN INSTALL command no longer supports 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 recommends that any privileged image linked /SYSEXE should be relinked for the V9.2 release because data structures and interfaces are subject to change for each new version.

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.

When you run a VSI OpenVMS x86-64 image on VSI OpenVMS Integrity, 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.

VSI OpenVMS x86-64 V9.2 supports a maximum of 32 CPUs.

If you increase the number of CPUs in your virtual machine configuration, you will see messages like the following during system startup:

%SMP-I-CPUTRN, CPU #2 has joined the active set.
%SMP-I-CPUTRN, CPU #1 has joined the active set.
%SMP-I-CPUTRN, CPU #3 has joined the active set.

Once VSI OpenVMS x86-64 is up and running, the DCL command SHOW CPU will reflect your CPU count. For example:

$ show cpu
System: X86VMS, VBOX   VBOXFACP
CPU ownership sets:
   Active           0-3
   Configure        0-3
CPU state sets:
   Potential        0-3
   Autostart        0-3
   Powered Down     None
   Not Present      None
   Hard Excluded    None
   Failover         None
$

The DCL command STOP/CPU n will remove a CPU from the set of CPUs being used. For example:

$ stop/cpu 3
%SMP-I-CPUTRN, CPU #3 was removed from the active set.
$

The DCL command START/CPU n will add a CPU to the set of CPUs being used. For example:

$ start/cpu 3
%SMP-I-CPUTRN, CPU #3 has joined the active set.
$

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 supports a single system crash dump of the compressed selective format. Bits 0 and 3 in the system parameter DUMPSTYLE must both be set. The value 9 is the default setting.

VSI OpenVMS x86-64 system crash dumps are written using a minimal VMS environment called the dump kernel. All the files used by the dump kernel are included in the MemoryDisk, described in Section 2.1.14, “Memory Disks” of this document.

Dump Off System Disk

Crash dumps can be written to the system disk or to an alternate disk designated for the 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 following example that specifies DKA100: as the desired dump device.

You can confirm the setting using the SHOW DUMP_OPTIONS command.

The change is effective immediately, without requiring a reboot.

System Dump Analysis

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

System Service Intercept (SSI) is available on VSI OpenVMS x86-64. SSI enables system services to be intercepted and user-specified code to run before, after, or instead of the intercepted system service.

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

VSI OpenVMS x86-64 V9.2 includes support for VAX floating point format in most of the system-supplied libraries. However, there are some known issues that will be resolved in a future update. These include the inability to print VAX floating point values from C applications and missing support for VAX floating point in the current Fortran cross-compiler.

In VSI OpenVMS x86-64 V9.2, 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 Pthread debugger command threads -o u, which 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
SDA>

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 now 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

Additional fields have been added to these structures. Fields added to the WCB structure, in particular, are not compatible with those in previous versions of OpenVMS due to the layout of the structure. You must recompile and relink any images that access these structures to include these changes.

The file and volume major version in SYS$BASE_IMAGE.EXE has been incremented to reflect these changes.

If you activate an image that has not been recompiled and relinked, the system displays the following error message:

         %SYSTEM-W-SYSVERDIF, system version mismatch; please relink

VSI OpenVMS I/O User’s Reference Manual documents the file access control flag FIB$V_NOLOCK. This flag allows a privileged user to open a file even if another user has locked that file against all other access. However, VSI OpenVMS x86-64 V9.2 adds the restriction that FIB$V_NOLOCK is only allowed on a read-only access basis. This means that the FIB$V_WRITE flag must be clear (along with the FIB$V_NOREAD and FIB$V_NOWRITE flags). Attempting to access a file with both FIB$V_NOLOCK set and FIB$V_WRITE set will result in the following error:

SYSTEM-F-BADPARAM, bad parameter value

FIB$V_NOLOCK is not used by most applications, but this restriction may affect disk maintenance utilities such as defragmenters.

You cannot run the DHCP and the failSAFE IP client on the same NIC on VSI TCP/IP Services for OpenVMS X6.x. If a customer is running the DHCP client on a NIC, then failSAFE IP should not be configured on this NIC. Since the assigned address is actually controlled by DHCP, VSI TCP/IP Services for OpenVMS should not reassign this address. If a customer needs to run the DHCP client and provide a failover mechanism, they should configure the NIC in a lan failover set.

When using SFTP or SCP with the default options, you may occasionally see an ASTFLT message followed by a stack dump.

The ASTFLT only happens when the progress meter is shown, which is the default. To avoid this problem, we recommend using the quiet switch (-q), so that the progress meter is not shown.

This problem will be addressed in a future version of OpenVMS.

User-written x86-assembler code must follow the VSI OpenVMS calling standard (see the VSI OpenVMS Calling Standard manual, chapter "OpenVMS x86-64 Conventions") 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

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

LSI Logic SAS controllers are not supported on ESXi due to a shared interrupt issue between one emulated LSI Logic SAS controller and another non-LSI Logic SAS controller on the PCI bus.

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 V9.2. 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 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.

VSI may implement minimal installation for OpenVMS x86-64 in a future release.

Running the minicopy procedure using HBMM convertible bitmaps will result in a system crash on VSI OpenVMS x86-64 V9.2. However, running this procedure using traditional minicopy bitmaps will not result in a crash. If you want to take advantage of quicker minicopy (as opposed to full copy), please ensure that you are using traditional minicopy bitmaps following the dismount of a shadow set member.

To verify that HBMM convertible bitmaps are not in use, follow these steps:

This issue will be fixed in a future patch kit.

Recently, an issue was discovered when using file and page file backed writable global sections. The issue can result in an INCONMMGT or PGFIPLHI system crash. A fix for this issue is expected to be available shortly after the release of VSI OpenVMS x86-64 V9.2. If you experience a system crash, you are encouraged to report the problem and provide the dump for analysis.

When connecting to a logical tape, you will get the following error:

$ LM CONNECT tape.tap LMA1:
%LM-F-INVGEOMETRY, Invalid geometry specified

Despite what the error message says, this is not a geometry issue, but a lock-related error that appears when the container is opened.

Because of this, logical tapes are not supported on VSI OpenVMS x86-64 V9.2.

A fix for this issue is expected to be available shortly after the release of VSI OpenVMS x86-64 V9.2.

The TRACEBACK facility sometimes prints an extra message such as the RMS-S-STALL message in the example below. The error is not real and can be safely ignored.

$ run cnf_check3 OK AB OK %RMS-S-STALL, synchronize with operation completion
%PAS-F-OPNDASSCOM, operands are not assignment compatible %TRACE-F-TRACEBACK, symbolic stack
dump follows image module routine line rel PC abs PC

Under certain conditions, if an MSCP serving node goes away and a device on a client node comes out of Mount Verification, the client system may crash.

This issue will be addressed in a future release.

Below is the list of known C Run-Time Library issues in VSI OpenVMS x86-64 V9.2:

These issues will be addressed in a future release.

Applications that are linked against the pthreads library may crash because of an access violation occurring in the pthreads code. This issue is under investigation and will be fixed in a future update.

The following lines in the TCPIP$BIND_CONF.TEMPLATE_FORWARD template file set up the forwarders' addresses and the DNSSEC validation:

//Specifies the IP addresses to be used for forwarding.
//The default is the empty list (no forwarding).
forwarders {
    8.8.8.8;
    8.8.4.4;
};
 
dnssec-validation auto; //Enable DNSSEC validation.
                        //Note dnssec-enable also needs to be set to
                        //yes to be effective. The default is yes.

However, if forwarders are changed to DNS servers that do not support DNSSEC or have it disabled, DNS lookup replies will be discarded when the DNSSEC validation fails.

To avoid this, please comment out the line of dnssec-validation auto.

NTPDATE is no longer supported and will be removed from an upcoming release of VSI TCP/IP Services. To perform the equivalent of NTPDATE, run NTPD making use of the -q and "-G" options.

$ ntpd :== $tcpip$ntp 
$ ntpd "-G" -q
ntp.exe[538969120]: ntpd 4.2.8p15@1.3728 Fri Sep 22 07:00:58 UTC 2020 (2): Starting
ntp.exe[538969120]: Command line: tbd$dka200:[sys0.syscommon.][sysexe]tcpip$ntp.exe -G -q -4
ntp.exe[538969120]: ----------------------------------------------------
ntp.exe[538969120]: ntp-4 is maintained by Network Time Foundation,
ntp.exe[538969120]: Inc. (NTF), a non-profit 501(c)(3) public-benefit
ntp.exe[538969120]: corporation.  Support and training for ntp-4 are
ntp.exe[538969120]: available at https://www.nwtime.org/support
ntp.exe[538969120]: ----------------------------------------------------
ntp.exe[538969120]: proto: precision = 1000.000 usec (-10)
ntp.exe[538969120]: proto: fuzz beneath 0.710 usec
ntp.exe[538969120]: basedate set to 2022-05-21
ntp.exe[538969120]: gps base set to 2022-05-22 (week 2211)
ntp.exe[538969120]: Listen and drop on 0 v4wildcard 0.0.0.0:123
ntp.exe[538969120]: Listen normally on 1 LO0 127.0.0.1:123
ntp.exe[538969120]: Listen normally on 2 WE0 10.10.116.182:123
ntp.exe[538969120]: Listening on routing socket on fd #4 for interface updates
ntp.exe[538969120]: ntpd: time set -50.590756 s
ntpd: time set -50.590756s
$

The TCPIP service XDM fails to start due to a version mismatch of a library against which it is built. The following error message will appear in SYS$SPECIFIC:[TCPIP$XDM]TCPIP$XDM_RUN.LOG:

%DCL-W-ACTIMAGE, error activating image DECW$XLIBSHR
-CLI-E-IMGNAME, image file X86VMS$DKA0:[SYS0.SYSCOMMON.][SYSLIB]DECW$XLIBSHR.EXE
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

This issue will be addressed in an upcoming release of VSI TCP/IP Services.

VSI OpenVMS x86-64 may not correctly maintain the time of day in virtual machine environments after certain events. To keep the time of day accurate, the system manager may need to issue a SET TIME command after booting, suspending, taking a snapshot of a virtual machine, or any other similar events, depending on the virtual machine host. This will be addressed in a future release of VSI OpenVMS x86-64.

Host systems running Windows 10 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 10 host system:

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

For more information about the CPU feature checks, see Section 1.5, “CPU Compatibility Checks for Virtual Machines” in the Before You Start… Read These First 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, in turn, can significantly impact the performance of your VMware virtual machine.

Furthermore, proceeding to boot from such display will often result in an incorrect output on the serial console connection, requiring a reset of your terminal emulator's terminal settings.

To avoid this, proceed as follows (instead of booting):