[HECnet] Another TOPS-10 DECnet problem

[Johnny Billquist]

In RSX, there is no fixed table for logged in users.
There is the device table, and each existing terminal can have a user 
logged in into it.

With "no limits" I just mean that there are no predefined limits, such 
as in RSTS/E where you define how many users/jobs you have.

In RSX, a logged in user has his terminal, and that's it. So there is in 
that sense certainly a limit which is based on how many terminals you have.

But each user can run any number of processse at the same time. There 
are no fixed limit on that. Each process take up a little space in pool, 
and if you run out of pool, you will not be happy.
But processes are dynamically created/deleted, and they all just sit in 
a linked list. So memory would be the one limit, I guess. But that is 
not a fixed number.

   Johnny

On 2021-11-13 17:57, Thomas DeBellis wrote:
> I think Tops-20 had some code for applications terminals, but I don't 
> remember where I saw that.  It has hooks for canonical terminals, but I 
> think that may be DEC's adaptation of MIT's SUPDUP code.
> 
> May I ask you to clarify what you mean by 'no hard limit'?  Do you mean 
> that the configuration parameter is effectively infinite (I.E., a 31 bit 
> positive number) or that the system will dynamically allocate jobs and 
> tasks as they are requested?
> 
> Either way, that is remarkably impressive and contrasts with Tops-20 
> where you have to configure these and (I believe) you do have some 
> limits or some tables overflow.  I think the number of forks per job is 
> limited by the job status block (JSB), which was never put into extended 
> memory.  The number of forks is a hard limit and configured when 
> building the monitor.  For PANDA, the system can accommodate a maximum 
> of 320 forks.  I guess that is probably plenty for all but the most 
> excessive hobbyist usage. This is what my typical development job looks 
> like:
> 
>     @i fork
>          Editor (1): Editor, Kept, HALT at 53206, 0:00:22.1
>          SETNODE-Sources (3): Kept, HALT at 53206, 0:06:23.0
>          Once-Source (4): Kept, HALT at 53206, 0:00:48.9
>          STAR-Sources (5): Kept, HALT at 53206, 0:07:47.7
>          EFTPSER-Sources (6): Kept, HALT at 53206, 0:00:01.9
>          Monitor-DECnet-Sources (7): Kept, HALT at 53206, 0:00:10.1
>          ALGOTS-Sources (12): Kept, HALT at 53206, 0:00:59.0
>          DN60-Sources (13): Kept, HALT at 53206, 0:00:00.8
>          BATCON-Sources (14): Kept, HALT at 53206, 0:00:15.3
>          FAL-DAPLIB-Sources (15): Kept, HALT at 53206, 0:00:01.2
>          PA1050-Sources (16): Kept, HALT at 53206, 0:03:40.5
>          NETPTH-DECnet-Ping-Sources (17): Kept, HALT at 53206, 0:00:09.7
>          DDT-Sources (21): Kept, HALT at 53206, 0:01:28.8
>          Exec-Sources (22): Kept, HALT at 53206, 0:00:05.5
>          LAT-Sources (23): Kept, HALT at 53206, 0:00:08.3
>       => Monitor-TTY-Service (10): Kept, HALT at 53206, 0:00:04.5
>          Kermit-Source (11): Kept, HALT at 53206, 0:03:25.4
>          Monitor-Scheduler (20): Kept, HALT at 53206, 0:00:09.3
>          Monitor-DTE-Driver (2): Kept, HALT at 53206, 0:00:07.1
>          Monitor-NRT-Sources (24): Kept, HALT at 53206, 0:00:03.8
>     @
> 
> At certain times of the year, using 20 forks to handle various source 
> and editing might have gotten me a scolding, back in the day.  During 
> the summer however, we went from 3 student DEC20's to one (CU20A) and 
> the other two (CU20C and CUU20D) were handed over to staff for 
> development and to get them off the staff machine (CU20B). I did get 
> close to this one summer when I was putting Columbia's (extensive) 
> modifications into the Tops-20 V6 field test.
> 
>> ------------------------------------------------------------------------
>> On 11/12/21 6:12 PM, Johnny Billquist wrote:
>>
>> There is no hard limit on the number of logged in users in RSX. And no 
>> hard limit on the number of running tasks either.
>>
>> Controlling lots of terminals from one process in RSX is easy. You do 
>> need to have the terminals open, but the limit on devices accessed 
>> from one task is 256. You don't need to have active I/Os to any 
>> terminal in order to read from them, so it's actually very little 
>> resources required. A little bit of memory, but that's it.
>>
>> I believe this was used out by customers in lots of places. I never 
>> saw any really big ones, but I heard about 911 dispatch centers in the 
>> US. But small scale solutions on the same principles were/are being 
>> run that I know of...
>>
>>   Johnny
>>> ------------------------------------------------------------------------
>>> On 2021-11-12 21:01, Paul Koning wrote:
>>>
>>> RSTS has an API for that, allowing one program to control lots of 
>>> terminals without having to open lots of individual files for each 
>>> terminal.  It makes it possible to support 127 terminals, even though 
>>> the number of logged-in users is limited to 63.
>>>> ------------------------------------------------------------------------
>>>> On Nov 11, 2021, at 6:49 PM, Johnny Billquist <bqt at softjar.se> wrote:
>>>>
>>>> RSX-11M-PLUS can have up to 256 terminals. However, I sortof doubt 
>>>> much useful stuff would happen if you had that many users running 
>>>> interactively.
>>>>
>>>> I think it was more used for systems where you had some clever 
>>>> programs running that controlled lots of terminals.

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol