VSI OpenVMS x86-64 V9.2-2 Update V2

Copying very large disk files (4GB or larger) on VSI OpenVMS x86-64 may lead to the disk entering mount verification. Depending on the circumstances, the verification may never complete and the disk may suffer a mount verification timeout. Such a case would necessitate a DISMOUNT/ABORT or a reboot to recover access to the disk.

The disk controller requires that buffers used for transfers do not cross any 4GB boundary. When creating the scatter-gather map to describe the memory buffers to use, the disk driver incorrectly calculated the byte counts for the pieces which were split over such a boundary. The resulting error returned from the disk would trigger the mount verification event.

[SYS$LDR]SYS$PKMDRIVER.EXE

Jiras SPS-1427, DRIV-404

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

Copying very large disk files (4GB or larger) on VSI OpenVMS x86-64 may lead to the disk entering mount verification. Depending on the circumstances, the verification may never complete and the disk may suffer a mount verification timeout. Such a case would necessitate a DISMOUNT/ABORT or a reboot to recover access to the disk.

This problem is very similar to that described above in Section 5.1. In this case for SATA disks, the driver correctly handled transfers which crossed a 4GB boundary. However, it incorrectly created an additional scatter-gather list entry for a segment of a buffer that was immediately before a 4GB boundary but did not cross the 4GB boundary. The resulting error returned from the disk would trigger the mount verification event.

[SYS$LDR]SYS$PKDDRIVER.EXE

Jira DRIV-371

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

The AUTOGEN computation of the MPW_WAITLIMIT system parameter now calculates an increased value. A larger value will reduce the possibility of processes being placed in a resource wait state (RWMPB) when the modified page list must be flushed to the page file.

[SYSUPD]AUTOGEN.COM

Jira BO-1417

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

There are a number of system parameters that control allocation of system structures which must reside in 32-bit S0/S1 address space. The total of S0/S1 address space cannot exceed 2GB.

If the total of these S0/S1 parameters should exceed 2GB of address space, that would exhaust the available 32-bit memory and the system would fail to boot.

AUTOGEN will now recognize and report an error if the relevant system parameters will exhaust the available 32-bit space. The computation is not exact as there are some aspects of memory usage that AUTOGEN cannot determine.

If AUTOGEN calculates that the system 32-bit address space will be exhausted using the current parameter values, an error message and additional informational messages are generated to provide guidance for the system manager to adjust them using MODPARAMS.DAT.

AUTOGEN will provide a list of the parameters and their sizes when reporting the message. An example of the error message and presented data is:

%AUTOGEN-E-EXH_S0S1 - The generated parameters will exhaust S0S1 space.

The generated parameters will result in a system that will not boot.
The following parameters consume 2399.85MB of S0S1 space of which there
is only 2GB (2048MB) available.  You should review records pertaining to
the following parameters in MODPARAMS.DAT:

      PAGEDYN            579724288 Bytes    552.87 MB
      NPAGEVIR          1879048192 Bytes   1792.00 MB
      GH_EXEC_DATA            2048 Pages     16.00 MB
      GH_RES_CODE             3072 Pages     24.00 MB
      GH_RES_DATA              512 Pages      4.00 MB
      GH_RO_EXEC_S0           1024 Pages      8.00 MB
      GH_RO_RES_S0            1024 Pages      8.00 MB

[SYSUPD]AUTOGEN.COM

Jira UT-220

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

Update MODPARAMS.DAT to reduce the size of the parameters which contribute to the 32-bit address space.

The SYSMWCNT system parameter specifies the size of the pageable portion of the system working set. On X86, none of system space is pageable.

If a large value for this parameter is computed by AUTOGEN and used during system operation, it could impact the ability of the system to generate a valid system crash dump file during a system crash.

AUTOGEN will no longer calculate a large value for the SYSMWCNT parameter.

The next release of VSI OpenVMS x86-64 will remove references to SYSMWCNT from the system and make the SYSMWCNT system parameter obsolete.

[SYSUPD]AUTOGEN.COM

Jira BO-1527

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

Limit the size of the SYSMWCNT system parameter by adding this line to MODPARAMS.DAT:

MAX_SYSMWCNT=8192

The system will fail to boot if the error log system parameters (ERRORLOGBUFFERS and ERLBUFFERPAGES) are larger than the S2 error log system parameters (ERRORLOGBUFF_S2 and ERLBUFFERPAG_S2).

AUTOGEN has been updated to insure the generated ERRORLOGBUFF_S2 and ERLBUFFERPAG_S2 parameters are at least as large as the ERRORLOGBUFFERS and ERLBUFFERPAGES parameters.

The next release of VSI OpenVMS x86-64 will correct the issue and allow the system to successfully boot regardless of any differences in these parameters.

[SYSUPD]AUTOGEN.COM

Jiras SPS-1419, BO-1542

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

If the X86 boot fails with the following error:

%SYSBOOT-F-GHREGIONFULL, An allocation was attempted that exceeded
                         the space in the EXEC S2 region.
This is a fatal error in source code.  Please contact VSI support.
Error: Slice allocation S2 Nonpaged pool status: 00000124 for 0x0 bytes halting ...

When invoked as a foreign command to execute a single operation, the LIST command in AUTHORIZE produces the desired output file but returns an incorrect status code to DCL in the $STATUS symbol.

For example:

$ mcr authorize list/brief SYSTEM
$ show symbol $status
$STATUS == "%X10002EE8"
$ write sys$output f$message(%X0002EE8)
%SYSTEM-W-INVKTLIM, invalid kernel thread limit specified

This patch kit corrects the behavior so that the normal success status code is returned as expected.

[SYSEXE]AUTHORIZE.EXE

Jiras SPS-1436, UT-269

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

Exception handling could not always find the target context for a SYS$GOTO_UNWIND_64 operation. This could result in calling the Pascal RTL condition handler an additional time, which eventually caused either an access violation (ACCVIO) or program hang.

This symptom occurred in a Pascal program which used a GOTO statement.

Other exception handler usages within OpenVMS which could experience the problem have also been corrected.

• [SYS$LDR]EXCEPTION.EXE
• [SYS$LDR]EXCEPTION.STB
• [SYS$LDR]EXCEPTION_MON.EXE
• [SYS$LDR]EXCEPTION_MON.STB
• [SYSEXE]LANACP_BFS.EXE
• [SYSEXE]DBGHK$PRCDUMP_KERNEL.EXE
• [SYSLIB]IMGDMP.EXE
• [SYSLIB]LIBRTL.EXE
• [SYSLIB]LIBRTL.STB
• [SYSLIB]SDA$SHARE.EXE

Jiras SPS-1347, RTLS-425

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

The XFC extension for SDA may not display the header for some files displayed by a SHOW FILE command, such as:

SDA> XFC SHOW FILE /BRIEF /OPEN

The routine used to display the file information did not always detect switching to a different disk volume and skipped the header information.

This has been corrected with this patch kit.

[SYSLIB]XFC$SDA.EXE

• Jira BO-1538
• Netsuite NS6238

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

When a magtape is mounted in ANSI mode (not foreign), the magtape ACP (MTAAACP) controls file access on the tape.

The layout of structures used in MTAAACP is different on X86 due to compiler changes from previous architectures. In some cases this caused a timing issue where some transient data was not accessible. This produced an access violation which resulted in an UNXSIGNAL bugcheck and system crash.

The problem is corrected with this patch kit.

[SYSEXE]MTAAACP.EXE

Jira BO-1598

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

An export/import of a VMware VM may change the LAN device adapter type from PCI to PCIE. The device configuration file, SYS$SYSTEM:SYS$CONFIG.DAT, allowed only PCI devices.

This has been corrected by duplicating the VMware LAN device entries and marking one of them PCI and the other PCIE. This configures the LAN devices regardless of the adapter type.

A side effect of this update is that if the e1000e network type is selected when configuring a network device, rather than no device being configured when the VM is booted, the EI device will be configured and an error message is displayed:

Unsupported network interface card, device set offline

The system manager can then edit the VM configuration and select the e1000. Note that the e1000e device will be supported in the next release of VSI OpenVMS x86-64.

[SYSEXE]SYS$CONFIG.DAT

Jiras SPS-1447, BO-1569

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

Edit SYS$SYSTEM:SYS$CONFIG.DAT to duplicate the VMware LAN device entries (search for VMware in SYS$CONFIG.DAT) and change the adapter type such that one entry is PCI and the other is PCIE.

A DIRECTORY command with a file size selection qualifier may not display files larger than 1TB. For example, the command:

$ DIRECTORY/SELECT=SIZE=MINIMUM=1

would not display any files in the directory larger than 1TB.

This problem was due to the selection routine incorrectly interpreting the file size as a signed integer value.

The problem is corrected with this patch kit.

[SYSEXE]DIRECTORY.EXE

Jira BO-1562

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

The SETSHOSHADOW image provides the interface for the SET SHADOW and SHOW SHADOW commands to modify behavior or display information from the shadowing device driver.

Timing issues may arise when these commands are issued before the relevant driver structures are completely initialized while a shadow set is mounted. This would typically result in an access violation and subsequent system crash.

A synchronization mechanism has been added to prevent data being misinterpreted before the mount is complete.

[SYSEXE]SETSHOSHADOW.EXE

Jiras BO-1575, DRIV-188

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

Adding a duplicate network proxy (for example, for having one with /DEFAULT and one without) results in the security server failing and issuing timeout warnings. The only recovery would be to restart the security server.

This problem arose from incorrectly accounting for the new local user in the proxy record.

The problem is corrected with this patch kit.

[SYSEXE]SECURITY_SERVER.EXE

Jiras BO-1531, BO-1584

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

The library routine LIB$X86_ALLOC_BPV is used to allocate a bound procedure value memory area. The conversion to pagelets did not correctly account for the pagesize on X86, resulting in much less memory allocated than was requested. Subsequent access to the memory would either fail or generate an access violation.

This problem is corrected with this patch kit.

• [SYSLIB]LIBRTL.EXE
• [SYSLIB]LIBRTL.STB

Jira RTLS-429

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

The VAX format complex floating point math functions return an incorrect or invalid value for the real portion of the result.

The CVT_IEEE_COMPLEX_TO_VAX macro to convert to VAX format contained a typo for the real portion description.

This problem is corrected with this patch kit.

[SYSLIB]DPML$SHR.EXE

Jira RTLS-431

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

Due to corrections included in V9.2-2, the COBOL RTL needs to readjust code that deals with floating divide-by-zero and invalid floating traps. Without the change, programs that expect to see such errors may get incorrect output or tracebacks.

Correctly working programs are not impacted.

The problem is corrected with this patch kit.

[SYSLIB]DEC$COBRTL.EXE

Jira DEV-2034

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

The routines OTS$ADDP, OTS$ASHP, and OTS$CMPP were rewritten for the V9.2-2 Update V1.0 patch kit to resolve BASIC and COBOL issues.

Further improvements to these routines now provide the expected VAX-style condition status for the functions being performed.

[SYSLIB]LIBOTS2.EXE

Jira RTLS-426

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

The VAX/IEEE conversion routines in LIBOTS.EXE incorrectly modified a preserved register without saving and restoring it. This could lead to incorrect results and unknown effect to the calling routine.

The code has been modified to use a non-preserved temporary register for the affected operations.

• [SYSLIB]LIBOTS.EXE
• [SYSLIB]LIBOTS.STB

Jira DEV-2043

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

When a condition handler performed a goto unwind operation, some context from the original condition was not deallocated before execution continued at the target of the goto unwind.

This problem is corrected with this patch kit.

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

Jiras BO-1570, DEV-1739

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

In a scenario where an $UNWIND operation is initiated intending to reach the base frame, the $UNWIND could fail to reach the base frame and the operation would be aborted. But, since the original mechanism depth was not restored on abort, control would return to the incorrect call frame. This could result in a hang, continuously retrying and aborting the same $UNWIND.

The mechanism depth is now saved during the $UNWIND so control can return to the correct call frame on error or abort.

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

Jiras SPS-1469, BO-1600

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

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.

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

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

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

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.

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

Jiras SPS-1256, BO-1485

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

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.

[SYSEXE]SETSHOWDUMP.EXE

Jira KT-191

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

Do not specify shadow sets to SET DUMP/DEVICE.

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.

[SYS$STARTUP]CLUE$STARTUP.COM

Jiras KT-188, KT-195

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

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

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.

• [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

Jira BO-1537

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

Install the protected shareable image with shared address data.

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.

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

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

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

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

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

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

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

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.

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

Jira BO-1536

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

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.

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

Jira SPS-1352

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

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

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.

[SYSEXE]DDTM$XG_SERVER.EXE

Jira SPS-1271

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

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.

[SYSLIB]LIBOTS2.EXE

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

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

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.

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

Jira AM-221

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

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.

[SYSLIB]DTI$SHARE.EXE

Jiras SPS-1271, BO-1535

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

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

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.

[SYSLIB]TRACE.EXE

Jiras SPS-1339, DEV-2013

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

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

[SYSLIB]DEC$BASRTL.EXE

Jira RTLS-423

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

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.

[SYSEXE]DCL.EXE

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

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

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.

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

Jiras SPS-1375, SPS-1343

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

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.

[SYSEXE]LINK.EXE

Jiras DEV-1944, DEV-2019

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

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

[SYSEXE]SECURITY_SERVER.EXE

Jira BO-1506

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

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

[SYSEXE]SECURITY_SERVER.EXE

Jiras BO-1506, BO-1531

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

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

This problem is corrected with this patch kit.

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

Jiras BO-1540, SPS-1428

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