looks awesome from here too
$ mc ncp tell pirsts show active circuits
Active Circuit Volatile Summary as of 13-SEP-2022 14:36:31
Circuit State Loopback
Adjacent
Name Routing
Node
QNA-0 on 29.206
(ONAPI4)
$
$ mc ncp tell pirsts show active lines
Active Line Volatile Summary as of 13-SEP-2022 14:36:39
Line State
QNA-0 on
$
$ mc ncp tell pirsts show circuit qna-0 char
Circuit Volatile Characteristics as of 13-SEP-2022 14:36:54
Circuit = QNA-0
State = on
Cost = 1
Hello timer = 45
Parameter #811 = 5
Listen timer = 90
Owner = Node 29901PIRSTS
Line = QNA-0
Type = Ethernet
Router priority = 64
Parameter #2110 = %X'00'
$ mc ncp tell pirsts show line qna-0 char
Line Volatile Characteristics as of 13-SEP-2022 14:37:13
Line = QNA-0
State = on
Receive buffers = 10
Protocol = Ethernet
Hardware address = 08-00-2B-02-10-87
$ mc ncp tell pirsts show exec char
Node Volatile Characteristics as of 13-SEP-2022 14:37:28
Executor node = 29.205 (PIRSTS)
State = on
Identification = DECnet/E V4.1
Management version = V4.3.0
Loop count = 1
Loop length = 128
Loop Data type = mixed
Counter timer = 0
Incoming timer = 120
Outgoing timer = 120
NSP version = V4.0.0
Maximum links = 32
Delay factor = 48
Delay weight = 3
Inactivity timer = 120
Retransmit factor = 5
Routing version = V2.0.0
Type = nonrouting IV
Routing timer = 120
Broadcast routing timer = 40
Maximum address = 1023
Maximum circuits = 1
Maximum cost = 1022
Maximum hops = 30
Maximum visits = 32
Maximum area = 63
Max broadcast nonrouters = 64
Max broadcast routers = 16
Maximum buffers = 15
Buffer size = 576
Segment buffer size = 576
Parameter #2125 = [29,206]
Parameter #2126 = 4
Parameter #2127 = 2
Parameter #2129 = 4096
Parameter #2128 = SY0:[0,1]NSP0.SYS
$
$ mc ncp tell pirsts show active nodes
Active Node Volatile Summary as of 13-SEP-2022 14:37:44
Executor node = 29.205 (PIRSTS)
State = on
Identification = DECnet/E V4.1
Active links = 1
Node State Active Delay Circuit Next
node
Links
29.206 (ONAPI4) QNA-0
29.206 (ONAPI4)
31.10 (QCOCAL) 1 7 QNA-0
29.206 (ONAPI4)
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 <bqt@softjar.se> 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 <bqt@softjar.se> 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 <bqt@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. JohnnyOn 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@lists.dfupdate.se To unsubscribe send an email to hecnet-leave@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@lists.dfupdate.se To unsubscribe send an email to hecnet-leave@lists.dfupdate.se_______________________________________________ HECnet mailing list -- hecnet@lists.dfupdate.se To unsubscribe send an email to hecnet-leave@lists.dfupdate.se_______________________________________________ HECnet mailing list -- hecnet@lists.dfupdate.se To unsubscribe send an email to hecnet-leave@lists.dfupdate.se