10 Nov
2021
10 Nov
'21
4:54 p.m.
. not date related this time (or at least I don't think it is).
Every time I boot TOPS-10 (7.04, KS10, simh) I get stopcode NTMNEC. The
job running is NML and the user PC is 511522. This is a debug stopcode so
the system keeps going.
The manual says of NTMNEC - "Some routine took the non-skip return, but
did not give an error code by calling NTExxx. This means that the program
returned to top level and field NXERR was zero. Determine which
routine is failing, and make the error return give an error code."
Has anybody else seen this? Is there a patch? It's getting a bit
annoying, not to mention that it keeps crash dumping.
Thanks,
Bob
10 Nov
10 Nov
6:37 p.m.
It's possible that NML is gronking on a negative number of
milliseconds.? I suggest you try my updated patch and let us know what
happens.
??? At label NMXTIM + 9 lines, (Decimal) change
??????????? IDIVI T3,JIFSEC???????? ;CONVERT TO NUMBER OF MILLISECONDS.
??????????? SKIPL T2??????????????? ;MAKE SURE WE HAVE A POSITIVE
NUMBER OF SECONDS
??????????? TDNE T1,[XWD -1,600000] ;MAKE SURE NO DATE OVERFLOW
???? To:
??????????? IDIVI T3,JIFSEC???????? ;CONVERT TO NUMBER OF MILLISECONDS.
??????????? MOVMS T3??????????????? ;Ensure milliseconds are always
positive ??????????? MOVMS T2??????????????? ;Ensure seconds are always
positive ??????????? TDZA T1,[XWD -1,600000] ;Ensure no Julian half day
overflow
On 11/10/21 10:54 AM, Robert Armstrong wrote:
? ? not date related this time (or at least I don?t think it is)?
? Every time I boot TOPS-10 (7.04, KS10, simh) I get stopcode NTMNEC.?
The job running is NML and the user PC is 511522.? This is a debug
stopcode so the system keeps going.
? The manual says of NTMNEC ? ?Some routine took the? non-skip?
return,? but did not give an error code by calling NTExxx. ?This means
that the program returned? to? top level? and? field? NXERR was zero.?
Determine which routine is failing, and make the? error return give an
error code.?
? Has anybody else seen this?? Is there a patch?? It?s getting a bit
annoying, not to mention that it keeps crash dumping.
Thanks,
Bob
7 p.m.
Ah.., well, that's different.
I don't suppose DEC supplied source for NML?? More source got released
by default on Tops-10 than Tops-20 (you had to purchase monitor
sources), which we all thought was pretty enlightened as it allowed a
larger number of sites to contribute.
------------------------------------------------------------------------
On 11/10/21 12:56 PM, Robert Armstrong wrote:
It's possible that NML is gronking on a
negative number of milliseconds.
??Thanks, but I?m pretty sure (quite sure actually) that?s not the
issue here.? This problem has been around since I set up VENTI, and
was happening long before yesterday or any NMXTIM patches.
Bob
7:03 p.m.
Even if it doesn't matter (and I would tend to agree with you there),
I'd try the patch that addresses the millisecond value in T3, anyway.
Negative milliseconds sounds like it could seriously disturb something
that wasn't prepared to swallow it...
It can't be right.
------------------------------------------------------------------------
On 11/10/21 1:00 PM, Thomas DeBellis wrote:
Ah.., well, that's different.
I don't suppose DEC supplied source for NML?? More source got released
by default on Tops-10 than Tops-20 (you had to purchase monitor
sources), which we all thought was pretty enlightened as it allowed a
larger number of sites to contribute.
------------------------------------------------------------------------
On 11/10/21 12:56 PM, Robert Armstrong wrote:
>
> >It's possible that NML is gronking on a negative number of milliseconds.
>
> ??Thanks, but I?m pretty sure (quite sure actually) that?s not the
> issue here.? This problem has been around since I set up VENTI, and
> was happening long before yesterday or any NMXTIM patches.
>
> Bob
>
8:12 p.m.
I don't suppose DEC supplied source for NML?
What about these? Not sure about how compatible they are with "recent"
releases tho...
10 ? http://pdp-10.trailing-edge.com/BB-X117B-SB_1986/index.html
20 ? http://pdp-10.trailing-edge.com/BB-P363B-SM_1985/index.html
HTH, :)
G.
10:09 p.m.
Wow!? That looks very promising!? I'll grab both and have a peek.
On 11/10/21 2:12 PM, G. wrote:
I don't
suppose DEC supplied source for NML?
What about these? Not sure about how compatible they are with "recent"
releases tho...
10 ? http://pdp-10.trailing-edge.com/BB-X117B-SB_1986/index.html
20 ? http://pdp-10.trailing-edge.com/BB-P363B-SM_1985/index.html
HTH, :)
G.
7:11 p.m.
I don't suppose DEC supplied source for NML?
Doesn?t look like it ? there?s nothing in [10,7,NML] except for the NML.EXE. Oddly
there are sources for FAL, NFT and even NCP but not NML. I wonder if there?s some ?trick?
for building NML.EXE from some other source?
In any case, following the rule of ?no matter what bad data you give in the monitor
call, it shouldn?t crash the system? I don?t think NML is the problem. It might be
interesting to figure out exactly what call NML is trying to execute, but the bug is in
the monitor.
Bob
10:06 p.m.
It is certainly true that NML might be choking on legitimately bogus
monitor data.??? However, one hesitates to observe that signaling
incorrect input by crashing is a misfeature...
The monitor call would be nice to know.? You can trap both UUO's and
JSYi on Tops-20 in a number of ways to see what is actually happening,
whether or not you have the source.? I can't remember whether Tops-10
has a similar feature.? I thought not, although I'm fairly certain it
does have address break.
If the crash dump is Galaxy based, then it will have the AC's preserved
in a block in the crash dump.
------------------------------------------------------------------------
On 11/10/21 1:11 PM, Robert Armstrong wrote:
I don't suppose DEC supplied source for NML?
??Doesn?t look like it ? there?s nothing in [10,7,NML] except for the
NML.EXE.? Oddly there are sources for FAL, NFT and even NCP but not
NML.? I wonder if there?s some ?trick? for building NML.EXE from some
other source?
? In any case, following the rule of ?no matter what bad data you give
in the monitor call, it shouldn?t crash the system? I don?t think NML
is the problem.? It might be interesting to figure out exactly what
call NML is trying to execute, but the bug is in the monitor.
Bob
10:22 p.m.
It is certainly true that NML might be choking on
legitimately bogus monitor data.
Actually, we?re talking about the other way around ? the monitor is choking on, maybe
legitimate maybe bogus (nobody knows at this point), data from NML.
However, one hesitates to observe that signaling
incorrect input by crashing is a misfeature...
No, one doesn?t hesitate in my universe? Especially when we?re talking about crashing a
timesharing operating system with maybe 100 users logged in, most of whom are students
frantically trying to get their homework finished before class starts in ten minutes :)
Bob
11 Nov
11 Nov
7:25 p.m.
Ah, OK, so I got that backwards...? So it's Tops-10 reporting a
malformed request from NML by crashing, then.? Alright, it's a misfeature.
Did you happen to have a crash dump?? I might like to take a look after
I get Kermit-20 behaving better (and after I figure out what's what with
K10MIT, sigh)
100 students?? That's all?? Heh...? I can't even remember how many we
had online with six 20's, but it didn't matter.? If one of them went
out, you got your choice of machine room phone color: bright red hot or
white hot. ? Been there, done that.? Glad I'm not doing it any more.
------------------------------------------------------------------------
On 11/10/21 4:22 PM, Robert Armstrong wrote:
It is certainly true that NML might be choking on
legitimately bogus
monitor data.
? Actually, we?re talking about the other way around ? the monitor is
choking on, maybe legitimate maybe bogus (nobody knows at this point),
data from NML.
However, one hesitates to observe that signaling
incorrect input by
crashing is a misfeature...
? No, one doesn?t hesitate in my universe?? Especially when we?re
talking about crashing a timesharing operating system with maybe 100
users logged in, most of whom are students frantically trying to get
their homework finished before class starts in ten minutes :)
Bob
7:45 p.m.
On Nov 11, 2021, at 1:25 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
...
100 students? That's all? Heh... I can't even remember how many we had online
with six 20's, but it didn't matter. If one of them went out, you got your choice
of machine room phone color: bright red hot or white hot. Been there, done that. Glad
I'm not doing it any more.
Indeed. I still remember the blistering I got (in 1977) when I added a new feature and
the result was a system crash (buffer overflow due to falling behind) in the middle of the
day, at max load. Max load was 600 logged-in students. Ouch.
paul
8:29 p.m.
Paul,
Don?t you mean 600 logged OUT students?
-Steve
SF:IP2
On Nov 11, 2021, at 13:45, Paul Koning <paulkoning
at comcast.net> wrote:
?
On Nov 11, 2021, at 1:25 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
...
100 students? That's all? Heh... I can't even remember how many we had online
with six 20's, but it didn't matter. If one of them went out, you got your choice
of machine room phone color: bright red hot or white hot. Been there, done that. Glad
I'm not doing it any more.
Indeed. I still remember the blistering I got (in 1977) when I added a new feature and
the result was a system crash (buffer overflow due to falling behind) in the middle of the
day, at max load. Max load was 600 logged-in students. Ouch.
paul
8:43 p.m.
:-) They sure where logged out when the message "plato off" appeared on every
terminal...
paul
On Nov 11, 2021, at 2:29 PM, Steve Davidson <steve
at davidson.net> wrote:
Paul,
Don?t you mean 600 logged OUT students?
-Steve
SF:IP2
> On Nov 11, 2021, at 13:45, Paul Koning <paulkoning at comcast.net> wrote:
>
> ?
>
>> On Nov 11, 2021, at 1:25 PM, Thomas DeBellis <tommytimesharing at
gmail.com> wrote:
>>
>> ...
>> 100 students? That's all? Heh... I can't even remember how many we had
online with six 20's, but it didn't matter. If one of them went out, you got your
choice of machine room phone color: bright red hot or white hot. Been there, done that.
Glad I'm not doing it any more.
>
> Indeed. I still remember the blistering I got (in 1977) when I added a new feature
and the result was a system crash (buffer overflow due to falling behind) in the middle of
the day, at max load. Max load was 600 logged-in students. Ouch.
>
> paul
>
>
10:30 p.m.
You had a 20 that would handle 600 students in 1977/???/? Yikes!!? What
kind of monster was that and how did you do this without melting?
As I recall, the maximum number of lines that an RSX-20F front end would
handle with a full complement of DH11's is 128.? I have heard of a site
(Case Western Reserve) having more than one front end handling lines,
which I would imagine could get you up to 256.? There was also another
site that moved the terminal handling code out of section 0, which was
probably a great idea.
I also recall that the maximum job number that you could get on CFS was
512 for a maximum of 128 jobs per node.
But I don't think I'm aware of any 20 doing more than about 70 active
users without some serious load issues.? That would be a mix of text
editing, email and maybe some iterative program development.? At
Columbia, our standard 20 configuration was two DF20's (?) for (I think)
3.5 MW.? We experimented with 'maxing' a 20 out with two DH20's and an
MA20 for 3.75 MW, but it did not perform substantially better.
I'm not sure what the limiting factor was, whether it was paging or
CPU.? If it was paging, then assuming you weren't doing too many
multi-section programs, a 32MW Toad would clearly handle a higher number
of users (and perhaps far higher), but you are then talking about
contending for other things, RH20's, disks and at some point, you are
just out of CPU.
There was a multi-processor version of TENEX, but nothing like that
exists in any Tops-20 source that I've seen.
------------------------------------------------------------------------
On 11/11/21 2:43 PM, Paul Koning wrote:
:-) They sure where logged out when the message "plato off" appeared on every
terminal...
paul
> ------------------------------------------------------------------------
> On Nov 11, 2021, at 2:29 PM, Steve Davidson<steve at davidson.net> wrote:
>
> Paul,
>
> Don?t you mean 600 logged OUT students?
>
> -Steve
>
> SF:IP2
>> ------------------------------------------------------------------------
>> On Nov 11, 2021, at 13:45, Paul Koning<paulkoning at comcast.net> wrote:
>>
>> Indeed. I still remember the blistering I got (in 1977) when I added a new
feature and the result was a system crash (buffer overflow due to falling behind) in the
middle of the day, at max load. Max load was 600 logged-in students. Ouch.
>>
>> paul
>>
>>> ------------------------------------------------------------------------
>>> On Nov 11, 2021, at 1:25 PM, Thomas DeBellis<tommytimesharing at
gmail.com> wrote:
>>>
>>> ...
>>> 100 students? That's all? Heh... I can't even remember how many we
had online with six 20's, but it didn't matter. If one of them went out, you got
your choice of machine room phone color: bright red hot or white hot. Been there, done
that. Glad I'm not doing it any more.
11:20 p.m.
You had a 20 that would handle 600 students in 1977???
I think he said something about six 20s? I?m pretty sure there?s no way one CPU would
have handled 600 timesharing users. We could get to around 120 on a single KL10E with
TOPS-10 before it got unbearably slow. With TOPS-20 on the same hardware we could only
get to 80 or so; TOPS20 was something of a pig.
Bob
11:48 p.m.
Oh, that old cat fight?? Meow!!? I'm walking away from it; I don't know
how much email got spewed between MRC and BAH about it.? I don't think
either side ever got the point that you are not comparing apples to apples.
Having looked at both schedulers, I don't immediately see that either
was more efficient than the other.? There clearly was cross
fertilization in a number of areas.
Recall that Tops-20 has processes and that a job may have a large number
of processes.? The number of jobs then is not going to be a valid
comparison.? For example, let's take a look at Galaxy on Tops-10, which
occupies 10 job slots:
Job??? Who???? Line#??? What?? Size(P) State?? Run Time
?1??? [OPR]???? DET???? NEBULA? 26+40?? HB 0
?3??? [OPR]????? 0????? QUEUE?? 9+38??? ^C 1
?7??? [OPR]???? DET???? QUASAR? 40+40?? SL 1
?9??? [OPR]???? DET???? PULSAR? 5+40??? HB SW 0
10??? [OPR]???? DET???? ORION?? 109+40? SL 0
11??? [OPR]???? DET???? NML???? 15+18?? HB 3
13??? [OPR]???? DET???? CDRIVE? 30+40?? HB 0
14??? [OPR]???? DET???? FAL-10? 104+40? SL 1
They're all underneath a _single_ job on Tops-20 or built into the EXE?,
but producing the same load because it is the same code.
We did do some instrumenting and we found that the snazzy parsing
(COMND%) was not contributing that much to load.? There was some
overhead simulating UUO's, which are obviously natively executing on
Tops-10.? Nearly all editing was done with WYSIWYG video editing, which
surely must produce more load than TECO or SOS.? Some work was put into
TEXTI% to mitigate the context switching.
MRC's position was that Tops-20 was doing more, but I'm not sure how
comfortable I am with that.? Having used and programmed both, I think
it's more like 'doing differently'.? I would say that it was rare to
find people who could easily move between the two and/or who weren't
highly opinionated.
It's a waste of time; you bought what did the job best for your
environment.? It's kind of like apples and pineapples; they sound the
same but they're just not.
------------------------------------------------------------------------
On 11/11/21 5:20 PM, Robert Armstrong wrote:
You had a 20 that would handle 600 students in
1977/???/
??I think he said something about six 20s?? I?m pretty sure there?s no
way one CPU would have handled 600 timesharing users.?? We could get
to around 120 on a single KL10E with TOPS-10 before it got unbearably
slow.? With TOPS-20 on the same hardware we could only get to 80 or
so; TOPS20 was something of a pig.
Bob
12 Nov
12 Nov
12:26 a.m.
And where I'm from we were regularly running 40 people on one 11/70 with
RSTS/E, and on bad days we were above 60. But then it was miserably slow...
And yes, I have plenty of memories of the mails between MRC and BAH. :-)
Johnny
On 2021-11-11 23:48, Thomas DeBellis wrote:
Oh, that old cat fight?? Meow!!? I'm walking away
from it; I don't know
how much email got spewed between MRC and BAH about it.? I don't think
either side ever got the point that you are not comparing apples to apples.
Having looked at both schedulers, I don't immediately see that either
was more efficient than the other.? There clearly was cross
fertilization in a number of areas.
Recall that Tops-20 has processes and that a job may have a large number
of processes.? The number of jobs then is not going to be a valid
comparison.? For example, let's take a look at Galaxy on Tops-10, which
occupies 10 job slots:
Job??? Who???? Line#??? What?? Size(P) State?? Run Time
?1??? [OPR]???? DET???? NEBULA? 26+40?? HB 0
?3??? [OPR]????? 0????? QUEUE?? 9+38??? ^C 1
?7??? [OPR]???? DET???? QUASAR? 40+40?? SL 1
?9??? [OPR]???? DET???? PULSAR? 5+40??? HB SW 0
10??? [OPR]???? DET???? ORION?? 109+40? SL 0
11??? [OPR]???? DET???? NML???? 15+18?? HB 3
13??? [OPR]???? DET???? CDRIVE? 30+40?? HB 0
14??? [OPR]???? DET???? FAL-10? 104+40? SL 1
They're all underneath a _single_ job on Tops-20 or built into the EXE?,
but producing the same load because it is the same code.
We did do some instrumenting and we found that the snazzy parsing
(COMND%) was not contributing that much to load.? There was some
overhead simulating UUO's, which are obviously natively executing on
Tops-10.? Nearly all editing was done with WYSIWYG video editing, which
surely must produce more load than TECO or SOS.? Some work was put into
TEXTI% to mitigate the context switching.
MRC's position was that Tops-20 was doing more, but I'm not sure how
comfortable I am with that.? Having used and programmed both, I think
it's more like 'doing differently'.? I would say that it was rare to
find people who could easily move between the two and/or who weren't
highly opinionated.
It's a waste of time; you bought what did the job best for your
environment.? It's kind of like apples and pineapples; they sound the
same but they're just not.
------------------------------------------------------------------------
On 11/11/21 5:20 PM, Robert Armstrong wrote:
>
> >You had a 20 that would handle 600 students in 1977/???/
>
> ??I think he said something about six 20s?? I?m pretty sure there?s no
> way one CPU would have handled 600 timesharing users.?? We could get
> to around 120 on a single KL10E with TOPS-10 before it got unbearably
> slow.? With TOPS-20 on the same hardware we could only get to 80 or
> so; TOPS20 was something of a pig.
>
> Bob
>
--
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
12:38 a.m.
Believe me, a large number of us in the systems group were really sorry
to retire our 11/60 (or 11/50? 55?) RSTS system.? We just thought it was
so neat.? And we missed it for years.? The assembler was a little
strange for us, but definitely easier for us to hack than PDP-8 (which
had its own advocates) or IBM 370 (which had truly maniacal devotees)?
The architecture had some very interesting ideas.
I was also one of the few that would move between DEC and IBM, which is
quite a paradigm shift if you've ever had to stare a 3270 in the face
after EMACS.
My students always seem to ask me which OS I prefer or what language is
the best, my response is always the same, "I like the OS that I get paid
to use and the language I get paid to program in".? One has to earn a
living...
I honestly don't know where those two got their stamina from...
------------------------------------------------------------------------
On 11/11/21 6:26 PM, Johnny Billquist wrote:
And where I'm from we were regularly running 40
people on one 11/70
with RSTS/E, and on bad days we were above 60. But then it was
miserably slow...
And yes, I have plenty of memories of the mails between MRC and BAH. :-)
? Johnny
On 2021-11-11 23:48, Thomas DeBellis wrote:
Oh, that old cat fight?? Meow!!? I'm walking
away from it; I don't
know how much email got spewed between MRC and BAH about it.? I don't
think either side ever got the point that you are not comparing
apples to apples.
Having looked at both schedulers, I don't immediately see that either
was more efficient than the other.? There clearly was cross
fertilization in a number of areas.
Recall that Tops-20 has processes and that a job may have a large
number of processes.? The number of jobs then is not going to be a
valid comparison.? For example, let's take a look at Galaxy on
Tops-10, which occupies 10 job slots:
Job??? Who???? Line#??? What Size(P) State?? Run Time
?1??? [OPR]???? DET???? NEBULA? 26+40?? HB 0
?3??? [OPR]????? 0????? QUEUE?? 9+38??? ^C 1
????? [OPR]???? DET???? QUASAR? 40+40?? SL 1
?9??? [OPR]???? DET???? PULSAR? 5+40??? HB SW 0
10??? [OPR]???? DET???? ORION?? 109+40? SL 0
11??? [OPR]???? DET???? NML???? 15+18?? HB 3
13??? [OPR]???? DET???? CDRIVE? 30+40?? HB 0
14??? [OPR]???? DET???? FAL-10? 104+40? SL 1
They're all underneath a _single_ job on Tops-20 or built into the
EXE?, but producing the same load because it is the same code.
We did do some instrumenting and we found that the snazzy parsing
(COMND%) was not contributing that much to load.? There was some
overhead simulating UUO's, which are obviously natively executing on
Tops-10.? Nearly all editing was done with WYSIWYG video editing,
which surely must produce more load than TECO or SOS.? Some work was
put into TEXTI% to mitigate the context switching.
MRC's position was that Tops-20 was doing more, but I'm not sure how
comfortable I am with that.? Having used and programmed both, I think
it's more like 'doing differently'.? I would say that it was rare to
find people who could easily move between the two and/or who weren't
highly opinionated.
It's a waste of time; you bought what did the job best for your
environment.? It's kind of like apples and pineapples; they sound the
same but they're just not.
------------------------------------------------------------------------
On 11/11/21 5:20 PM, Robert Armstrong wrote:
>
> >You had a 20 that would handle 600 students in 1977/???/
>
> ??I think he said something about six 20s?? I?m pretty sure there?s
> no way one CPU would have handled 600 timesharing users.?? We could
> get to around 120 on a single KL10E with TOPS-10 before it got
> unbearably slow.? With TOPS-20 on the same hardware we could only
> get to 80 or so; TOPS20 was something of a pig.
>
> Bob
>
12:49 a.m.
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.
But PDP-11 systems were/are pretty capable, considering some of the
limitations... And they are still being used in some places, which I
find pretty nice. And of course, I continue whack at them when I get a
chance. The combination of TCP/IP, web servers, and stuff like
Datatrieve makes it look almost like some modern stack of tools. I'm
having blast nearly every day. I just wish I could locate the sources of
the layered products...
MRC vs. BAH was sometimes interesting. I usually did side with MRC in
those discussions, but I tried to mostly keep out of it, since PDP-10
isn't my forte. But it was often somewhat interesting to read and
follow, I thought. MRC never quit standing up for TOPS-20. :-)
Johnny
On 2021-11-12 00:38, Thomas DeBellis wrote:
Believe me, a large number of us in the systems group
were really sorry
to retire our 11/60 (or 11/50? 55?) RSTS system.? We just thought it was
so neat.? And we missed it for years.? The assembler was a little
strange for us, but definitely easier for us to hack than PDP-8 (which
had its own advocates) or IBM 370 (which had truly maniacal devotees)
The architecture had some very interesting ideas.
I was also one of the few that would move between DEC and IBM, which is
quite a paradigm shift if you've ever had to stare a 3270 in the face
after EMACS.
My students always seem to ask me which OS I prefer or what language is
the best, my response is always the same, "I like the OS that I get paid
to use and the language I get paid to program in".? One has to earn a
living...
I honestly don't know where those two got their stamina from...
------------------------------------------------------------------------
On 11/11/21 6:26 PM, Johnny Billquist wrote:
> And where I'm from we were regularly running 40 people on one 11/70
> with RSTS/E, and on bad days we were above 60. But then it was
> miserably slow...
>
> And yes, I have plenty of memories of the mails between MRC and BAH. :-)
>
> ? Johnny
>
> On 2021-11-11 23:48, Thomas DeBellis wrote:
>> Oh, that old cat fight?? Meow!!? I'm walking away from it; I don't
>> know how much email got spewed between MRC and BAH about it.? I don't
>> think either side ever got the point that you are not comparing
>> apples to apples.
>>
>> Having looked at both schedulers, I don't immediately see that either
>> was more efficient than the other.? There clearly was cross
>> fertilization in a number of areas.
>>
>> Recall that Tops-20 has processes and that a job may have a large
>> number of processes.? The number of jobs then is not going to be a
>> valid comparison.? For example, let's take a look at Galaxy on
>> Tops-10, which occupies 10 job slots:
>>
>> Job??? Who???? Line#??? What Size(P) State?? Run Time
>>
>> ?1??? [OPR]???? DET???? NEBULA? 26+40?? HB 0
>> ?3??? [OPR]????? 0????? QUEUE?? 9+38??? ^C 1
>> ????? [OPR]???? DET???? QUASAR? 40+40?? SL 1
>> ?9??? [OPR]???? DET???? PULSAR? 5+40??? HB SW 0
>> 10??? [OPR]???? DET???? ORION?? 109+40? SL 0
>> 11??? [OPR]???? DET???? NML???? 15+18?? HB 3
>> 13??? [OPR]???? DET???? CDRIVE? 30+40?? HB 0
>> 14??? [OPR]???? DET???? FAL-10? 104+40? SL 1
>>
>>
>> They're all underneath a _single_ job on Tops-20 or built into the
>> EXE?, but producing the same load because it is the same code.
>>
>> We did do some instrumenting and we found that the snazzy parsing
>> (COMND%) was not contributing that much to load.? There was some
>> overhead simulating UUO's, which are obviously natively executing on
>> Tops-10.? Nearly all editing was done with WYSIWYG video editing,
>> which surely must produce more load than TECO or SOS.? Some work was
>> put into TEXTI% to mitigate the context switching.
>>
>> MRC's position was that Tops-20 was doing more, but I'm not sure how
>> comfortable I am with that.? Having used and programmed both, I think
>> it's more like 'doing differently'.? I would say that it was rare to
>> find people who could easily move between the two and/or who weren't
>> highly opinionated.
>>
>> It's a waste of time; you bought what did the job best for your
>> environment.? It's kind of like apples and pineapples; they sound the
>> same but they're just not.
>> ------------------------------------------------------------------------
>> On 11/11/21 5:20 PM, Robert Armstrong wrote:
>>>
>>> >You had a 20 that would handle 600 students in 1977/???/
>>>
>>> ??I think he said something about six 20s?? I?m pretty sure there?s
>>> no way one CPU would have handled 600 timesharing users.?? We could
>>> get to around 120 on a single KL10E with TOPS-10 before it got
>>> unbearably slow.? With TOPS-20 on the same hardware we could only
>>> get to 80 or so; TOPS20 was something of a pig.
>>>
>>> Bob
>>>
>
--
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
9:01 p.m.
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.
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.
A variation on this theme (with a specialized bulk data DMA service) was used by the
inhouse APT tool to drive manufacturing test setups.
But PDP-11 systems were/are pretty capable,
considering some of the limitations... And they are still being used in some places, which
I find pretty nice. And of course, I continue whack at them when I get a chance. The
combination of TCP/IP, web servers, and stuff like Datatrieve makes it look almost like
some modern stack of tools. I'm having blast nearly every day. I just wish I could
locate the sources of the layered products...
Another example of a large configuration is Typeset-11 (TMS-11). I don't remember
exactly what the terminal limit is on that, but I'm fairly sure it was at least 64.
TMS-11 systems also do a form of clustering, with up to 4 nodes (at least -- that's
the max I remember) with dynamic routing dating back to before DECnet did that. Part of
the reason such a large setup worked is that the terminals are all block-editing
terminals, with the main editing work done on VT-71 terminals where you download a file,
edit it entirely in the terminal (thanks to an 11/23 inside) and send back the result.
Typeset-11 had some rather odd I/O: 6-bit UARTs carrying data streams from wire service
feeds like Associated Press, custom interfaces to typesetting machines (this is before
PostScript), multipoint BiSync over DL-11/E interfaces to connect to Harris 2200 display
ad editing terminals, ...
paul
11:31 p.m.
? My first computer job was at a TMS-11 site. VT71's and72's were great
editing terminals, especially when compared to using EDI on VT52's and
100's. The competition for their use between the programmers and the
typesetters was fierce.
? Say, since you worked on IAS/RSX11D, did you happen to save a copy of
DECNet for either of them or RMS11-K for IAS? I'm an RSX11D/IAS
hobbyist, and products for them are hard to come by....
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
On 11/12/2021 2:01 PM, Paul Koning wrote:
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.
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.
A variation on this theme (with a specialized bulk data DMA service) was used by the
inhouse APT tool to drive manufacturing test setups.
But PDP-11 systems were/are pretty capable,
considering some of the limitations... And they are still being used in some places, which
I find pretty nice. And of course, I continue whack at them when I get a chance. The
combination of TCP/IP, web servers, and stuff like Datatrieve makes it look almost like
some modern stack of tools. I'm having blast nearly every day. I just wish I could
locate the sources of the layered products...
Another example of a large
configuration is Typeset-11 (TMS-11). I don't remember exactly what the terminal
limit is on that, but I'm fairly sure it was at least 64. TMS-11 systems also do a
form of clustering, with up to 4 nodes (at least -- that's the max I remember) with
dynamic routing dating back to before DECnet did that. Part of the reason such a large
setup worked is that the terminals are all block-editing terminals, with the main editing
work done on VT-71 terminals where you download a file, edit it entirely in the terminal
(thanks to an 11/23 inside) and send back the result.
Typeset-11 had some rather odd I/O: 6-bit UARTs carrying data streams from wire service
feeds like Associated Press, custom interfaces to typesetting machines (this is before
PostScript), multipoint BiSync over DL-11/E interfaces to connect to Harris 2200 display
ad editing terminals, ...
paul
13 Nov
13 Nov
2:19 a.m.
No, sorry to say. I have absolutely nothing from that time, not even any documents. I
never saw DECnet for either, actually; the networking technology in TMS-11 was entirely
different and unrelated.
It would be neat if a copy of the VT71 firmware could be found, then SIMH could be taught
to emulate the hardware.
A while ago I contacted a museum in the Boston area which at one time had a TMS-11 system,
but they got rid of it a decade ago and no longer have any records of its fate.
paul
On Nov 12, 2021, at 5:31 PM, Lee Gleason
<lee.gleason at comcast.net> wrote:
My first computer job was at a TMS-11 site. VT71's and72's were great editing
terminals, especially when compared to using EDI on VT52's and 100's. The
competition for their use between the programmers and the typesetters was fierce.
Say, since you worked on IAS/RSX11D, did you happen to save a copy of DECNet for either
of them or RMS11-K for IAS? I'm an RSX11D/IAS hobbyist, and products for them are hard
to come by....
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
On 11/12/2021 2:01 PM, Paul Koning wrote:
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.
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.
A variation on this theme (with a specialized bulk data DMA service) was used by the
inhouse APT tool to drive manufacturing test setups.
But PDP-11 systems were/are pretty capable,
considering some of the limitations... And they are still being used in some places, which
I find pretty nice. And of course, I continue whack at them when I get a chance. The
combination of TCP/IP, web servers, and stuff like Datatrieve makes it look almost like
some modern stack of tools. I'm having blast nearly every day. I just wish I could
locate the sources of the layered products...
Another example of a large
configuration is Typeset-11 (TMS-11). I don't remember exactly what the terminal
limit is on that, but I'm fairly sure it was at least 64. TMS-11 systems also do a
form of clustering, with up to 4 nodes (at least -- that's the max I remember) with
dynamic routing dating back to before DECnet did that. Part of the reason such a large
setup worked is that the terminals are all block-editing terminals, with the main editing
work done on VT-71 terminals where you download a file, edit it entirely in the terminal
(thanks to an 11/23 inside) and send back the result.
Typeset-11 had some rather odd I/O: 6-bit UARTs carrying data streams from wire service
feeds like Associated Press, custom interfaces to typesetting machines (this is before
PostScript), multipoint BiSync over DL-11/E interfaces to connect to Harris 2200 display
ad editing terminals, ...
paul
2:30 a.m.
? Oh, I have the .lda files that were the downline loaded software for
the VT72's. I never thought there'd be any interest in it, without the
hardware.
? I'll send you a copy if you like.
On 11/12/2021 7:19 PM, Paul Koning wrote:
No, sorry to say. I have absolutely nothing from that
time, not even any documents. I never saw DECnet for either, actually; the networking
technology in TMS-11 was entirely different and unrelated.
It would be neat if a copy of the VT71 firmware could be found, then SIMH could be taught
to emulate the hardware.
A while ago I contacted a museum in the Boston area which at one time had a TMS-11
system, but they got rid of it a decade ago and no longer have any records of its fate.
paul
> On Nov 12, 2021, at 5:31 PM, Lee Gleason <lee.gleason at comcast.net> wrote:
>
>
> My first computer job was at a TMS-11 site. VT71's and72's were great
editing terminals, especially when compared to using EDI on VT52's and 100's. The
competition for their use between the programmers and the typesetters was fierce.
>
> Say, since you worked on IAS/RSX11D, did you happen to save a copy of DECNet for
either of them or RMS11-K for IAS? I'm an RSX11D/IAS hobbyist, and products for them
are hard to come by....
> --
> Lee K. Gleason N5ZMR
> Control-G Consultants
> lee.gleason at comcast.net
>
> On 11/12/2021 2:01 PM, Paul Koning wrote:
>>> 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.
>> 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.
>>
>> A variation on this theme (with a specialized bulk data DMA service) was used by
the inhouse APT tool to drive manufacturing test setups.
>>
>>> But PDP-11 systems were/are pretty capable, considering some of the
limitations... And they are still being used in some places, which I find pretty nice. And
of course, I continue whack at them when I get a chance. The combination of TCP/IP, web
servers, and stuff like Datatrieve makes it look almost like some modern stack of tools.
I'm having blast nearly every day. I just wish I could locate the sources of the
layered products...
>> Another example of a large configuration is Typeset-11 (TMS-11). I don't
remember exactly what the terminal limit is on that, but I'm fairly sure it was at
least 64. TMS-11 systems also do a form of clustering, with up to 4 nodes (at least --
that's the max I remember) with dynamic routing dating back to before DECnet did that.
Part of the reason such a large setup worked is that the terminals are all block-editing
terminals, with the main editing work done on VT-71 terminals where you download a file,
edit it entirely in the terminal (thanks to an 11/23 inside) and send back the result.
>>
>> Typeset-11 had some rather odd I/O: 6-bit UARTs carrying data streams from wire
service feeds like Associated Press, custom interfaces to typesetting machines (this is
before PostScript), multipoint BiSync over DL-11/E interfaces to connect to Harris 2200
display ad editing terminals, ...
>>
>> paul
>>
2:39 a.m.
Yes, I would like that. The hardware documentation (for the display processor) is on
Bitsavers, so a simulation should be possible.
I wonder if any of those terminals survived.
paul
On Nov 12, 2021, at 8:30 PM, Lee Gleason
<lee.gleason at comcast.net> wrote:
Oh, I have the .lda files that were the downline loaded software for the VT72's. I
never thought there'd be any interest in it, without the hardware.
I'll send you a copy if you like.
On 11/12/2021 7:19 PM, Paul Koning wrote:
No, sorry to say. I have absolutely nothing from
that time, not even any documents. I never saw DECnet for either, actually; the
networking technology in TMS-11 was entirely different and unrelated.
It would be neat if a copy of the VT71 firmware could be found, then SIMH could be taught
to emulate the hardware.
A while ago I contacted a museum in the Boston area which at one time had a TMS-11
system, but they got rid of it a decade ago and no longer have any records of its fate.
paul
> On Nov 12, 2021, at 5:31 PM, Lee Gleason <lee.gleason at comcast.net> wrote:
>
>
> My first computer job was at a TMS-11 site. VT71's and72's were great
editing terminals, especially when compared to using EDI on VT52's and 100's. The
competition for their use between the programmers and the typesetters was fierce.
>
> Say, since you worked on IAS/RSX11D, did you happen to save a copy of DECNet for
either of them or RMS11-K for IAS? I'm an RSX11D/IAS hobbyist, and products for them
are hard to come by....
> --
> Lee K. Gleason N5ZMR
> Control-G Consultants
> lee.gleason at comcast.net
>
> On 11/12/2021 2:01 PM, Paul Koning wrote:
>>> 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.
>> 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.
>>
>> A variation on this theme (with a specialized bulk data DMA service) was used by
the inhouse APT tool to drive manufacturing test setups.
>>
>>> But PDP-11 systems were/are pretty capable, considering some of the
limitations... And they are still being used in some places, which I find pretty nice. And
of course, I continue whack at them when I get a chance. The combination of TCP/IP, web
servers, and stuff like Datatrieve makes it look almost like some modern stack of tools.
I'm having blast nearly every day. I just wish I could locate the sources of the
layered products...
>> Another example of a large configuration is Typeset-11 (TMS-11). I don't
remember exactly what the terminal limit is on that, but I'm fairly sure it was at
least 64. TMS-11 systems also do a form of clustering, with up to 4 nodes (at least --
that's the max I remember) with dynamic routing dating back to before DECnet did that.
Part of the reason such a large setup worked is that the terminals are all block-editing
terminals, with the main editing work done on VT-71 terminals where you download a file,
edit it entirely in the terminal (thanks to an 11/23 inside) and send back the result.
>>
>> Typeset-11 had some rather odd I/O: 6-bit UARTs carrying data streams from wire
service feeds like Associated Press, custom interfaces to typesetting machines (this is
before PostScript), multipoint BiSync over DL-11/E interfaces to connect to Harris 2200
display ad editing terminals, ...
>>
>> paul
>>
12:12 a.m.
On 2021-11-12 21:01, Paul Koning 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
--
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
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.
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.
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.
14 Nov
14 Nov
2:46 a.m.
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
4:01 a.m.
? This discussion of RSX? limits reminds me of a pre symposium seminar
I attended decades ago, about the RSX11M exec (M+ hadn't been released yet).
? It was presented by Robert Bismuth, an RSX heavy of the era. He
mentioned in passing that the absolute limit of the number of running
tasks on an RSX11M system was around 300 or so (he had an exact number -
I don't recall it). All running a one instruction task that did a
branch-on-self. He said it was limited by available pool. I wonder if
anyone has done the research on M+ to see what its maximum number of
running tasks is.
On 11/13/2021 7:46 PM, Johnny Billquist wrote:
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.
12:42 p.m.
I've not done any analysis, but I suspect it's higher in M+. The reason
being that one important change in M+ was the creation of secondary
pool, which is much larger, and a bunch of stuff moved over from primary
pool to secondary pool. You also have split I/D space for the kernel, so
pool in general is much larger in M+.
But thanks for the info. Very interesting.
Johnny
On 2021-11-14 04:01, Lee Gleason wrote:
? This discussion of RSX? limits reminds me of a pre symposium seminar
I attended decades ago, about the RSX11M exec (M+ hadn't been released
yet).
? It was presented by Robert Bismuth, an RSX heavy of the era. He
mentioned in passing that the absolute limit of the number of running
tasks on an RSX11M system was around 300 or so (he had an exact number -
I don't recall it). All running a one instruction task that did a
branch-on-self. He said it was limited by available pool. I wonder if
anyone has done the research on M+ to see what its maximum number of
running tasks is.
On 11/13/2021 7:46 PM, Johnny Billquist wrote:
--
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
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.
12 Nov
12 Nov
12:55 a.m.
On 11/11/21 6:38 PM, Thomas DeBellis wrote:
I was also one of the few that would move between DEC
and IBM, which
is quite a paradigm shift if you've ever had to stare a 3270 in the
face after EMACS.
Tim Stark and I have multiple VAXen talking DECnet to HECnet and NJE to
HNET (the global hobbyist Bitnet-II network). DNANJE and TCPNJE work
great using JNET from Wingra. A few VMS and Linux nodes show up on both
lists: http://moshix.dynu.net/
It is kind of cool to receive a file over NJE and copy it to another
host over DECnet :)
1:21 a.m.
Really?? I'll have to finish looking into that.
I had wanted to dust off the IBMSPL code (which I had hacked a lot at
Columbia) and wire it into HNET, but I didn't finish the review to
understand at what level I would need to wire the IP based protocols in
to replace (or simulate) the DN60.
I'm just too deep into too many rabbit holes...
------------------------------------------------------------------------
On 11/11/21 6:55 PM, Supratim Sanyal wrote:
Tim Stark and I have multiple VAXen talking DECnet to HECnet and NJE
to HNET (the global hobbyist Bitnet-II network). DNANJE and TCPNJE
work great using JNET from Wingra. A few VMS and Linux nodes show up
on both lists: http://moshix.dynu.net/
It is kind of cool to receive a file over NJE and copy it to another
host over DECnet :)
------------------------------------------------------------------------
On 11/11/21 6:38 PM, Thomas DeBellis wrote:
I was also one of the few that would move between DEC and IBM, which
is quite a paradigm shift if you've ever had to stare a 3270 in the
face after EMACS.
1:26 a.m.
On 11/11/21 7:21 PM, Thomas DeBellis wrote:
Really?? I'll have to finish looking into that.
Really! :)
And, to make things more interesting, I have a little AppleTalk Phase-2
network going with Tomas over the same GRE tunnel that carries DECnet
traffic between my and his areas :)
I had wanted to dust off the IBMSPL code (which I had
hacked a lot at
Columbia) and wire it into HNET, but I didn't finish the review to
understand at what level I would need to wire the IP based protocols
in to replace (or simulate) the DN60.
I'm just too deep into too many rabbit holes...
> ------------------------------------------------------------------------
> On 11/11/21 6:55 PM, Supratim Sanyal wrote:
>
> Tim Stark and I have multiple VAXen talking DECnet to HECnet and NJE
> to HNET (the global hobbyist Bitnet-II network). DNANJE and TCPNJE
> work great using JNET from Wingra. A few VMS and Linux nodes show up
> on both lists: http://moshix.dynu.net/
>
> It is kind of cool to receive a file over NJE and copy it to another
> host over DECnet :)
>> ------------------------------------------------------------------------
>> On 11/11/21 6:38 PM, Thomas DeBellis wrote:
>>
>> I was also one of the few that would move between DEC and IBM, which
>> is quite a paradigm shift if you've ever had to stare a 3270 in the
>> face after EMACS.
>
--
3:03 a.m.
On Nov 11, 2021, at 4:30 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
You had a 20 that would handle 600 students in 1977??? Yikes!! What kind of monster was
that and how did you do this without melting?
No, sorry for confusing the story. The 600 user machine (with 1000 connected terminals)
was the University of Illinois PLATO system, running on a pair of CDC 6500 mainframes.
Later versions got much bigger (on larger and faster CDC mainframes), but 600 users on a
pair of two-core machines each running at around two MIPS or so was a pretty significant
achievement.
paul
908
days inactive
912
days old
33 comments
8 participants
participants (8)
-
bob＠jfcl.com -
bqt＠softjar.se -
gerry77＠mail.com -
lee.gleason＠comcast.net -
paulkoning＠comcast.net -
steve＠davidson.net -
supratim＠riseup.net -
tommytimesharing＠gmail.com