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

INSTALL_1: To be installed by all customers.

This installation rating serves as a guide to which customers should apply this remedial kit.

Reference the attached Disclaimer of Warranty and Limitation of Liability Statement.

A reboot is mandated as part of installing this kit, performed automatically following the kit installation.

VSI OpenVMS for the x86 architecture uses a memory disk image, stored on the system disk, when booting the system. The content of the memory disk must remain consistent with the system disk content.

This kit updates the memory disk image and invokes a system reboot sequence (shutdown with reboot) directly as part of the kit installation. You must be prepared to allow the system reboot when installing the kit. After all other kit actions are complete, the system will automatically shutdown and reboot.

If you allow the reboot, you will have the choice of whether to invoke the site-specific shutdown procedure, SYS$MANAGER:SYSHUTDWN.COM during the shutdown portion of the reboot.

By default, after installation completes, the minutes until shutdown is zero. If you wish to leave additional time before the shutdown begins, define the system logical name SHUTDOWN$MINIMUM_MINUTES as the integer value of the wait time in minutes. For example:

 DEFINE/SYSTEM SHUTDOWN$MINIMUM_MINUTES 10

No other options for the shutdown may be specified.

The shutdown will commence directly after the memory disk update as the final portion of the kit installation.

VSI OpenVMS x86-64 V9.2-2

This kit will create a new memory disk image file during PRODUCT INSTALL or PRODUCT UNDO PATCH operations. This file is required for x86 systems bootstrap. If this file cannot be correctly created, the target disk will not be bootable and you will need to restore from backup.

During PRODUCT INSTALL, the kit will check for sufficient space on the target disk. The minimum free space is 600,000 blocks to ensure that the memory disk image file and kit files can safely fit on the disk.

Additionally, a check is made to determine if the disk is too fragmented to correctly create the memory disk file. If either check fails, the installation will be aborted before making any changes. After you take corrective actions the PRODUCT INSTALL can be re-attempted.

These same checks are not automatically handled by the kit before a PRODUCT UNDO PATCH operation. This is not a frequent operation for customer systems. Should you need to remove this kit, you should ensure sufficient disk space before you start. The same 600,000 block minimum applies. To check fragmentation requirements, you can use the following commands:

$ ANALYZE/DISK/EXTENTS/REQUIRED=200000/NOOUTPUT disk
$ SHOW SYMBOL ANALYZE$REQUIRED_EXTENTS

If the symbol value is 25 or more, the disk is too fragmented and you should defragment it before using PRODUCT UNDO PATCH. You can accomplish this using a defragmentation tool or by restoring an image backup.

Problem Description

When mapping large process-based PFN-mapped sections, the process working set may be left in an inconsistent state. When the process logs out, the system could then crash with a DELCONPFN bugcheck.

This issue can often occur when installing large images with the /SHARE=ADDRESS/RESIDENT qualifiers.

The problem is corrected with this patch kit.

Images and/or Files Affected

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

VSI Case Identifier

Jiras SPS-1273, SPS-1285, BO-1473

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Problem Description

Under some circumstances, the SYS$IO_PERFORM[W] system services may incorrectly compute the data buffer address for the I/O operation.

This can result in file corruption or application issues due to reading the wrong data.

The problem is corrected with this patch kit.

Images and/or Files Affected

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

VSI Case Identifier

Jiras SPS-1256, BO-1485

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Problem Description

The SET DUMP/DEVICE command allows the specification of shadow sets as Dump Off System Disk (DOSD) devices and SHOW DUMP will display a dump file found on the shadow set. However, the dump kernel cannot locate the dump file on a shadowed DOSD device.

This change causes SET DUMP/DEVICE to disallow shadow sets as DOSD devices.

Images and/or Files Affected

[SYSEXE]SETSHOWDUMP.EXE

VSI Case Identifier

Jira KT-191

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Workaround

Do not specify shadow sets to SET DUMP/DEVICE.

Problem Description

An error in CLUE$STARTUP failed to end the search for a dump disk if none of the devices specified in the SET DUMP command were mounted at the time CLUE$STARTUP runs during boot.

This could result in an infinite loop within the procedure, and the resulting log file would eventually consume all the space on the system device.

This problem is corrected with this patch kit.

Images and/or Files Affected

[SYS$STARTUP]CLUE$STARTUP.COM

VSI Case Identifier

Jiras KT-188, KT-195

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Workaround

Make sure any DOSD devices are mounted before CLUE$STARTUP runs. Mounting the devices in SYS$STARTUP:SYPAGSWPFILES.COM fulfills this condition.

Problem Description

For a merge-activation of a protected shareable image, the transfer code to relocate the image was incorrectly allocated in P0 space. This can result in an access violation in an inner mode if the P0 address space is deleted or overwritten, causing a process or system crash.

With this patch kit, the transfer code is correctly allocated in a protected area in P1 space, eliminating the risk and potential crash.

Images and/or Files Affected

• [SYS$LDR]SYSTEM_PRIMITIVES_0.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES_0.STB
• [SYS$LDR]SYSTEM_PRIMITIVES_0_MIN.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES_0_MIN.STB
• [SYS$LDR]SYSTEM_PRIMITIVES_2.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES_2.STB
• [SYS$LDR]SYSTEM_PRIMITIVES_2_MIN.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES_2_MIN.STB
• [SYS$LDR]SYSTEM_PRIMITIVES_3.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES_3.STB
• [SYS$LDR]SYSTEM_PRIMITIVES_3_MIN.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES_3_MIN.STB
• [SYS$LDR]SYSTEM_PRIMITIVES_4.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES_4.STB
• [SYS$LDR]SYSTEM_PRIMITIVES_4_MIN.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES_4_MIN.STB
• [SYS$LDR]SYSTEM_PRIMITIVES_6.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES_6.STB
• [SYS$LDR]SYSTEM_PRIMITIVES_6_MIN.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES_6_MIN.STB
• [SYS$LDR]SYSTEM_PRIMITIVES_7.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES_7.STB
• [SYS$LDR]SYSTEM_PRIMITIVES_7_MIN.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES_7_MIN.STB

VSI Case Identifier

Jira BO-1537

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Workaround

Install the protected shareable image with shared address data.

Problem Description

The RUNOFF code uses some special RMS internals to adjust RMS data structures for the files it is processing, for example the NAM fields using the FAB$V_NAM flag.

However, it incorrectly misses a few fields, especially the NAM$L_DEV field, which causes internal structure corruption when run on x86. This would result in XPORT errors and possibly display corrupted file names.

This problem is corrected with this patch kit.

Images and/or Files Affected

• [SYSEXE]DSRINDEX.EXE
• [SYSEXE]DSRTOC.EXE
• [SYSEXE]RUNOFF.EXE

VSI Case Identifier

Jiras BO-1504, SPS-926, SPS-991

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Problem Description

The following issues in the Debugger are corrected with this patch kit:

Images and/or Files Affected

• [SYSLIB]DEBUG.EXE
• [SYSLIB]DEBUGSHR.EXE

VSI Case Identifier

Jiras DEV-1683, DEV-1941, DEV-1967

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Problem Description

ACMS on x86 would encounter various failures, usually resulting in the server process crashing. Even the IVP would fail during product installation.

ACMS uses merge-activation of a protected shareable image. One portion of the structures involved in this mechanism was not correctly made permanent in P1 space. If the space was reused ACMS would encounter spurious failures.

The problem is corrected with this patch kit.

Images and/or Files Affected

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

VSI Case Identifier

Jira BO-1536

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Problem Description

When a system configured as a cluster member boots, the cluster port driver, PEDRIVER, configures on all available LAN devices, including LAN Failover (LL) devices and VLAN (VL) devices.

For x86, a standalone version of LANACP.EXE is run to read the LAN device database and configure LAN Failover and VLAN devices.

An error in the code would only allow configuration of LLA and VLA devices, regardless of the actual device names. If the hardware included other devices, they would not be configured. If the hardware didn't include LLA or VLA, LANACP would attempt to configure the devices as LLA and VLA, resulting in an incorrect and unusable device configuration.

This problem is corrected with this patch kit.

Images and/or Files Affected

• [SYSEXE]LANACP.EXE
• [SYSEXE]LANACP_BFS.EXE

VSI Case Identifier

Jira SPS-1352

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Workaround

This workaround requires redundant cluster communications paths so that cluster communications are not lost during these manual steps:

Problem Description

XA Gateway XaOpen() function failed due to a latent coding error which did not affect other architectures for OpenVMS pre-x86.

Typical errors were like this one displayed by the IVP during kit installation:

IVP fail: failed to call gateway XaOpen function (-3)

This issue is corrected with this patch kit.

Images and/or Files Affected

[SYSEXE]DDTM$XG_SERVER.EXE

VSI Case Identifier

Jira SPS-1271

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Problem Description

The following routines were added to the Object Time System (OTS) to enable packed decimal use required by the BASIC compiler.

These emulate the VAX instructions ADDPx, CMPPx and ASHP.

Images and/or Files Affected

[SYSLIB]LIBOTS2.EXE

VSI Case Identifier

Jiras RTLS-42, RTLS-424, DEV-2015

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Problem Description

The system will crash with an INCONSTATE bugcheck if the Availability Manager (DECamds) connects to an OpenVMS x86 system and displays single process information.

The routine used on x86 to collect process memory information for Availability Manager had an issue which could result in the INCONSTATE system crash.

This has been corrected with this patch kit.

Images and/or Files Affected

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

VSI Case Identifier

Jira AM-221

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Problem Description

When the DTI$SHARE image was installed with shared address data, a bug in the generated code caused an executive mode access violation. This would usually result in an unexpected process termination.

The issue is corrected with this patch kit.

Images and/or Files Affected

[SYSLIB]DTI$SHARE.EXE

VSI Case Identifier

Jiras SPS-1271, BO-1535

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Workaround

Install the DTI$SHARE image without shared address data. On a running system which (by default) already has this image installed, use the command:

$ INSTALL REPLACE SYS$SHARE:DTI$SHARE - /OPEN/HEADER/SHARED=NOADDR/PROTECTED

Problem Description

Under some circumstances, traceback processing could encounter an exception, generating the message:

TRACEBACK - Exception occurred during traceback processing

An example of this occurred when the LSE editor encountered an error and attempted to display a traceback detailing the call stack.

This problem is corrected with this patch kit.

Images and/or Files Affected

[SYSLIB]TRACE.EXE

VSI Case Identifier

Jiras SPS-1339, DEV-2013

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Problem Description

Various modules in the BASIC RTL have been enhanced to enable x86-64 support. This includes support to:

Images and/or Files Affected

[SYSLIB]DEC$BASRTL.EXE

VSI Case Identifier

Jira RTLS-423

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Problem Description

A DCL command procedure with certain syntax errors may result in a supervisor mode DOUBLEDEALO bugcheck, resulting in the deletion of the executing process.

This issue is corrected with this patch kit.

Images and/or Files Affected

[SYSEXE]DCL.EXE

VSI Case Identifier

Jiras SPS-1428, SPS-1429, BO-1541

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Problem Description

An executive mode bugcheck may be declared as fatal or non-fatal. A fatal executive mode bugcheck will crash the entire system. A non-fatal executive mode bugcheck will terminate the offending process.

If the BUGCHECKFATAL system parameter is set to 1, any executive mode bugcheck will cause a system crash (typically, this is used to get a crash dump snapshot of the underlying problem).

An error in the return mechanism from executive mode exception handling could result in a KRNLSTAKNV system crash, even if the BUGCHECKFATAL system parameter was set to 0 and the triggering executive mode bugcheck was declared as non-fatal.

This problem has been corrected with this patch kit.

Images and/or Files Affected

• [SYS$LDR]EXCEPTION.EXE
• [SYS$LDR]EXCEPTION.STB
• [SYS$LDR]EXCEPTION_MON.EXE
• [SYS$LDR]EXCEPTION_MON.STB

VSI Case Identifier

Jiras SPS-1375, SPS-1343

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Problem Description

The linker sometimes reports conflicting attributes for .text sections.

Code sections in object modules should have the SHR attribute. The x86 compilers did not always set this attribute. With some .text sections being SHR and some NOSHR, the linker reports this with a warning. The warnings at link time are propagated into the image.

With this change, the linker silently changes all PSECTS with a name prefix of .text and the EXE attribute to SHR. This way no link time warnings are reported or propagated into the image file due to this condition.

Images and/or Files Affected

[SYSEXE]LINK.EXE

VSI Case Identifier

Jiras DEV-1944, DEV-2019

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Problem Description

Systems under persistent attack could fail to run the CIA database maintenance routine indefinitely. This could result in accumulating expired records over time, with the possibility of introducing transaction timeouts and denial of service. Should the database grow large enough, it could exhaust required resources and halt transaction processing entirely.

To alleviate this condition, a new server thread has been added which runs the CIA database periodic maintenance routine at a selectable interval regardless of attack volume. This guarantees that expired records are removed from the database and avoids the potential issues.

A new system logical name, SYS$CIA_MAINTENANCE_INTERVAL, now allows system managers to set the interval, in minutes, between maintenance runs. The interval can be set based on the attack volume for a system or cluster. The larger the attack volume, the smaller the interval should be to help keep the database and transaction times as small as possible. Intervals can be set from 1 to 60 minutes, with 10 minutes being the default.

For example, to set an interval of 5 minutes, use the command:

$ DEFINE/EXEC/SYSTEM SYS$CIA_MAINTENANCE_INTERVAL 5

Images and/or Files Affected

[SYSEXE]SECURITY_SERVER.EXE

VSI Case Identifier

Jira BO-1506

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Problem Description

The following issues have been corrected in the security server with this patch kit:

Images and/or Files Affected

[SYSEXE]SECURITY_SERVER.EXE

VSI Case Identifier

Jiras BO-1506, BO-1531

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

Problem Description

Some exceptions which should have only deleted the current process mistakenly crashed the system.

This problem is corrected with this patch kit.

Images and/or Files Affected

• [SYS$LDR]EXCEPTION.EXE
• [SYS$LDR]EXCEPTION.STB
• [SYS$LDR]EXCEPTION_MON.EXE
• [SYS$LDR]EXCEPTION_MON.STB

VSI Case Identifier

Jiras BO-1540, SPS-1428

Release Version of VSI OpenVMS That Will Contain This Change

Next VSI OpenVMS x86-64 release after V9.2-2.

This kit is provided for download within a ZIP archive container file.

Info-ZIP's freeware ZIP and UNZIP tools are provided for use on this VSI OpenVMS version. Your site may have already set up symbols for these tools or other equivalent ZIP tools. If not, use the following command to define a symbol to run the UNZIP image:

$ UNZIP == "$SYS$SYSDEVICE:[VMS$COMMON.SYSHLP.UNSUPPORTED.UNZIP]UNZIP"

Then invoke UNZIP to unpack the kit using the command:

$ UNZIP VMS922X_UPDATE-V0200

This will extract the installable PCSI product kit file and its associated signed manifest (_VNC file), used for kit validation during PRODUCT commands.

VSI strongly recommends always using the manifest to validate the kit content during any PRODUCT commands. This will occur automatically if the files are both contained in the same directory.

Install this kit with the POLYCENTER Software Installation Utility by logging into the SYSTEM account, and typing the following at the DCL prompt:

$ PRODUCT INSTALL VMS922X_UPDATE [/SOURCE=location_of_kit]

The kit location may be a CD/DVD or a disk directory that contains the kit. The /SOURCE qualifier is not needed if the PRODUCT INSTALL command is executed from the same directory as the kit location.

This kit requires the use of /RECOVERY_MODE and /SAVE_RECOVERY_DATA and will automatically set them; they do not need to be present on the command line.

The release notes for any kit may be extracted prior to kit installation using the PRODUCT EXTRACT RELEASE_NOTES command.

User-selectable options for installation behavior and scripting are available in this kit, refer to Appendix A, "User-Selectable Control Options and Scripting Considerations" for further details.

Additional help on installing PCSI kits can be found by typing HELP PRODUCT INSTALL at the system prompt.

Should you need to remove this kit via PRODUCT UNDO PATCH, the same mandated reboot requirement is in effect as the memory disk image is changed back to the prior system content.

The kit will update the memory disk image automatically as the final part of installation. There is currently no mechanism within the PCSI utility to cleanly invoke a system reboot for PRODUCT UNDO PATCH.

You will be instructed as the kit exits that you must perform this function manually in this case.

%INSTALL-I-NONRESSHRADR, image installed ignoring '/RESIDENT' image_name
                -INSTALL-E-NOGHREG, insufficient memory in the code or data granularity
                 hint region

%INIT-F-GHREGIONFULL, An allocation was attempted from GH region GH_RES_CODE_S2 but
                there is not enough space in the region for the allocation.

There is not enough space on the memory disk.
                You must take these steps now to complete this installation:
                
                -  Run @SYS$UPDATE:SYS$MD
                -  Reboot the system