VSI DECnet-Plus Version 9.2-H

Previously, the following error was displayed at the end of the test:

OSIT$IVP ..Disconnecting transport connection
%SYSTEM-F-IVDEVNAM, invalid device name
%NONAME-F-NOMSG, Message number 00000004

A fix was made to NET$OSDRIVER.EXE to solve this problem.

The porting of MOP to x86-64 was inadvertently not finished. Memory management differences between Alpha/IA-64 and x86-64 required changes that were not made until now. MOP now works correctly.

Several procedures that display a copyright year were not always having the copyright year updated. Those procedures will now be automatically updated during the build. The affected procedures are NET$CONFIGURE.COM, NET$STARTUP.COM, and NET$SHUTDOWN.COM.

A timing window existed such that periodic communication errors were returned from the X.500 DSA server to the X.500 DXIM client. This windows has been closed.

This is a continuation of the fix made in DECnet-Plus V9.2-B that addressed VSI Jira DV-19 -- All OSI incoming connections are rejected We think that we've put the final nail in the coffin by properly deallocating a memory structure that had been forgotten.

In DECnet-Plus V9.2-B, a fix was made for Jira DV-19, which involved a condition where all incoming OSI connections are rejected. As part of that fix, various spinlock acquisitions were added. Unfortunately, we were a bit aggressive in our spinlock holding, leading to Jira DV-49. The fix was to release the relevant spinlock before touching address space in a process that could be paged out.

If DECnet was stopped and then restarted without an intervening system reboot, an error was emitted during the startup of DNS. Whilst this error is benign, its appearance can be confusing.

The procedure DNS$CLERK_STARTUP.COM has been modified to check to see if the execlet SYS$NAME_SERVICES has been loaded. If it has, then no attempt is made to load it again.

A required change to some internal networking data structures inadvertently broke the IP port forwarding mechanism in DECnet-Plus. This change was made during VMS V9.2 development; a temporary fix was put in to prevent system crashes, but IP port forwarding was broken.

With this fix, IP port forwarding now works correctly.

In an environment with a high rate of incoming alias connections, clients will sometimes be rejected, with no understandable error message. At the time of the rejection, the current transport connections are well below the limit as shown by:

$ MCR NCL SHOW OSI TRANSPORT MAX TRANSPORT CONNECTIONS
$ MCR NCL SHOW OSI TRANSPORT ALL STATUS

$ MCR NCL SHOW NSP MAX TRANSPORT CONNECTIONS
$ MCR NCL SHOW NSP ALL STATUS

There is a longstanding hard-coded limit of 64 incoming alias connections for each node participating as a cluster alias target. When those 64 slots are used up (or pending deletion if the connection has already been terminated), incoming connections are rejected.

Also, there was a mechanism in place to ensure that a slot was not prematurely reused. A slot could not be reused until a certain amount of time had passed. From comments in the code, it's not clear how long that timeout was supposed to be. The comments indicated that the unit of the timeout was 1/100 of a second, and that 15 times that unit was to have passed.

However, EXE$GL_ABSTIM is used as the counter; that is the number of seconds since the system has booted. So, that meant that a slot needed to have been freed up for 15 seconds before it could be resued. We think that was not the intent of the engineer who originally wrote that code.

Thus, we have reduced the multiplier from 15 down to 5. We think that value is still rather high, but is a conservative change.

Reducing the aging factor of slot reuse, in conjunction with increasing the number of slots from 64 to 1024 has eliminated this connection rejection problem. With these changes, DECnet engineering and the support staff have been unable to reproduce the problem. Prior to this fix, the problem was 100% reproducible.

This problem was seen on a system where client-initiated connections were being disconnected due to a timeout. The issue was that certain data structures were not being correctly deallocated in response to the disconnection request. As a result, a table that temporarily holds pointers to those data structures filled up, which prevented the creation of new incoming connections.

The resolution is to correctly handle the incoming disconnect request, thereby deallocating the relevant data structures and removing the relevant entries in the connection table.

This problem was seen when adding and then deleting the same session control application repeatedly. Certain data structures were not deleted when the application was deleted.

The resolution is to correctly delete the relevant data structures.

A problem arose due to the default naming scheme for DTSS servers. Prior to this change, the underscore character _ was being used as part of the default name. That use is in contravention to RFC 1035.

The resolution is to remove the underscore as part of the default name.

As part of the dialogue presented by NET$CONFIGURE, one is asked for the ordered list to use for directory services. A response with a comma-delimited list with whitespace after the comma, such as "domain, local", is greeted with the error message:

%NET$CONFIGURE-E-INVCIDLIST, invalid CDI directory service list

The simple fix is to use F$EDIT( answer, "COLLAPSE" ) to remove all whitespace before processing the response.

NET$CONFIGURE was mistakenly restricting the OSI transport maximum receive buffers to 65535. Whereas the NSP transport maximum receive buffer parameter is limited to 65535, the OSI transport maximum receive buffer parameter can be as high as 4294967295. NET$CONFIGURE was using the wrong F$FAO format specifier when creating the NCL script after the configuration dialog.

The local transport selector was not displayed in the OPCOM message that was reported for a local transport disconnection. The remote transport selector was being displayed, but not the local transport.

The local transport selector is now displayed correctly in the OPCOM message.

PWIPDRIVER passed bad data to the TPCONS component of DECnet-Plus, causing a crash.

TPCONS now returns an error instead of crashing.

The ISO8473 Echo Response does not work and produces corrupted ERP packets.

When L2 Link State HBR is configured in a cluster, the cluster alias on other cluster member remains unreachable.

A DECnet node crashed due to inline bug-check in the TPCONS module.

System crashed in TPCONS module with BUGCHECK type DECnet detected a fatal error.

Circuits connected to the same LAN, one of the routing circuits is assigned to the wrong router.

Fix connectivity issue between cluster alias members when L2 link state HBR is configured on the cluster.