13 Sep
2022
13 Sep
'22
4:39 p.m.
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)
On 9/13/22 10:32 AM, Wilm Boerhout wrote:
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(a)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(a)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(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
>>>>
>>>>> 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
--
