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.

VSI OpenVMS x86-64 V9.2-1 includes VSI TCP/IP Services X6.0-22. The services listed below are available in X6.0-22. 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-22, please report them to VSI via the VMS Software Service Platform.

With VSI TCP/IP Services X6.0-22, VSI introduces security enhancements for FTPS (FTP over SSL). For details, refer to Appendix B, Security Enhancements for VSI TCP/IP Services X6.0-22 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-1 Installation Guide.

FTP> SET PASSIVE ON
Passive is ON

Currently, a VSI OpenVMS system where an updated version of TCP/IP Services is installed will not receive an updated version of DHCLIENT-SCRIPT.COM, which is a script used by DHCP client.

To work around this issue, perform the following steps after installing VSI OpenVMS V9.2-1:

Using TCPDUMP with more than 6500 buffers specified by the -b option may result in a system crash. This will be addressed in an upcoming operating system update.

Install either VSI DECnet Phase IV or VSI DECnet-Plus on VSI OpenVMS x86-64 V9.2-1 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.

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-1 compared to VSI OpenVMS x86-64 V9.2.

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-1:

During the installation of OpenVMS x86-64 V9.2-1, 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-22 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:

%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 be safely ignored.

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

VSI will address this issue in a future release.

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-1 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-1, use the new V9.2-1_XGI5 cross-tools kit (X86_XTOOLS-V0902-1_XGI5-1.ZIP).

For details on the changes to the cross-tools in the V9.2-1_XGI5 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-1 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 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 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 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 now 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 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-1 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
        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 V9.2-1 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-1 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 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 recommends that any privileged image linked /SYSEXE should be relinked for the V9.2-1 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-1 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 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 MemoryDisk described in Section 2.1.14, “Memory Disks”

New System Crash Dump – Interleaved Dumps

VSI OpenVMS x86-64 V9.2-1 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, 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 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.

In 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 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-1 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

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.

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-1, a container file can only be connected as a shared LD device accessible to multiple architectures as follows:

As of VSI OpenVMS x86-64 V9.2 with the Update V1.0 patch installed and higher, VSI OpenVMS supports the configuration of up to four (4) LSI Logic Parallel SCSI controllers per ESXi virtual machine.

LSI Logic SAS controllers are not supported on ESXi.

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

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.

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

These issues will be addressed in a future release.

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 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. Improvements have been made to the system to improve the efficiency of system memory allocation.

Previously, using FTP/SSL to connect to a system running TCP/IP X6.0 would fail when attempting to use a variety of commands after authenticating the user's username and password. This issue has been fixed in the current release.

When using the TCP/IP 6.0-22 NFS client, entering the command TCPIP MOUNT /SHARE will cause the system to hang.

Until this issue is resolved, VSI recommends restricting the access to the NFS mount commands to privileged users only. This can be done by setting the permissions on the SYS$SHARE:TCPIP$DNFS_MOUNT_SHR.EXE file as follows:

SET SECURITY/PROTECTION=WORLD SYS$SHARE:TCPIP$DNFS_MOUNT_SHR.EXE

The SET FILE/ATTRIBUTES command now 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-1            Platform    Installed
    Destination: DISK$SYSTEM_DISK:[VMS$COMMON.]
VSI X86VMS VMS V9.2-1                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 CHECKSUM command help or the VSI OpenVMS DCL Dictionary: A-M.

VSI OpenVMS x86-64 V9.2-1 includes the 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 provides the Freeware executables for managing ZIP archives on OpenVMS x86-64 systems. In VSI OpenVMS x86-64 V9.2-1, the installation procedure automatically puts these files in the following directories on the system disk:

The DCL command TCPIP SHOW VERSION (/ALL) and TCPIP command SHOW VERSION (/ALL) will indicate an incorrect version when reporting the status of TCP/IP Services.

When using DHCP client to configure interface(s), the information needed for the command SHOW NETWORK to report the TCP/IP network status is not initialized. In this scenario, SHOW NETWORK will display the following:

$ show network

Product:  TCP/IP    Node:  <TCP/IP host/node name not yet available> Address(es):  0.0.0.0

If necessary, the missing information may be obtained with one or more options of the TCPIP SHOW command.

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 unexpected system behavior.

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.

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

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.

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 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 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 2.2.9, “Possible Issues with VMware Virtual Machines”

Recent release of VMware Workstation 17 Player was unable to boot VSI OpenVMS x86-64 V9.2. This issue has been corrected for version V9.2-1.

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:

When upgrading from the previous version of VSI OpenVMS to VSI OpenVMS V9.2-1, make sure that VSI OpenSSH V8.9-1C is not installed on the system. Otherwise, the upgrade procedure will not be completed properly, and the system might not be usable.

On KVM/QEMU, only one VirtIO-SCSI adapter can be configured and used on a VSI OpenVMS x86-64 V9.2-1 system.