[HECnet] Another TOPS-10 DECnet problem

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.