I had been wondering why nobody else appears to be seeing these particular messages on Tops-10/Tops-20.  It occurred to me that the reason for this is that the default PANDA configuration doesn't enable their display.  If you haven't already done so, then may I suggest adding the following lines to SYSTEM:SYSTEM.CMD?

;; Change default PANDA logging.  We want to know what's going on
Enable Output-Display BUGINF-Messages
Enable Output-Display BUGCHK-Messages
Enable Output-Display System-Messages
Enable Output-Display All-Messages /Information-Messages
Enable Output-Display All-Messages /Job-Messages
Enable Output-Display All-Messages /OPR-Action-Messages
Enable Output-Display DECNET-EVENT-MESSAGES
Enable Output-Display DECNET-LINK-MESSAGES

Among other things, the commands condition some Galaxy component (I think NMLT20 on Tops-20) to do the equivalent of a NODE% JSYS to perform a .NDSIC which enables the fork to receive node topology change interrupts.  However, as these are Galaxy OPR commands, they should be compatible for Tops-10 as well.

The question is whether the messages are indicative of any real issue or whether it's a perfectly fine informative notification of, "Hey, I can't talk to 28NH::".  Normally, I only see such alerts when I make an outgoing connection to a node that is not online.  I don't see anything else, even in the local area.  At one point in Phase III, I would see when nodes coming on and offline, which was kind of cool.

If you do the above and perchance see any messages like the below, then I suggest that you please pass them on to Paul so he can see if there are any correlations with what he's doing.

On 9/13/22 8:19 PM, Thomas DeBellis wrote:

I have Galaxy set to log DECnet events.  For what it's worth, every so often I see the following on my Tops-20 console:


23:19:48          -- DECnet link message --

Communication failure to the following nodes:
28NH

Since January 16th of 2021 (last year), it's happened as 44 times on TOMMYT::  Sometimes it's frequent over a few days, sometimes I can go months without seeing them.  For example, nothing since July.  I'm not sure this has anything to do with the RSTS failure mode.  Absent further information, I'm more inclined to believe that Tops-20 isn't handling a close properly or something has decided to time out.   Aside from the below, I don't have additional data (all times Eastern)

 1)  16-Jan-2021 23:19:48    16)   9-Jul-2021 17:47:59      31)  30-Dec-2021 02:00:23
 2)  18-Jan-2021 23:32:29    17)   8-Aug-2021 12:31:02      32)  10-Jan-2022 19:52:45
 3)  13-Feb-2021 03:02:15    18)  28-Aug-2021 20:24:15      33)  10-Jan-2022 20:13:45
 4)  15-Feb-2021 14:47:26    19)  28-Aug-2021 20:27:55      34)  26-Jan-2022 16:44:22
 5)  16-Feb-2021 03:37:28    20)  30-Aug-2021 20:25:23      35)  26-Jan-2022 16:51:53
 6)  16-Feb-2021 03:40:29    21)  31-Aug-2021 17:02:58      36)  27-Jan-2022 03:01:25
 7)   2-Mar-2021 05:12:34    22)   5-Sep-2021 16:59:49      37)  27-Jan-2022 18:04:29
 8)  21-Mar-2021 08:46:31    23)   6-Sep-2021 17:06:24      38)   1-Feb-2022 00:07:43
 9)  30-Mar-2021 09:33:44    24)   7-Sep-2021 20:10:28      39)   1-Feb-2022 10:56:22
10)   3-Apr-2021 10:04:41    25)  15-Sep-2021 17:05:30      40)  23-Feb-2022 13:28:14
11)   8-Apr-2021 18:06:07    26)   2-Oct-2021 19:58:06      41)   4-May-2022 18:16:00
12)  17-May-2021 16:35:56    27)   6-Nov-2021 23:58:46      42)   9-Jun-2022 12:10:02
13)  25-Jun-2021 18:06:03    28)  25-Nov-2021 03:01:53      43)   7-Jul-2022 04:36:26
14)   1-Jul-2021 19:02:55    29)   6-Dec-2021 10:42:18      44)  11-Jul-2022 21:42:21
15)   8-Jul-2021 19:11:26    30)  24-Dec-2021 17:45:08

It's possible that SPEAR could get some more information on this; I haven't looked.
On 9/13/22 11:12 AM, Paul Koning wrote:
Disallowed anonymous access would show up differently, that would be a connection reject with reject code 34 (authorization data not valid).

	paul