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 to hecnet-leave(a)lists.dfupdate.se

I have tried to keep up with the patches, also those advertised on this list. And it is not only netmapper that knocks on my door… *W* *From:*Keith Halewood &lt;Keith.Halewood(a)pitbulluk.org&gt; *Sent:* Tuesday, September 13, 2022 11:00 AM *To:* The Hobbyist DECnet mailing list &lt;hecnet(a)lists.dfupdate.se&gt; *Subject:* [HECnet] Re: RSTS DECnet config question I have two RSTS 10.1L nodes on HECnet and they see netmapper activity regularly. I’ve not had any issues with job slots running out. Did DECnet patching take place? Otherwise, it doesn’t seem to be netmapper causing this. Keith *From:*Wilm Boerhout [mailto:wboerhout@gmail.com <mailto:wboerhout@gmail.com>] *Sent:* 13 September 2022 09:06 *To:* hecnet(a)lists.dfupdate.se *Subject:* [HECnet] RSTS DECnet config question 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

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) _______________________________________________ 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 &lt;bqt(a)softjar.se&gt; 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

On Sep 13, 2022, at 10:55 AM, Robert Armstrong &lt;bob(a)jfcl.com&gt; wrote: FWIW, I have a very similar problem on ZITI with DECnet/Linux. Every night when Paul’s mapper would run it would leave a zombie NML process hanging around, and after a couple of weeks I’d have to reboot to get rid of them. I just stopped allowing NML access on ZITI for that reason. I’m not saying that Paul’s mapper is to blame – DECnet/Linux has tons of bugs and I’m sure this is just another mistake somewhere. But it might be that the mapper is doing something slightly different or unusual and that’s why we see these symptoms.

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 Sep 13, 2022, at 3:18 PM, Johnny Billquist &lt;bqt(a)softjar.se&gt; wrote: DECnet/Linux definitely have issues. I would agree with what Bob writes. But unless someone manages to trigger this through normal, interactive requests, the mapper is also doing something slightly out of the ordinary. Which in fact seems likely, and most of DECnet/Linux was tested by just running it against VMS as the debug tool. So anything VMS isn't doing have not been properly tested at all. Lots of reverse engineering behind the whole thing.

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.

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. _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se