V9.2-3 Update V1.0 ECO Kit for VSI OpenVMS x86-64

The DCL command SHOW DEVICE EIx/FULL and the SDA command SHOW LAN both displayed non-specific or confusing device names for EIx devices.

Device names for the E1000 and E1000e devices were always set to 82540, the name of the base Intel 82540 chip. In addition to the base 82540 device, the SYS$EI1000X driver supports several variants: the 82543, 82545, and 82574 devices. This update identifies the variant type, if present.

When a VM has been configured with multiple types of E1000 and E1000e devices, this change makes it easier to differentiate them.

The virtio and VMXNET 3 devices have also been corrected to display the names EI_VIRTIO and EI_VMXNET3. Previously, they used the prefix EV instead of EI.

• [SYS$LDR]IO_ROUTINES.EXE
• [SYS$LDR]IO_ROUTINES.STB
• [SYS$LDR]IO_ROUTINES_MON.EXE
• [SYS$LDR]IO_ROUTINES_MON.STB
• [SYS$LDR]SYS$EVDRIVER.EXE
• [SYS$LDR]SYS$VMXNET3.EXE
• [SYSEXE]SDA.EXE
• [SYSLIB]LAN$SDA.EXE
• [SYSLIB]SDA$SHARE.EXE

Jiras DRIV-464, DRIV-501

The next VSI OpenVMS x86-64 release after V9.2-3.

The suggested workaround for this issue is to use the LANCP command SHOW DEVICE/INTERNAL_COUNTERS device_name to see the actual device name and description.

Several issues existed with the virtio and VMXNET 3 NIC drivers.

For virtio, the driver did not tally the number of resets properly as other network device drivers do.

For VMXNET 3, the driver did not tally link state change interrupts correctly. Also for VMXNET 3, when the driver was first started, there would be a spurious link bounce.

These issues have been corrected with this update.

• [SYS$LDR]SYS$EVDRIVER.EXE
• [SYS$LDR]SYS$VMXNET3.EXE

None.

The next VSI OpenVMS x86-64 release after V9.2-3.

Using LANCP commands to manage a LAN Failover Set was potentially confusing in some areas. There were no issues with LAN Failover operational behavior, just with the management for setup and configuration.

The management usability improvements include:

Another improvement was to allow more flexibility in adding and removing devices from a LAN Failover Set. This reduced the need to disable the failover set before making changes.

The LANCP SET DEVICE/SWITCH command was modified to round-robin through the members of the failover set rather than selecting the first available started device. This allows you to cycle though all failover set members if there are more than two members.

• [SYS$LDR]SYS$LLDRIVER.EXE
• [SYSEXE]LANCP.EXE
• [SYSEXE]LANACP.EXE
• [SYSHLP]LANCP$HELP.HLB

Jiras DRIV 478-486, DRIV-507

The next VSI OpenVMS x86-64 release after V9.2-3.

VLANs on virtio devices were created by associating the VLAN tag with the assigned network. This meant that the virtio driver SYS$EVDRIVER would be assigned to the VLAN network directly and never actually see VLAN tags itself. Rather than creating a VLAN device, a virtio device (EIF, for example) would embody the VLAN tag by virtue of the assigned network.

An attempt to create a VLAN device on a virtio device is not supported and should return an error status.

The VLAN driver and LANCP were updated to address this issue.

LANCP now rejects attempts to create a VLAN device on a NIC that does not support VLANs, such as the virtio device. Rather than failing silently, the following error message is now issued:

Requested VLAN host device not VLAN-capable, VLAN device VLA0

• [SYS$LDR]SYS$VLANDRIVER.EXE
• [SYSEXE]LANCP.EXE
• [SYSEXE]LANACP.EXE
• [SYSHLP]LANCP$HELP.HLB

Jira DRIV-463

The next VSI OpenVMS x86-64 release after V9.2-3.

The MOP messages transmitted every 8-12 minutes include several operating system specific fields. One such field is the O/S name.

This field was displayed as AVMS, a remnant from OpenVMS Alpha.

The MOP messages now correctly display this field as XVMS for VSI OpenVMS x86-64 systems.

• [SYS$LDR]SYS$LAN.EXE
• [SYS$LDR]SYS$LAN_CSMACD.EXE

Jira DRIV-495

The next VSI OpenVMS x86-64 release after V9.2-3.

The following changes have been made to LANCP and LANACP:

• [SYSEXE]LANCP.EXE
• [SYSEXE]LANACP.EXE
• [SYSHLP]LANCP$HELP.HLB

Jiras DRIV-460, DRIV-461, DRIV-465-467, DRIV-469-475, DRIV-512

The next VSI OpenVMS x86-64 release after V9.2-3.

The LAN drivers did not account for jumbo receive buffers properly, resulting in excessive non-paged pool consumption.

This issue has been corrected with this update.

• [SYSEXE]LANCP.EXE
• [SYSEXE]LANACP.EXE
• [SYS$LDR]SYS$LAN.EXE
• [SYS$LDR]SYS$LAN_CSMACD.EXE

Jiras DRIV-487, DRIV-505

The next VSI OpenVMS x86-64 release after V9.2-3.

Treatment of transmit timeout conditions in the SYS$EI1000X driver has been improved.

Treatment of the periodic reset function used in driver qualification has been standardized across the three LAN drivers.

• [SYS$LDR]SYS$EI1000X.EXE
• [SYS$LDR]SYS$EVDRIVER.EXE
• [SYS$LDR]SYS$VMXNET3.EXE

Jiras DRIV-493, DRIV-494

The next VSI OpenVMS x86-64 release after V9.2-3.

SCACP would exit with an error when the SCACP SHOW LAN/SDA, SHOW VC/SDA, or SHOW CHANNEL/SDA commands were issued.

The /SDA qualifier is intended to produce displays similar to the equivalent SDA> PE commands.

This behavior has been corrected with this update. Some other SCACP output display spacing has also been corrected.

• [SYSEXE]SCACP.EXE

Jira BO-1924

Netsuite NS7746

The next VSI OpenVMS x86-64 release after V9.2-3.

This affected VMware OpenVMS VMs that had selected the VMXNET 3 as the NIC type.

Jumbo transmits worked, but no jumbo frames were received.

This issue has been corrected in the SYS$VMXNET3 driver.

Corresponding changes were made to the LAN SDA extension that supports the VMXNET 3 driver.

• [SYS$LDR]SYS$VMXNET3.EXE
• [SYSLIB]LAN$SDA.EXE

Jira DRIV-487

The next VSI OpenVMS x86-64 release after V9.2-3.

Using a LAN Failover device for cluster communications may have limited cluster communication performance.

The default receive size was set to 8 for LAN Failover devices, when it should have been set to 128. Depending on the load, this may have limited performance.

PEDRIVER uses this default receive size as the transmit window size, which determines how many transmits PEDRIVER can issue.

The default size has been corrected to 128 with this update.

• [SYS$LDR]SYS$LLDRIVER.EXE

Jiras BO-1944, DRIV-522

Netsuite NS7748

The next VSI OpenVMS x86-64 release after V9.2-3.

The suggested workaround for this issue is to override the receive window size for cluster communications by issuing the following command for Virtual Circuits (VCs) that have the default window size of 8:

$ MCR SCACP SET VC vcname /WINDOW=TRANSMIT=128

However, this command must be repeated when a VC is created (for example, after a system boots).

KVM VMs using the e1000e NIC (82574) have corrupted jumbo frames if the size is 2049-2053, 4097-4101, 6145-6149, or 8193-8197 bytes. The buffer length reported is 4 bytes shorter than actual.

The problem is due to a KVM hypervisor bug with the 82574 device.

The issue can be corrected by checking for the condition and adjusting the length of the last two buffer segments.

The SYS$EI1000X driver now does this for any e1000 or e1000e (82540, 82545, or 82574) device, although the condition only happens with the 82574 device.

The condition is counted in the LANCP SHOW DEVICE/INTERNAL counters as "CRC workarounds applied".

• [SYS$LDR]SYS$LAN.EXE

Jira DRIV-517

The next VSI OpenVMS x86-64 release after V9.2-3.

For a VLAN device, the "receive bytes" and "multicast receive bytes" counters were counted incorrectly for jumbo packets larger than 2048 bytes.

This issue has been corrected with this update.

• [SYS$LDR]SYS$EI1000X.EXE

None.

The next VSI OpenVMS x86-64 release after V9.2-3.

RMS Changes

If a process owns a lock on a file system resource and another process attempts to acquire an incompatible lock on the same resource, then a blocking AST is delivered to the owning process so it may lower the lock mode to allow the new process to continue.

Under normal circumstances, this happens automatically and the processes will make progress with the locks and file access as needed.

A process in RWMBX resource wait state could own file system locks on files while it was trying to read or write to a mailbox. Should a new process request a lock in this case, the owning process was unable to drop its lock mode since the process could not continue until the resource wait state was satisfied.

To prevent a potential hang, the blocking AST routine has been modified to directly lower the lock mode rather than wait until the RWMBX state clears.

This behavior was discovered by a customer using PIPE to invoke the AUTHORIZE utility as a step in its piped commands. Since each step in the pipe creates a new sub-process and uses mailboxes for communication, it was possible for the PIPE command to cause the process to block against itself. As this entailed a file lock on the system authorization file (SYSUAF), eventually it would cause a system hang for new processes or any other processes trying to access the file.

This behavior has been corrected with this update.

• [SYS$LDR]RMS.EXE
• [SYS$LDR]RMS.STB

Jiras CLUS-38, BO-1900

Netsuite NS7556

The next VSI OpenVMS x86-64 release after V9.2-3.

The RMS V5 ECO kits (VMS842L3I_RMS-V0500 for IA-64 and VMS842L2A_RMS-V0500 for Alpha systems) contained a comprehensive internal status code reorganization to avoid returning a truncated error status on some RMS operations during heavy load.

The equivalent code was updated in VSI OpenVMS x86-64 V9.2.

One particular set of status code condition tests was accidentally missed during that update. In trying to determine whether there was a record locked condition during an RMS $DELETE operation, the missed condition test could in some cases mistakenly signal the following error:

%RMS-E-RLK, target record currently locked by another stream

This issue has been corrected with this update.

• [SYS$LDR]RMS.EXE
• [SYS$LDR]RMS.STB

Jira BO-1945

Netsuite NS7669, NS7935

The next VSI OpenVMS x86-64 release after V9.2-3.

SYS Changes

The PROBE mechanism is a central piece of the ring protection system that OpenVMS uses for hierarchical access to system memory. PROBE checks the accessibility of a starting and ending address based on the caller's mode and the protection mask for read or write access for kernel, executive, supervisor, or user modes.

In VAX, Alpha, and IA-64 architectures, a PROBE instruction is part of the hardware instruction set, providing an efficient mechanism for these tests. In the x86-64 system architecture there is no similar instruction, so the behavior is emulated by system software. This is inherently more expensive overhead for the required functionality.

The original PROBE emulation in VSI OpenVMS x86-64 has been enhanced for better system performance. This consists of improvements in two areas:

• [SYS$LDR]IO_ROUTINES.EXE
• [SYS$LDR]IO_ROUTINES.STB
• [SYS$LDR]IO_ROUTINES_MON.EXE
• [SYS$LDR]IO_ROUTINES_MON.STB
• [SYS$LDR]PROCESS_MANAGEMENT.EXE
• [SYS$LDR]PROCESS_MANAGEMENT.STB
• [SYS$LDR]PROCESS_MANAGEMENT_MON.EXE
• [SYS$LDR]PROCESS_MANAGEMENT_MON.STB
• [SYS$LDR]SYS$VM.EXE
• [SYS$LDR]SYS$VM.STB
• [SYS$LDR]SYS$VM_MON.EXE
• [SYS$LDR]SYS$VM_MON.STB
• [SYS$LDR]SYSGETSYI.EXE
• [SYS$LDR]SYSGETSYI.STB
• [SYS$LDR]SYSTEM_PRIMITIVES.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES.STB
• [SYS$LDR]SYSTEM_PRIMITIVES_MIN.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES_MIN.STB
• [SYSEXE]SYSBOOT.EXE

Jiras BO-1873, BO-1912, BO-1940, QTV-1168

The next VSI OpenVMS x86-64 release after V9.2-3.

On VSI OpenVMS x86-64 virtual machine systems, the MONITOR utility displayed inaccurate data on screens that showed processor mode or CPU usage. Other utilities that gather similar statistics were also affected.

This issue stemmed from the hard tick rate used by the system for accounting purposes. This is a sampling frequency used to collect the relevant data. VM environments were using a 10 msec rate, which is too coarse to differentiate multiple events that can occur during that interval.

The hard tick rate for VMs has been lowered from 10 msec to 1 msec, which is the hard tick rate used on physical machines.

Additionally, some hard tick events for x86-64 systems were being incorrectly counted or discarded. This behavior has been corrected with this update.

For VMs, the MONITOR utility and other utilities that display or gather processor mode or CPU usage now have the same behavior for output as traditional OpenVMS hardware system environments.

• [SYS$LDR]SYSTEM_PRIMITIVES.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES.STB
• [SYS$LDR]SYSTEM_PRIMITIVES_MIN.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES_MIN.STB

Jira BO-1800

The next VSI OpenVMS x86-64 release after V9.2-3.

On systems with at least one virtio-scsi adapter configured, if DEVICE_NAMING was enabled, the dump kernel would trigger an access violation and the dump kernel would then crash during reboot. After reboot, the system would be unable to write a crash dump in case of a system crash.

This was due to an IOGEN routine being called from executive mode during AUTOCONFIGURE when it must be called from kernel mode.

This issue has been corrected with this update.

• [SYSLIB]IOGEN$VIRTIO_CONFIG.EXE

Jira KT-207

The next VSI OpenVMS x86-64 release after V9.2-3.

When a process is adding address space and the process page tables are being updated, the wrong page table entry could be used when setting the window bit for pages that are doubly mapped.

This incorrect status was ignored until the process address space was torn down during process deletion, either from logging out or being terminated with the $DELPRC system service. When the discrepancy was found during process deletion, the system crashed with a DELCONPFN bugcheck.

This issue has been corrected with this update.

• [SYS$LDR]SYS$VM.EXE
• [SYS$LDR]SYS$VM.STB
• [SYS$LDR]SYS$VM_MON.EXE
• [SYS$LDR]SYS$VM_MON.STB

Jira SPS-1273

The next VSI OpenVMS x86-64 release after V9.2-3.

This problem was due to an incorrect buffer length used internally by the $GETDVI system service to retrieve the lock value block that contains the device mount count data. The MOUNTCNT_CLUSTER item returned zero instead of the correct device mount count.

This issue only occurred on x86-64 systems.

This would also affect calls to the $GETDVI system service or LIB$GETDVI from any programs, in addition to the DCL lexical that was reported by a customer.

This issue has been corrected with this update.

• [SYS$LDR]IO_ROUTINES.EXE
• [SYS$LDR]IO_ROUTINES.STB
• [SYS$LDR]IO_ROUTINES_MON.EXE
• [SYS$LDR]IO_ROUTINES_MON.STB

Jira BO-1921

Netsuite NS7715

The next VSI OpenVMS x86-64 release after V9.2-3.

RTL Changes

The system startup did not install the Linker (SYS$SYSTEM:LINK.EXE) or the C++ Run-Time Libraries (SYS$SHARE:LIBCXX.EXE and SYS$SHARE:LIBCXXABI.EXE) as known images.

Installing the images can help improve performance of the Linker and C++ applications.

This change adds the relevant entries to the master list used to determine which files to install as known images during system boot.

You will need to use AUTOGEN to update the system to actually install the images at boot. The boot time list is generated during the GENPARAMS phase of AUTOGEN.

If you wish to install these as known images before the next AUTOGEN and system reboot, you may manually add them yourself for the current incarnation of the system using the following commands:

$ INSTALL ADD SYS$SHARE:LIBCXXABI /OPEN /HEADER /SHARED=ADDRESS_DATA
$ INSTALL ADD SYS$SHARE:LIBCXX    /OPEN /HEADER /SHARED=ADDRESS_DATA
$ INSTALL ADD SYS$SYSTEM:LINK     /OPEN /HEADER /SHARED=ADDRESS_DATA

• [SYSMGR]VMS$IMAGES_MASTER.DAT

Jira BO-1898, BO-1899

The next VSI OpenVMS x86-64 release after V9.2-3.

The NUM and NUM1 functions in the BASIC language convert a number to a text representation. If these functions were called with a quadword integer value to convert, they would signal the following error:

%BAS-F-NOTIMP, Not implemented

For most programs, this would terminate the image.

The port from IA-64 to x86-64 for the conversion routine had not yet been completed.

The issue has been addressed with this ECO kit.

• [SYSLIB]DEC$BASRTL.EXE

Jira RTLS-509

The next VSI OpenVMS x86-64 release after V9.2-3.

For a program written in Pascal, when an open file allocated in a routine is not explicitly closed, the Pascal Run-Time Library routine PAS$CLOSE_LOCAL is called to close those files automatically at the end of the routine, or during an unwind or non-local GOTO operation.

The PAS$CLOSE_LOCAL routine needs platform-specific knowledge about the stack layout to find file variables. This code had not been completely ported from IA-64 to x86-64.

The issue has been corrected with this update.

• [SYSLIB]PAS$RTL.EXE

Jira RTLS-516

The next VSI OpenVMS x86-64 release after V9.2-3.

DEBUG Changes

The following corrections and improvements have been made to the Debugger with this ECO kit:

• [SYSLIB]DBG$HA_KERNEL.EXE
• [SYSLIB]DBG$HA_MAIN.EXE
• [SYSLIB]DEBUG.EXE
• [SYSLIB]DEBUGSHR.EXE
• [SYSLIB]DEBUGUISHR.EXE

Jira DEV-2492, DEV-2631, DEV-2674, DEV-2737, DEV-2752, DEV-2828, DEV-2837, DEV-2846, DEV-2856, DEV-2876, DEV-2881

The next VSI OpenVMS x86-64 release after V9.2-3.

ACME Changes

Various bug fixes have been made to the VMS ACME agent for ACME logins. The following problems have been corrected:

• [SYSLIB]VMS$VMS_ACMESHR.EXE

Jira BO-1849, BO-1856, BO-1859, BO-1901, BO-1907, BO-1920

The next VSI OpenVMS x86-64 release after V9.2-3.

For debugging purposes, the ACME server has tracing code that can be enabled when needed. This tracing has been modified to set the trace flag for the following control mode phases:

• AGENT_INITIALIZE
• AGENT_STARTUP
• AGENT_SHUTDOWN
• AGENT_STANDBY

• [SYSEXE]ACME_SERVER.EXE

Jira BO-1737

The next VSI OpenVMS x86-64 release after V9.2-3.

When using ACME login on VSI OpenVMS x86-64, attempting to capture the output of a SET PASSWORD/GENERATE command within a DCL command procedure fails with the following error:

%STR-F-ILLSTRCLA, illegal string class

This issue has been corrected with this update.

• [SYSEXE]SETP0_ACME.EXE

Jira UT-314

The next VSI OpenVMS x86-64 release after V9.2-3.

The installation requirements for the ACME LDAP Agent are different on VSI OpenVMS x86-64 from previous VSI OpenVMS platforms.

The ACME LDAP configuration and installation document has been updated to include additional details for x86-64, as well as a general cleanup of content, images, and formatting.

The PDF and TXT versions of the document are placed in SYS$HELP.

• [SYSHLP]ACMELDAP_STD_CONFIG_INSTALL.TXT
• [SYSHLP]ACMELDAP_STD_CONFIG_INSTALL.PDF

Jira BO-1874

The next VSI OpenVMS x86-64 release after V9.2-3.

Security Server Changes

The VSI OpenVMS x86-64 security server could generate improperly formatted suspect records for certain DECnet connections and insert them into the intrusion database.

Should this occur in a VMScluster, Alpha or IA-64 cluster members could then experience security server failures triggered by the improper records.

The security server now correctly formats these suspect records.

In addition, the security server now includes a self-healing check that removes any improper records from the intrusion database.

• [SYSEXE]SECURITY_SERVER.EXE

Jira BO-1908

The next VSI OpenVMS x86-64 release after V9.2-3.

The security server includes an exception handler to determine what actions to take if an unexpected error or exception occurs. Usually, this will lead to the handler restarting the server.

In some cases, the exception handler could terminate before completing the restart process. This would leave the server in a non-responsive "zombie" state that required a system reboot to clear.

The security server has been modified to reorder recovery steps and limit the use of certain services during exception handling to avoid cascading exception failures. This ensures completion of the restart process and proper image cleanup.

• [SYSEXE]SECURITY_SERVER.EXE

Jira BO-1998

The next VSI OpenVMS x86-64 release after V9.2-3.

Miscellaneous Changes

Several items displayed by the SEARCH/STATISTICS command were tallied in longword (32-bit) counters. The fields would overflow and restart at zero if there were more than 4,294,967,295 records or characters in the file or files being searched, which is easily possible for very large files. Should the field overflow, the output display was incorrect.

The following fields are now tallied in quadword (64-bit) counters to prevent overflow:

• Records searched
• Characters searched
• Records matched
• Lines printed

To accommodate displaying potentially large values for these items, the output format of the statistics summary has changed, with wider field sizes where needed. The same items are displayed in the same order. The displays for Elapsed Time and CPU Time now include the leading digits for the number of days, should the search take that long to complete.

Here is an example showing the new format for the output display:

Files searched:                   9123       Buffered I/O count:        34060
Records searched:             63172133       Direct I/O count:          62142
Characters searched:        2819025795       Page faults:                  17
Records matched:                  2524       Elapsed CPU time:  0 00:02:56.10
Lines printed:                    4180       Elapsed time:      0 00:07:58.89

By default, SEARCH/STATISTICS also creates DCL symbols for some of the metrics calculated. These are defined in the local symbol table as character strings, so they will not overflow for large numeric values. Since DCL only supports 32-bit arithmetic, large values cannot be directly converted to integers for additional processing, but would need to use a program or utility that does provide 64-bit arithmetic. However, DCL procedures may use the character symbols for reporting purposes or to create a comma separated list for input to a spreadsheet program, for example.

New symbols are now created for the Elapsed Time and CPU Time values, so this information may also be captured by DCL command procedures without the need to parse the command display output. The two new time symbols are created in DCL Delta Time format, so they may be used directly for DCL time calculations.

Here are the DCL symbols generated by the example SEARCH/STATISTICS display output above:

SEARCH$CHARACTERS_SEARCHED = "2819025795"
SEARCH$CPU_TIME = "0-00:02:56.10"
SEARCH$ELAPSED_TIME = "0-00:07:58.89"
SEARCH$FILES_SEARCHED = "9123"
SEARCH$LINES_PRINTED = "4180"
SEARCH$RECORDS_MATCHED = "2524"
SEARCH$RECORDS_SEARCHED = "63172133"

• [SYSEXE]SEARCH.EXE
• [SYSMSG]CLIUTLMSG.EXE

Jiras UT-319, UT-326

The next VSI OpenVMS x86-64 release after V9.2-3.

The following changes were made to the MACRO compiler:

The version of the compiler can be shown using the MACRO/VERSION command:

$ MACRO/VERSION
XMAC V6.0-117 (GEM 50Y4T) on OpenVMS x86_64 V9.2-3

• [SYSEXE]MACRO.EXE

Jiras DEV-2688, DEV-2703, DEV-2624, DEV-2788

The next VSI OpenVMS x86-64 release after V9.2-3.

On VSI OpenVMS V9.2-3, the Linker sometimes reports the following warning:

%ILINK-W-DRELOSYM, debug relocation for undefined symbol

When linking an image with code in P2 space (the default) and using the /DEBUG qualifier, the Linker would sometimes fail to find a symbol referenced in the debug information. The above warning message would be displayed along with some additional information.

The generated image was not affected in the sense that it can be run and works as expected. If run with the Debugger, the Debugger may report or display messages if it attempts to access the particular symbol referenced in the DRELOSYM message.

This issue has been corrected with this update.

• [SYSEXE]LINK.EXE

Jira BO-1895

The next VSI OpenVMS x86-64 release after V9.2-3.

The SDA command CLUE XQP/LOCK=lockbasis displays lock and resource information, but previously would only display the lower 32 bits of the RSB address.

The command now correctly displays the entire 64 bit RSB address.

• [SYSLIB]CLUE$SDA.EXE

Jira UT-308

The next VSI OpenVMS x86-64 release after V9.2-3.