13 Nov
2021
13 Nov
'21
5:57 p.m.
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.