This is the V8.4-M release of DECnet-Plus for the following versions of VMS: VSI V8.4-1H1 on IA64 systems VSI V8.4-2 on IA64 systems VSI V8.4-2L1 on IA64 systems VSI V8.4-2L3 on IA64 systems VSI V8.4-2L1 on Alpha systems VSI V8.4-2L2 on Alpha systems Below is a summary of all HPE-reported and VSI-reported bugs that have been fixed since HPE shipped DECnet V8.4 for IA64 and Alpha systems HPE QuIX QXCM1001326591 The ISO8473 Echo Response does not work and produces corrupted ERP packets HPE QuIX QXCM1001317124 When L2 Link State HBR is configured in a cluster, the cluster alias on other cluster member remains unreachable. HPE QuIX QXCM1001392243 A DECnet node crashed due to inline bug-check in the TPCONS module HPE QuIX s QXCM1001443450 and QXCM1001332464 System crashed in TPCONS module with BUGCHECK type DECnet detected a fatal error. HPE QuIX QXCM1001513342 circuits connected to the same LAN, one of the routing circuits is assigned to the wrong router. HPE QuIX QXCM1001526839,QXCM1001538156 Fix connectivity issue between cluster alias members when L2 link state HBR is configured on the cluster The following two bugs are fixed in DECnet-Plus V8.4-J VSI BZ #951 DECnetPlus: Event Logging Transport Selector Missing 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. VSI BZ #1112 Crash with DECNET, DECnet detected a fatal error PWIPDRIVER passed bad data to the TPCONS component of DECnet-Plus, causing a crash. TPCONS now returns an error instead of crashing. The following bug is fixed in DECnet-Plus V8.4-K VSI BZ #3673 NET$CONFIGURE.COM not accepting 70000 for OSI Maximum Receive Buffers NET$CONFIGURE was mistakingly 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 following four bugs are fixed in DECnet-Plus V8.4-L VSI Jira DV-19 All OSI incoming connections are rejected 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. VSI Jira DV-20 Memory leak when adding/deleting session control applications 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. VSI Jira DV-22 Errors in DTSS$ERROR.LOG 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. VSI internally-found bug NET$CONFIGURE.COM is not user-friendly 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. The following change is made in DECnet-Plus V8.4-M The format of the value returned by SYI$_DECNET_VERSION has changed. Prior to this change, the value was hexidecimal 00051702, where 0005 denoted DECnet Phase V, and 1702 was an opaque value that corresponded to the release put out by Hewlett-Packard for V8.4 ECO2. That value had remained unchanged by VSI for its subsequent DECnet-Plus releases. For this release the value is hexidecimal 0005840D, where 0005 still denotes DECnet Phase V. For the low-order word of 840D, 84 indicates VMS version 8.4 and 0D is the ASCII value indicating the -M release. The following bug is fixed in DECnet-Plus V8.4-M VSI Jira DV-15 Alias connections are improperly rejected 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 and $ MCR NCL SHOW NSP MAX TRANSPORT CONNECTIONS $ MCR NCL SHOW NSP ALL STATUS There is a longstanding hardcoded 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.