Op 13 sep. 2022 om 12:00 heeft Johnny Billquist <bqt(a)softjar.se> het volgende geschreven: Are you saying that even though the DECnet connections are finished, there are processes that stay around forever? That seems wrong. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

I don't think you can blame any crawler for this. This would appear to be something wrong in RSTS/E then. Paul can maybe figure out what the problem is and how to resolve it.   Johnny On 2022-09-13 12:02, Wilm Boerhout wrote:

Funny as in "mostly vanilla"? Attached is the command output with credentials. But having priv access only here should not cause that behavior? Wilm -----Original Message----- From: Johnny Billquist <bqt(a)softjar.se> Sent: Tuesday, September 13, 2022 1:55 PM To: hecnet(a)lists.dfupdate.se Subject: [HECnet] Re: RSTS DECnet config question PIRSTS is "funny". .ncp tell pirsts sho exec cha NCP -- Show failed, operation failure ?Protection violation Error finding executor state . Maybe related? Johnny On 2022-09-13 12:58, Johnny Billquist wrote: _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

OK, NCP.TSK was <104> now <232>. NCP TELL from VAX no longer needs authentication. In a few days, I can tell whether this has fixed my original problem. Wilm -----Original Message----- From: Johnny Billquist&lt;bqt(a)softjar.se&gt; Sent: Tuesday, September 13, 2022 4:02 PM To:hecnet@lists.dfupdate.se Subject: [HECnet] Re: RSTS DECnet config question Well. I suspect any scraping would get the same effect I saw. On most any other machine that don't allow anonymous access, you'd see something like: .ncp tell jocke sho exec NCP -- Show failed, Listener connect failed, access control rejected But it might be that RSTS/E gives a result like that when no access. Just not what I would have expected. Johnny On 2022-09-13 14:12, Wilm Boerhout wrote: > Funny as in "mostly vanilla"? > > Attached is the command output with credentials. > > But having priv access only here should not cause that behavior? > > > Wilm > > -----Original Message----- > From: Johnny Billquist&lt;bqt(a)softjar.se&gt; > Sent: Tuesday, September 13, 2022 1:55 PM > To:hecnet@lists.dfupdate.se > Subject: [HECnet] Re: RSTS DECnet config question > > PIRSTS is "funny". > > .ncp tell pirsts sho exec cha > NCP -- Show failed, operation failure > ?Protection violation > Error finding executor state > . > > Maybe related? > > Johnny > > On 2022-09-13 12:58, Johnny Billquist wrote: >> I don't think you can blame any crawler for this. This would appear >> to be something wrong in RSTS/E then. Paul can maybe figure out what >> the problem is and how to resolve it. >> >> Johnny >> >> On 2022-09-13 12:02, Wilm Boerhout wrote: >>> That is what happens. I have 32 job slots, and usually it takes less >>> than two weeks to fill up. Unless I happen to log in in between and >>> kill the jobs. >>> >>> Groet, >>> Wilm >>> >>> (Verstuurd vanaf mijn telefoon, dus wat korter dan gewoonlijk.) >>> (Sent from my phone, so a bit more compact than usual) >>> >>>> Op 13 sep. 2022 om 12:00 heeft Johnny Billquist&lt;bqt(a)softjar.se&gt; >>>> het volgende geschreven: >>>> >>>> Are you saying that even though the DECnet connections are >>>> finished, there are processes that stay around forever? That seems wrong. >>>> >>>> Johnny >>>> >>>>> On 2022-09-13 10:06, Wilm Boerhout wrote: >>>>> Hail all you RSTS buffs! >>>>> One of my nodes (PIRSTS) is running RSTS V10.1L and DECnet V4.1 >>>>> Ever since I am on HECnet, I have observed that job slots are >>>>> filled over time with jobs under the DECnet account [29,206] in HB >>>>> state, up to the point that the job max is reached, and I cannot >>>>> log in anymore. >>>>> My working hypothesis is that the polling processes (for HECnet >>>>> mapping and other inquiring minds – you know who you are) keep >>>>> creating new jobs, instead of reusing old ones. >>>>> Is there a way to tell DECnet/E that it should not keep jobs in HB >>>>> state, but log them out after use? Or reuse existing jobs on >>>>> incoming connection requests? On DECnet/VMS there are timer and >>>>> other logicals that steer this behavior. >>>>> Running a daily kill job seems, well, overkill. >>>>> Thanks, >>>>> *Wilm* >>>>> _______________________________________________ >>>>> HECnet mailing list --hecnet(a)lists.dfupdate.se To unsubscribe >>>>> send an email tohecnet-leave(a)lists.dfupdate.se >>>> -- >>>> Johnny Billquist || "I'm on a bus >>>> || on a psychedelic trip >>>> email:bqt@softjar.se || Reading murder books pdp is >>>> alive! || tryin' to stay hip" - B. Idol >>>> _______________________________________________ >>>> HECnet mailing list --hecnet(a)lists.dfupdate.se To unsubscribe send >>>> an email tohecnet-leave(a)lists.dfupdate.se >>> _______________________________________________ >>> HECnet mailing list --hecnet(a)lists.dfupdate.se To unsubscribe send >>> an email tohecnet-leave(a)lists.dfupdate.se > > _______________________________________________ > HECnet mailing list --hecnet(a)lists.dfupdate.se To unsubscribe send an > email tohecnet-leave(a)lists.dfupdate.se

The "protection violation" message is a standard RSTS message. It means that some OS request was made by a program and that request was rejected because it requires privilege and the program/user does not have that. I don't remember why the OS requests to query DECnet state require privilege; perhaps because they are the same request as is used to change state, which obviously needs to, or perhaps because some of the state is potentially sensitive and being more selective in the access checking wasn't worth the trouble. Disallowed anonymous access would show up differently, that would be a connection reject with reject code 34 (authorization data not valid). paul _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

------------------------------------------------------------------------ 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 16^th 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

On Sep 15, 2022, at 2:34 PM, Johnny Billquist &lt;bqt(a)softjar.se&gt; wrote: For directly connected nodes (point-to-point or ethernet), I usually get a log notification whenever a node comes or goes. That is pretty much standard DECnet logging. And it's event 4.15 for adjacency up, and 4.18 for adjacency down. Johnny

The mapper is very simple. Quoting from pydecnet/doc/mapper.txt: The network scanner looks at every node mentioned in the node database plus every node it can see as reachable. Roughly speaking, it makes a NICE connection (remote network management protocol) to each node, then asks it three questions: "show exec characteristics", "show active circuits" and "show active nodes". The first questions answers "what type of node is this" and also gets the node name if we don't already know it. The other two give the adjacent nodes, i.e., the connections from this node to its neighbors. Often but not always, that information includes the node type of the adjacent nodes. So to see what impact mapper polling would have on any given NML, you can simply use NCP, issue "set exec node <nodename>" then issue the three commands shown above. paul _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

Sure, but then again NICE is fully documented (other than OS-specific requests) in the architecture manuals; all that an implementer needs to do is implement what those specs say. Unlike some other specs, DECnet in general was specified sufficiently carefully that if you do what it says, it will work.

A good test would be to take an RSX or RSTS host and issue the NCP requests I described the mapper issues, to see if that reproduces the issue. And if not, then it might be time to trace the precise packets to see how they differ. As I said, there is nothing in any way unusual about the NICE requests the mapper issues.