TOPS-20 Boot Camp for VMS Users 05-Mar-2022

[Stephen M. Jones]

On Saturday March 5th, 2022 SDF will kick off its TOPS-20 Boot Camp series
on https://twitch.tv/sdfpubnix at 1PM Pacific Time (9PM GMT). Registration
is open at https://twenex.org/?bootcamp which includes access to SDF's
XKL Toad-2 and is offered at no cost.

If you cannot attend an archive of the live stream (approximately
1 hour long) will be posted to the fediverse via SDF's Peertube instance,
https://toobnix.org

Looking forward to doing a "TOPS-20 Boot Camp for VMS Users", though any User
of any operating system background is certainly welcome, kid.

[Scott Lurndal]

Can you refresh my memory on the advantages and disadvantages of the PDP-10
vs. the VAX-11/780? From a technical standpoint, not from a nostalgia or DEC politics
standpoint? My migration at the time was from a PDP-8 to PDP-11 to VAX-11.

[Ahem A Rivet's Shot]

On Thu, 03 Mar 2022 14:30:52 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:

> Can you refresh my memory on the advantages and disadvantages of the
> PDP-10 vs. the VAX-11/780? From a technical standpoint, not from a

PDP-10 was a 36 bit mainframe that (usually) ran TOPS.
VAX-11/780 was a 32 bit mini that (usually) ran VMS.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

[Scott Lurndal]

Ahem A Rivet's Shot <ste...@eircom.net> writes:
>On Thu, 03 Mar 2022 14:30:52 GMT
>sc...@slp53.sl.home (Scott Lurndal) wrote:
>
>> Can you refresh my memory on the advantages and disadvantages of the
>> PDP-10 vs. the VAX-11/780? From a technical standpoint, not from a
>
> PDP-10 was a 36 bit mainframe that (usually) ran TOPS.
> VAX-11/780 was a 32 bit mini that (usually) ran VMS.
>

What were the advantages, if any, of one family over the other family?

I'm quite aware of the hardware specifications.

How does TOPS DCL compare with VMS DCL?

[Rich Alderson]

Ahem A Rivet's Shot <ste...@eircom.net> writes:

> On Thu, 03 Mar 2022 14:30:52 GMT
> sc...@slp53.sl.home (Scott Lurndal) wrote:

>> Can you refresh my memory on the advantages and disadvantages of the
>> PDP-10 vs. the VAX-11/780? From a technical standpoint, not from a

> PDP-10 was a 36 bit mainframe that (usually) ran TOPS.
> VAX-11/780 was a 32 bit mini that (usually) ran VMS.

There is not such thing as "TOPS". There were 2 operating systems available
from DEC for the PDP-10 architecture, named "Tops-10" and "TOPS-20". (There
were others, such as MIT AI Lab's ITS, the Stanford AI Lab's WAITS, and BBN's
TENEX.)

Tops-10 was the older system, a direct development of the monitor developed for
the PDP-6. It featured a wide array of device types, including realtime
capabilities, and a very low level I/O model in which the programmer had to
know details of the device(s) for which she was writing (buffer sizes, how many
buffers to specify for best operation, etc.). System calls were created using
hardware instruction traps ("Unimplemented User Opcodes" or UUOs).

TOPS-20 was created for the third generation PDP-10, based on the research OS
TENEX from BBN (which was created to explore demand-paged virtual memory on the
first generation PDP-10). The only direct I/O access was to disks and tapes;
everything else was mediated through the PDP-11/40 front end processor (or
other PDP-11/34 processors for things like DECnet). There was only a single
system call instruction, JSYS "Jump to SYStem", with massive internal dispatch
tables to handle every contingency; I/O was handled by means of particular JSYS
calls, and internally handled by the page mapping hardware.

ITS started as an experiment on the PDP-6, and used the same model for I/O as
the DEC monitor, although the details and implementations were sui generis.

WAITS grew out of DEC's PDP-6 monitor, with updates to the PDP-10 version until
1972, at which time the two went their separate ways. WAITS used the same I/O
model as the DEC monitor, although hardware I/O instructions were available to
user mode programs without privilege escalation (for use with specialized
hardware like robot arms).

--
Rich Alderson ne...@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

[Rich Alderson]

sc...@slp53.sl.home (Scott Lurndal) writes:

> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>> On Thu, 03 Mar 2022 14:30:52 GMT
>> sc...@slp53.sl.home (Scott Lurndal) wrote:

>>> Can you refresh my memory on the advantages and disadvantages of the
>>> PDP-10 vs. the VAX-11/780? From a technical standpoint, not from a

>> PDP-10 was a 36 bit mainframe that (usually) ran TOPS.
>> VAX-11/780 was a 32 bit mini that (usually) ran VMS.

> What were the advantages, if any, of one family over the other family?

VMS ran on supported hardware after 1983.

The PDP-10 operating systems were mainframe oriented ab origine, unlike VMS.

> I'm quite aware of the hardware specifications.

> How does TOPS DCL compare with VMS DCL?

Again, there ain't no "TOPS".

Tops-10 offered a facility called "MIC" which allowed for programmed execution
of programs, but programs had to be written to handle whatever command line
arguments they might expect.

TOPS-20 offered an unrelated facility also called "MIC", which was less capable
than the Tops-10 facility of the same name. In addition, later versions of
TOPS-20 offered "PCL" ("Programmable Command Language"), with a very different
syntax than MIC, which originated at CMU but provided as an unsupported feature
by DEC.

The facilities offered by both OSes are unrelated to "DCL" as understood by VMS
and other PDP-11 oeprating systems.

[Ahem A Rivet's Shot]

On 03 Mar 2022 15:24:16 -0500

Rich Alderson <ne...@alderson.users.panix.com> wrote:

> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>
> > On Thu, 03 Mar 2022 14:30:52 GMT
> > sc...@slp53.sl.home (Scott Lurndal) wrote:
>
> >> Can you refresh my memory on the advantages and disadvantages of the
> >> PDP-10 vs. the VAX-11/780? From a technical standpoint, not from a
>
> > PDP-10 was a 36 bit mainframe that (usually) ran TOPS.
> > VAX-11/780 was a 32 bit mini that (usually) ran VMS.
>
> There is not such thing as "TOPS". There were 2 operating systems
> available from DEC for the PDP-10 architecture, named "Tops-10" and
> "TOPS-20". (There were others, such as MIT AI Lab's ITS, the Stanford AI
> Lab's WAITS, and BBN's TENEX.)

Yes I was using TOPS as a shorthand for "TOPS-10 or TOPS-20".

[Scott Lurndal]

Rich Alderson <ne...@alderson.users.panix.com> writes:
>sc...@slp53.sl.home (Scott Lurndal) writes:
>
>> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>>> On Thu, 03 Mar 2022 14:30:52 GMT
>>> sc...@slp53.sl.home (Scott Lurndal) wrote:
>
>>>> Can you refresh my memory on the advantages and disadvantages of the
>>>> PDP-10 vs. the VAX-11/780? From a technical standpoint, not from a
>
>>> PDP-10 was a 36 bit mainframe that (usually) ran TOPS.
>>> VAX-11/780 was a 32 bit mini that (usually) ran VMS.
>
>> What were the advantages, if any, of one family over the other family?
>
>VMS ran on supported hardware after 1983.

I was using VMS 1979-1983.

>
>The PDP-10 operating systems were mainframe oriented ab origine, unlike VMS.

VMS wasn't designed as a batch system, so far as I'm aware, although
it could certainly serve as such.

>
>> I'm quite aware of the hardware specifications.
>
>> How does TOPS DCL compare with VMS DCL?
>
>Again, there ain't no "TOPS".

Correction noted. Let's abstract from the jargon and talk more
generically about the user interface. Pros and Cons of MIC/PCL
vs. DCL.

Note that I spent most of the 80's writing mainframe operating
systems for Burroughs, so I've both batch and TS experience.
You've used one of the Burroughs boxen at the LCM, yourself.

>
>The facilities offered by both OSes are unrelated to "DCL" as understood by VMS
>and other PDP-11 oeprating systems.

Generically, then. How does the interactive user experience differ
between the Decsystem-10/20 and the VAX-11/780. I've read quite a few
PDP-10 advocates claiming superiority, but I've never seen any
data to back it up other than "I prefer this to that" or "I'm pissed
because DEC management killed Jupiter".

[Bob Eager]

On Thu, 03 Mar 2022 15:33:04 -0500, Rich Alderson wrote:

> sc...@slp53.sl.home (Scott Lurndal) writes:
>
>> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>>> On Thu, 03 Mar 2022 14:30:52 GMT sc...@slp53.sl.home (Scott Lurndal)
>>> wrote:
>
>>>> Can you refresh my memory on the advantages and disadvantages of the
>>>> PDP-10 vs. the VAX-11/780? From a technical standpoint, not from a
>
>>> PDP-10 was a 36 bit mainframe that (usually) ran TOPS.
>>> VAX-11/780 was a 32 bit mini that (usually) ran VMS.
>
>> What were the advantages, if any, of one family over the other family?
>
> VMS ran on supported hardware after 1983.

It is also true to say that it ran on supported hardware in 1977.


--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

[Stephen M. Jones]

I would like to apologize for confusing VMS users with my joke/reference.
Though Rich has provided some excellent background into the development of
TOPS-20. He was there and still is.

The "TOPS-20 Boot Camp for VMS Users" was in reference to the parody
in "Alice's PDP-10" which has a passage that goes a little like this:

...
And I put down my keyboard, and I switched buffers, and there ...
in the other buffer... centered in the other buffer... away from
everything else in the buffer... in parentheses, capital letters,
in reverse video, read the following words:

"Kid, have you taken the ``VMS for TOPS-20 managers'' course yet?"

I walked over to the man and I said "Mister, you got a lot of damned
gall asking me if I've taken the ``VMS for TOPS-20 managers'' course
yet. I mean... I mean... I mean, I'm sitting here on the bench, I'm
sitting here on the LCG SIG bench, 'cause you want to know if I'm
braindamaged enough trade my PDP-10 for partial credit on a system
that doesn't even handle filename completion after being a litterbug."

He looked at me and said "Kid, the front office don't like your kind,
so we're going to put you on our VAX/VMS mailing list." And friends,
somewhere down in the NE43 receiving room is a large trash barrel with
a big sign on it that says "VAX/VMS documents".
...

Hence the title of the SDF event: "TOPS-20 Boot Camp for VMS Users". And
it's really not just for VMS Users, but anyone interested in TOPS-20. There
will likely be more comparisons with Linux (a wildly popular operating system)
rather than with VMS (a mildly popular operating system).

You can hack anything that you want, with TECO and DDT.

References: https://www.hactrn.net/sra/alice/alices.pdp10

[Peter Flass]

I’ve used both, although my -10 knowledge is 50 years old and not as
in-depth as I’d like. I’d say that the PDP-10 was more RISCy, and a
programmer’s dream to program in MACRO.

--
Pete

[Peter Flass]

It would have to be hard to tell, since the VAX hardware was a lot faster
than the PDP-10. I enjoyed working with both systems.

--
Pete

[Dennis Boone]

> You can hack anything that you want, with TECO and DDT.

Excepting, of course, Alice.

De

[Paul Rubin]

Peter Flass <peter...@yahoo.com> writes:
> It would have to be hard to tell, since the VAX hardware was a lot faster
> than the PDP-10. I enjoyed working with both systems.

For the first N years, VAXes were much slower than the faster 10's.
Faster VAXes appeared later, and eventually overtook the 10 mostly due
to improved chip technology. The main VAX for a long time was the
original 11/780 (introduced 1977) which was the canonical 1 MIP machine.
A KL-10 (introduced 1975) was maybe 3x that, about equivalent(?) to the
VAX 8600 that that came out in 1984.

I don't know about today, but legend has it that a few 11/780's were
kept operational for decades after that model's obsolescence, to serve
as benchmark hosts for MIPs rating of newer cpus.

[Scott Lurndal]

d...@ihatespam.msu.edu (Dennis Boone) writes:
> > You can hack anything that you want, with TECO and DDT.
>
>Excepting, of course, Alice.

Thanks Arlo.

[Bob Eager]

I have the album and the movie.

[Rich Alderson]

Bob Eager <news...@eager.cx> writes:

> On Thu, 03 Mar 2022 15:33:04 -0500, Rich Alderson wrote:

>> sc...@slp53.sl.home (Scott Lurndal) writes:

>>> What were the advantages, if any, of one family over the other family?

>> VMS ran on supported hardware after 1983.

> It is also true to say that it ran on supported hardware in 1977.

The 4th generation of the PDP-10 line was canceled in May, 1983, although the
customer base was large enough (financially speaking) to force Digital to
provide hardware support until 1988 and software support until 1993, but there
were no more sales by Digital of PDP-10 hardware to new customers after May
1983.

So an advantage of the VAX and VMS over the PDP-10 systems was support after
1983. Got it?

[Rich Alderson]

Ahem A Rivet's Shot <ste...@eircom.net> writes:

> On 03 Mar 2022 15:24:16 -0500
> Rich Alderson <ne...@alderson.users.panix.com> wrote:

>> There is not such thing as "TOPS". There were 2 operating systems
>> available from DEC for the PDP-10 architecture, named "Tops-10" and
>> "TOPS-20". (There were others, such as MIT AI Lab's ITS, the Stanford AI
>> Lab's WAITS, and BBN's TENEX.)

> Yes I was using TOPS as a shorthand for "TOPS-10 or TOPS-20".

A bad habit, since the two operating systems shared exactly zero features and
exactly zero code.

[David Lesher]

Bob Eager <news...@eager.cx> writes:

>On Fri, 04 Mar 2022 22:14:54 +0000, Scott Lurndal wrote:

>> d...@ihatespam.msu.edu (Dennis Boone) writes:
>>> > You can hack anything that you want, with TECO and DDT.
>>>
>>>Excepting, of course, Alice.
>>
>> Thanks Arlo.

>I have the album and the movie.

What about the 8x10 glossy photographs with circles and arrows...?

--
A host is a host from coast to coast...............wb8foz@panix.com
& no one will talk to a host that's close..........................
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

[Ahem A Rivet's Shot]

On 4 Mar 2022 22:17:58 GMT

Bob Eager <news...@eager.cx> wrote:

> I have the album and the movie.

How about the anniversary recordings ? I have the thirtieth which
has some fun Nixon references.

[Johnny Billquist]

I am of course, late to the game. And the bootcamp have already
happened. So people might already know the answers and comments I'm
about to give, but anyway...

On 2022-03-03 21:33, Rich Alderson wrote:
> sc...@slp53.sl.home (Scott Lurndal) writes:
>
>> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>>> On Thu, 03 Mar 2022 14:30:52 GMT
>>> sc...@slp53.sl.home (Scott Lurndal) wrote:
>
>>>> Can you refresh my memory on the advantages and disadvantages of the
>>>> PDP-10 vs. the VAX-11/780? From a technical standpoint, not from a
>
>>> PDP-10 was a 36 bit mainframe that (usually) ran TOPS.
>>> VAX-11/780 was a 32 bit mini that (usually) ran VMS.
>
>> What were the advantages, if any, of one family over the other family?
>
> VMS ran on supported hardware after 1983.

True. Or perhaps you should have said "developed after 1983". Not sure
if I'd classify that as an advantage when trying to do some kind of
comparison between the systems, though.

> The PDP-10 operating systems were mainframe oriented ab origine, unlike VMS.

Not entirely sure what you mean by that, Rich.
As you noted, Tops-10 originated in the monitor for the PDP-6. Is that
enough to call it mainframe? And is that a good thing? Tops-10 wasn't
very fancy or capable in some ways, even though it had some nifty things.
TOPS-20 is a completely different thing (as you also observed), with a
much more capable and nice design, if you ask me. If definitely have
some features and capabilities that VMS lacked. But was it more
mainframe-oriented? What does that even mean? TOPS-20 was probably worse
from an execution point of view than VMS, requiring more resources to
get the job done. But VMS isn't really any kind of batch oriented
environment either...

>> I'm quite aware of the hardware specifications.
>
>> How does TOPS DCL compare with VMS DCL?
>
> Again, there ain't no "TOPS".

[...MIC and and PCL text deleted...]
I think the question wasn't about scripting, but interactive use here.
Tops-10 or TOPS-20 did not have DCL. I can't remember what the
interactive command line interpreter was called in Tops-10, but in
TOPS-10 it's EXEC.
EXEC is for most people a much nicer environment than DCL. Command name
completion, filename completion, guide words, interactive help... It's
just so much nicer than DCL.

Scripting wise, it's much more muddled.

Apart from user interaction, some things are better, and some are worse
in VMS. It's hard to answer a generic question like "how were they
different", or what advantages one had over the other, unless we want to
just talk specific technical details. Because the rest is pretty subjective.

Johnny

[Johnny Billquist]

On 2022-03-04 22:23, Paul Rubin wrote:
> Peter Flass <peter...@yahoo.com> writes:
>> It would have to be hard to tell, since the VAX hardware was a lot faster
>> than the PDP-10. I enjoyed working with both systems.
>
> For the first N years, VAXes were much slower than the faster 10's.

Not really. The KL10 was about 1.5 MIPS, while the original VAX-11/780
was 1 MIPS.

Speed parity was basically achieved with the VAX-11/785. After that, the
VAXen just were becoming faster.

The PDP-10 was never a speed daemon. It was helped a lot by being
offloaded for terminal I/O by the front end processor. But with the
spreading of ethernet, all of that work started moving back to the
PDP-10 itself, at which point you really felt the pain. 40 users on a
-2060 was usually not all that much fun, I can tell you. Heck, even 20
was painful.

> Faster VAXes appeared later, and eventually overtook the 10 mostly due
> to improved chip technology. The main VAX for a long time was the
> original 11/780 (introduced 1977) which was the canonical 1 MIP machine.
> A KL-10 (introduced 1975) was maybe 3x that, about equivalent(?) to the
> VAX 8600 that that came out in 1984.

KL-10 was about 1.5x. The 8600, introduced in 1984 was 4x the 11/780,
and was noticeably faster than the KL-10.

> I don't know about today, but legend has it that a few 11/780's were
> kept operational for decades after that model's obsolescence, to serve
> as benchmark hosts for MIPs rating of newer cpus.

I think I heard such stories, but I never put any value to them. Another
story/problem is that the original MIPS definition was also based on a
specific version of OS and compiler. And as these evolved, the
VAX-11/780 actually became significantly faster than 1 MIPS. Which
exposed a problem with the whole MIPS definition. And also meant keeping
any VAXen around for reference was pretty pointless.

And that's a big reason DEC themselves never used MIPS. They instead
talked about VUPs. Where a VAX-11/780 was by definition 1 VUP. And it
was more properly based on the actual processing speed, and not
depending on various software.

Johnny

[Peter Flass]

It’s been a lot of years, but doesn’t VMS DCL have command-line completion?
(sorry for all the included text, I can’t seem to get this darn thing to
select text to delete)

--
Pete

[Peter Flass]

IBM never used MIPS either, but rated processors relative to each other. I
always thought they did this to avoid comparisons to other vendors’
machines, but it was probably as much because it was meaningless, as you
say.

--
Pete

[Paul Rubin]

Johnny Billquist <b...@softjar.se> writes:
> The KL10 was about 1.5 MIPS, while the original VAX-11/780 was 1 MIPS.

Ah ok, for some reason I had thought the KL10 was faster than that.
EIther way: "36 bits -- a full DEC" ;-)

[Scott Lurndal]

Peter Flass <peter...@yahoo.com> writes:

>Johnny Billquist <b...@softjar.se> wrote:

>>
>> And that's a big reason DEC themselves never used MIPS. They instead
>> talked about VUPs. Where a VAX-11/780 was by definition 1 VUP. And it
>> was more properly based on the actual processing speed, and not
>> depending on various software.
>>
>> Johnny
>>
>
>IBM never used MIPS either, but rated processors relative to each other. I
>always thought they did this to avoid comparisons to other vendors’
>machines, but it was probably as much because it was meaningless, as you
>say.

Likewise, Burroughs used RPM (Relative Performance Metric) to rate their
machines. RPM was measured using the throughput of a selected set of
customer applications in banking, finance and back-office fields.

The application set was once ported to run on the dominant competitors machines
and run on one of the 3030 series (iirc) to get a baseline for comparison.

[Rich Alderson]

Johnny Billquist <b...@softjar.se> writes:

> I am of course, late to the game. And the bootcamp have already
> happened. So people might already know the answers and comments I'm
> about to give, but anyway...

> On 2022-03-03 21:33, Rich Alderson wrote:

>> The PDP-10 operating systems were mainframe oriented ab origine, unlike VMS.

> Not entirely sure what you mean by that, Rich.

> As you noted, Tops-10 originated in the monitor for the PDP-6. Is that
> enough to call it mainframe? And is that a good thing? Tops-10 wasn't
> very fancy or capable in some ways, even though it had some nifty things.

I have in personal collection an advertisement from a UK magazine of the
Scientific American sort for the PDP-6 which touts it as a large system
available both for batch and for timesharing operations for a large number
of users. It was clearly positioned to compete with IBM and the rest of the
Seven Dwarves. (I do not believe that they had contracted into the BUNCH by
the 2nd quarter of 1964.)

On those grounds I will claim that it was considered to be a mainframe. KO
clearly considered it to be such when he declared (following its failure in the
marketplace) that DEC would not compete with IBM.

> TOPS-20 is a completely different thing (as you also observed), with a much
> more capable and nice design, if you ask me. If definitely have some features
> and capabilities that VMS lacked. But was it more mainframe-oriented? What
> does that even mean? TOPS-20 was probably worse from an execution point of
> view than VMS, requiring more resources to get the job done. But VMS isn't
> really any kind of batch oriented environment either...

DEC positioned the DEC-20 and TOPS-20 as *replacements* for Tops-10 on the
earlier generations of the PDP-10. If we can agree that DEC marketed those as
mainframe systems, then we have to accept that the -20 was also intended as a
mainframe.

> [...MIC and and PCL text deleted...]
> I think the question wasn't about scripting, but interactive use here.
> Tops-10 or TOPS-20 did not have DCL. I can't remember what the
> interactive command line interpreter was called in Tops-10, but in
> TOPS-10 it's EXEC.

Most of the discussion of DCL which I see on comp.os.vms has to do with the
scripting features rather than interactive use, so that's what I tend to think
of when asked to compare the PDP-10 offerings to it.

On Tops-10, the command processor is part of the running monitor; TOPS-20 has
only a very very limited built-in command processor, called the Mini-EXEC, with
single character commands to G(et a monitor), S(tart the loaded monitor), and
possibly E(nter DDT on the monitor) but that might be a pipe dream.

I do not know VMS (or RSTS/E or RSX) internals. Is DCL a separate program,
like the TOPS-20 EXEC? Or an interaction with the monitor/kernel?

> EXEC is for most people a much nicer environment than DCL. Command name
> completion, filename completion, guide words, interactive help... It's
> just so much nicer than DCL.

You get no argument from me!

> Scripting wise, it's much more muddled.

> Apart from user interaction, some things are better, and some are worse
> in VMS. It's hard to answer a generic question like "how were they
> different", or what advantages one had over the other, unless we want to
> just talk specific technical details. Because the rest is pretty subjective.

Amen.

[Charlie Gibbs]

On 2022-03-06, Johnny Billquist <b...@softjar.se> wrote:

> I think I heard such stories, but I never put any value to them. Another
> story/problem is that the original MIPS definition was also based on a
> specific version of OS and compiler. And as these evolved, the
> VAX-11/780 actually became significantly faster than 1 MIPS. Which
> exposed a problem with the whole MIPS definition. And also meant keeping
> any VAXen around for reference was pretty pointless.

Hence that definition of MIPS:

Meaningless Indicator of Processor Speed

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgi...@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

[Scott Lurndal]

Rich Alderson <ne...@alderson.users.panix.com> writes:
>Johnny Billquist <b...@softjar.se> writes:
>

>
>I do not know VMS (or RSTS/E or RSX) internals. Is DCL a separate program,
>like the TOPS-20 EXEC? Or an interaction with the monitor/kernel?

VMS is an odd beast in that respect. The VAX had a four privilege
rings (aside: interestingly enough, the relatively recent ARMv8
architecture also has four privilege rings (with a fifth coming soon)).

The kernel ran in the most privileged ring, Kernel Mode. RMS (mainly
derived from RSX-11, IIRC, and authored by Andy Goldstein (IIRC again))
ran in the next most privileged ring (Executive Mode). The Command
Interpreter (DCL) ran in the next ring (Supervisor Mode), and user
applications ran in the least privileged ring (User Mode).

As with most[*] ring-based privilege architectures, ring switches were
expensive and I believe once they went to Alpha, that architecture was
pretty much dead.

>
>> EXEC is for most people a much nicer environment than DCL. Command name
>> completion, filename completion, guide words, interactive help... It's
>> just so much nicer than DCL.

I didn't miss any of those features during the four years (1979-1983) that
I was doing systems programming on a four-vax cluster (with MA-780!), but
then I had been using TSS8.24 prior to that :-).

[*] most non-risc-based architectures, anyway. ARMv8 ring switches
while not free, can be quite efficient - far different from Intel
ring switches, for which three generations of ring-switch instructions
were created over the decades to make them more efficient.

[Johnny Billquist]

On 2022-03-06 19:34, Peter Flass wrote:
> Johnny Billquist <b...@softjar.se> wrote:
>> I am of course, late to the game. And the bootcamp have already
>> happened. So people might already know the answers and comments I'm
>> about to give, but anyway...

>>>> How does TOPS DCL compare with VMS DCL?
>>>
>>> Again, there ain't no "TOPS".
>>
>> [...MIC and and PCL text deleted...]
>> I think the question wasn't about scripting, but interactive use here.
>> Tops-10 or TOPS-20 did not have DCL. I can't remember what the
>> interactive command line interpreter was called in Tops-10, but in
>> TOPS-10 it's EXEC.
>> EXEC is for most people a much nicer environment than DCL. Command name
>> completion, filename completion, guide words, interactive help... It's
>> just so much nicer than DCL.
>>
>> Scripting wise, it's much more muddled.
>>
>> Apart from user interaction, some things are better, and some are worse
>> in VMS. It's hard to answer a generic question like "how were they
>> different", or what advantages one had over the other, unless we want to
>> just talk specific technical details. Because the rest is pretty subjective.
>>
>> Johnny
>>
>
> It’s been a lot of years, but doesn’t VMS DCL have command-line completion?
> (sorry for all the included text, I can’t seem to get this darn thing to
> select text to delete)

No, it don't. On VAX, there was a hack (from DECUS?) called DCLCOMPLETE
which sortof added this. But I don't think it was ever made to work on
any other hardware platform, it was sortof not working perfectly, and it
was definitely not something DEC ever included.

Johnny

[D.J.]

On Thu, 03 Mar 2022 14:30:52 GMT, sc...@slp53.sl.home (Scott Lurndal)

wrote:

>"Stephen M. Jones" <s...@ma.sdf.org> writes:
>>On Saturday March 5th, 2022 SDF will kick off its TOPS-20 Boot Camp series
>>on https://twitch.tv/sdfpubnix at 1PM Pacific Time (9PM GMT). Registration
>>is open at https://twenex.org/?bootcamp which includes access to SDF's
>>XKL Toad-2 and is offered at no cost.
>>
>>If you cannot attend an archive of the live stream (approximately
>>1 hour long) will be posted to the fediverse via SDF's Peertube instance,
>>https://toobnix.org
>>
>>Looking forward to doing a "TOPS-20 Boot Camp for VMS Users", though any User
>>of any operating system background is certainly welcome, kid.
>>
>

>Can you refresh my memory on the advantages and disadvantages of the PDP-10

>vs. the VAX-11/780? From a technical standpoint, not from a nostalgia or DEC politics
>standpoint? My migration at the time was from a PDP-8 to PDP-11 to VAX-11.

I didn't have access to the 11/780. The campus I was on had the
11/730. What differences for it ?

--
Jim

[Johnny Billquist]

On 2022-03-07 16:07, Scott Lurndal wrote:
> Rich Alderson <ne...@alderson.users.panix.com> writes:
>> Johnny Billquist <b...@softjar.se> writes:
>>
>
>>
>> I do not know VMS (or RSTS/E or RSX) internals. Is DCL a separate program,
>> like the TOPS-20 EXEC? Or an interaction with the monitor/kernel?
>
> VMS is an odd beast in that respect. The VAX had a four privilege
> rings (aside: interestingly enough, the relatively recent ARMv8
> architecture also has four privilege rings (with a fifth coming soon)).
>
> The kernel ran in the most privileged ring, Kernel Mode. RMS (mainly
> derived from RSX-11, IIRC, and authored by Andy Goldstein (IIRC again))
> ran in the next most privileged ring (Executive Mode). The Command
> Interpreter (DCL) ran in the next ring (Supervisor Mode), and user
> applications ran in the least privileged ring (User Mode).
>
> As with most[*] ring-based privilege architectures, ring switches were
> expensive and I believe once they went to Alpha, that architecture was
> pretty much dead.

People are always making the multiple processor modes a thing way bigger
than it is.

To comment more towards what Rich was thinking/asking, DCL is not a
normal user program. It is possible to have other "shells" than DCL,
which would live at the same level as DCL, but that almost was
non-existant in real life. People instead have shells as programs
running while DCL is still lurking in the background.

So it's less flexible than in Unix or TOPS-20, where it's just a program
like any other.

RSX is in a way maybe the most weird of them all. In the goal to
minimize memory and process resources, there is usually no program
associated with your terminal when you are at the DCL prompt. Instead,
it's all the responsibility of the terminal driver. Only when you've
completed a line and hit enter will DCL (or MCR) be started for you, to
process the line you typed.

In VMS, DCL is there the whole time.

>>> EXEC is for most people a much nicer environment than DCL. Command name
>>> completion, filename completion, guide words, interactive help... It's
>>> just so much nicer than DCL.
>
> I didn't miss any of those features during the four years (1979-1983) that
> I was doing systems programming on a four-vax cluster (with MA-780!), but
> then I had been using TSS8.24 prior to that :-).

It's one of those things where if you never used it, you don't
understand how much it means, and how much you'll miss it if it goes away.

It's very similar to how you'll feel today if someone throws /bin/sh at
you, and you are used to tcsh or bash. No filename completion, no line
editing, no interactive information, no nothing. It's like going back to
the dark ages.

And TOPS-20 EXEC is *better* than tcsh or bash...

Johnny

[Johnny Billquist]

You are not alone. Lots of people seem to think the KL10 was way faster
than it was.

Anyway, I still appreciate the 36-bit quote. But deep down inside, I'm a
PDP-11 person. :-D

Johnny

[Scott Lurndal]

From the perspective of the average user, there was no difference
between the 11/730, 11/750 or 11/780 other than absolute performance.

[Scott Lurndal]

For what it's worth, I've been using ksh since 1989 and while it supports
filename completion, I've never used it (since I use vi-style command
line editing, it takes more than just the tab key to invoke completion).

[Peter Flass]

I’m always amazed when I try to use some piece of software I used to use
years ago how primitive it seems now. Back then non-ISPF TSO or DOS EDLIN
seemed like usable, if not much fun, pieces of software. Playing with old
systems like TSS or Multics it seems like my biggest problem is lack of a
decent editor.

--
Pete

[Johnny Billquist]

Never used ksh, but it still certainly sounds like miles from sh.

I don't expect people will really get involved in TOPS-20 EXEC now, but
if you were to use it for a while, I think you'd start see my point. :-)

If you ever use Cisco gear, you might have gotten some taste of it as
well...

Johnny

[Scott Lurndal]

Yeah. I occasionally fire up tss8.24 on simh just to recall the old days;
using PIP to copy files seems so 1974. I also fire up the HP-3000 MPE
on simh as I used that after the PDP-8, but before the VAX. Interactively,
it was better than tss8.24, but compared to DCL, the command language was
limited (no scripting capability, for example) - however, the concept of
PASS files was an interesting feature - during a compile-link-run job
the output of a step could be written to $NEWPASS and the next step would
read from $OLDPASS; a transient unnamed temporary disk file.

$ BASICCOMP FILE.BAS
$ PREP $OLDPASS, $NEWPASS
$ RUN $OLDPASS

[Johnny Billquist]

On 2022-03-07 02:43, Rich Alderson wrote:
> Johnny Billquist <b...@softjar.se> writes:
>
>> I am of course, late to the game. And the bootcamp have already
>> happened. So people might already know the answers and comments I'm
>> about to give, but anyway...
>
>> On 2022-03-03 21:33, Rich Alderson wrote:
>
>>> The PDP-10 operating systems were mainframe oriented ab origine, unlike VMS.
>
>> Not entirely sure what you mean by that, Rich.
>
>> As you noted, Tops-10 originated in the monitor for the PDP-6. Is that
>> enough to call it mainframe? And is that a good thing? Tops-10 wasn't
>> very fancy or capable in some ways, even though it had some nifty things.
>
> I have in personal collection an advertisement from a UK magazine of the
> Scientific American sort for the PDP-6 which touts it as a large system
> available both for batch and for timesharing operations for a large number
> of users. It was clearly positioned to compete with IBM and the rest of the
> Seven Dwarves. (I do not believe that they had contracted into the BUNCH by
> the 2nd quarter of 1964.)
>
> On those grounds I will claim that it was considered to be a mainframe. KO
> clearly considered it to be such when he declared (following its failure in the
> marketplace) that DEC would not compete with IBM.

Fair enough. I would still consider both Tops-10 and TOPS-20 to be very
interactive centered. Not really mainframe, except for size and approach
to solve some problems using smaller processors attach and offload stuff
to them.

>> TOPS-20 is a completely different thing (as you also observed), with a much
>> more capable and nice design, if you ask me. If definitely have some features
>> and capabilities that VMS lacked. But was it more mainframe-oriented? What
>> does that even mean? TOPS-20 was probably worse from an execution point of
>> view than VMS, requiring more resources to get the job done. But VMS isn't
>> really any kind of batch oriented environment either...
>
> DEC positioned the DEC-20 and TOPS-20 as *replacements* for Tops-10 on the
> earlier generations of the PDP-10. If we can agree that DEC marketed those as
> mainframe systems, then we have to accept that the -20 was also intended as a
> mainframe.

I think part of the problem that this all becomes just labels for
marketing. Does it mean anything, and if so - what?

I don't think the differences between VMS and the PDP-10 OSes are that
radical. They are basically useful and used in the same type of
environments.

>> [...MIC and and PCL text deleted...]
>> I think the question wasn't about scripting, but interactive use here.
>> Tops-10 or TOPS-20 did not have DCL. I can't remember what the
>> interactive command line interpreter was called in Tops-10, but in
>> TOPS-10 it's EXEC.
>
> Most of the discussion of DCL which I see on comp.os.vms has to do with the
> scripting features rather than interactive use, so that's what I tend to think
> of when asked to compare the PDP-10 offerings to it.

Fair enough. I just got the impression that the OP in this case was
trying to understand the differences perceived by an interactive user.

>> EXEC is for most people a much nicer environment than DCL. Command name
>> completion, filename completion, guide words, interactive help... It's
>> just so much nicer than DCL.
>
> You get no argument from me!

:-)

Johnny

[Scott Lurndal]

Johnny Billquist <b...@softjar.se> writes:
>On 2022-03-07 18:07, Scott Lurndal wrote:
>> Johnny Billquist <b...@softjar.se> writes:
>>> On 2022-03-07 16:07, Scott Lurndal wrote:
>>>> Rich Alderson <ne...@alderson.users.panix.com> writes:
>>>>> Johnny Billquist <b...@softjar.se> writes:
>>>>>
>>
>>>
>>> It's very similar to how you'll feel today if someone throws /bin/sh at
>>> you, and you are used to tcsh or bash. No filename completion, no line
>>> editing, no interactive information, no nothing. It's like going back to
>>> the dark ages.
>>
>> For what it's worth, I've been using ksh since 1989 and while it supports
>> filename completion, I've never used it (since I use vi-style command
>> line editing, it takes more than just the tab key to invoke completion).
>
>Never used ksh, but it still certainly sounds like miles from sh.

Indeed, ksh is quite powerful - you can even access arbitrary shared
library functions linked in at runtime; has associative arrays and
a host of other useful scripting features (ksh93).

>
>I don't expect people will really get involved in TOPS-20 EXEC now, but
>if you were to use it for a while, I think you'd start see my point. :-)

I find most of those old command interpreters limited and unusable after
using the korn shell for so many years. I could give TOPS-20 EXEC
a try on simh someday to see, but I don't expect to like it much;
I suppose I could try to port the COBOL startrek game to COBOL on
the PDP-10 someday when I have absolutely nothing else to do :-)

>
>If you ever use Cisco gear, you might have gotten some taste of it as
>well...

I got an offer to join the IOS team (and an offer from NetApp at the
same time), but turned them down and went to SGI instead - both Cisco
and Netapp would have been financially more lucrative in the long run, sadly.

[Dan Espen]

sc...@slp53.sl.home (Scott Lurndal) writes:

> Johnny Billquist <b...@softjar.se> writes:
>>On 2022-03-07 18:07, Scott Lurndal wrote:
>>> Johnny Billquist <b...@softjar.se> writes:
>>>> On 2022-03-07 16:07, Scott Lurndal wrote:
>>>>> Rich Alderson <ne...@alderson.users.panix.com> writes:
>>>>>> Johnny Billquist <b...@softjar.se> writes:
>>>>>>
>>>
>>>>
>>>> It's very similar to how you'll feel today if someone throws /bin/sh at
>>>> you, and you are used to tcsh or bash. No filename completion, no line
>>>> editing, no interactive information, no nothing. It's like going back to
>>>> the dark ages.
>>>
>>> For what it's worth, I've been using ksh since 1989 and while it supports
>>> filename completion, I've never used it (since I use vi-style command
>>> line editing, it takes more than just the tab key to invoke completion).
>>
>>Never used ksh, but it still certainly sounds like miles from sh.
>
> Indeed, ksh is quite powerful - you can even access arbitrary shared
> library functions linked in at runtime; has associative arrays and
> a host of other useful scripting features (ksh93).

ksh has lots of good stuff, but miles from sh doesn't seem right.
It's very much like sh to a casual user.

--
Dan Espen

[Ahem A Rivet's Shot]

On Mon, 7 Mar 2022 20:18:28 +0100
Johnny Billquist <b...@softjar.se> wrote:

> On 2022-03-07 18:07, Scott Lurndal wrote:
> > Johnny Billquist <b...@softjar.se> writes:
> >> On 2022-03-07 16:07, Scott Lurndal wrote:
> >>> Rich Alderson <ne...@alderson.users.panix.com> writes:
> >>>> Johnny Billquist <b...@softjar.se> writes:
> >>>>
> >
> >>
> >> It's very similar to how you'll feel today if someone throws /bin/sh at
> >> you, and you are used to tcsh or bash. No filename completion, no line
> >> editing, no interactive information, no nothing. It's like going back
> >> to the dark ages.
> >
> > For what it's worth, I've been using ksh since 1989 and while it
> > supports filename completion, I've never used it (since I use vi-style
> > command line editing, it takes more than just the tab key to invoke
> > completion).
>
> Never used ksh, but it still certainly sounds like miles from sh.

It's surprisingly close - basically sh with history and filename
completion added, much of bash history manipulation comes from ksh the rest
from csh.

[Scott Lurndal]

by design.

[Vir Campestris]

TOPS-10 was where I first met assembler.

I thought the KL10 was _slower_ than that.

And how come I can still remember the instruction word format
(9-4-1-4-18) 40 years later?

Andy

[Rich Alderson]

sc...@slp53.sl.home (Scott Lurndal) writes:

> Rich Alderson <ne...@alderson.users.panix.com> writes:
>> Johnny Billquist <b...@softjar.se> writes:

>> I do not know VMS (or RSTS/E or RSX) internals. Is DCL a separate program,
>> like the TOPS-20 EXEC? Or an interaction with the monitor/kernel?

> VMS is an odd beast in that respect. The VAX had a four privilege
> rings (aside: interestingly enough, the relatively recent ARMv8
> architecture also has four privilege rings (with a fifth coming soon)).

> The kernel ran in the most privileged ring, Kernel Mode. RMS (mainly
> derived from RSX-11, IIRC, and authored by Andy Goldstein (IIRC again))
> ran in the next most privileged ring (Executive Mode). The Command
> Interpreter (DCL) ran in the next ring (Supervisor Mode), and user
> applications ran in the least privileged ring (User Mode).

Interestingly, the *2nd generation* PDP-10, the KI-10 processor, implemented a
4-level privilege model: Kernel, Executive, Public, and User. Tops-10 ran
mostly in Executive mode, with only some of the most sensitive routines done in
Kernel mode. Public mode was a user-level mode (i.e., no privileged
instructions such as I/O operations) which allowed for system services similar
to dynamic libraries in modern Unix-style operating systems, but serving a
different purpose. User mode was the bog standard mode for any program not
requiring elevated privileges.

(Public mode was used by the system services such as spoolers so that user
programs did not need to use system calls to interact with unit record
equipment.)

> As with most[*] ring-based privilege architectures, ring switches were
> expensive and I believe once they went to Alpha, that architecture was
> pretty much dead.

The KI model was not ring-based in the way that I understand rings (based on
early Multics writings, mostly); it was simply a matter of a couple of bits in
the process status.

[Scott Lurndal]

It's changing between rings that is the primary issue as that often
includes a change in the memory context (e.g. x86 segment, active page
table) resulting in a performance hit. E.g. UUO's/system calls.

[Scott Lurndal]

What really killed it on the VAX was multiple ring changes for many
operations (file operations executed in executive mode, and they
called kernel mode facilities like $QIO/$QIOW). On the other hand,
user mode could make requests to DCL with a change mode to supervisor
call.

[Johnny Billquist]

On 2022-03-07 23:58, Scott Lurndal wrote:
> sc...@slp53.sl.home (Scott Lurndal) writes:

>> It's changing between rings that is the primary issue as that often
>> includes a change in the memory context (e.g. x86 segment, active page
>> table) resulting in a performance hit. E.g. UUO's/system calls.
>
> What really killed it on the VAX was multiple ring changes for many
> operations (file operations executed in executive mode, and they
> called kernel mode facilities like $QIO/$QIOW). On the other hand,
> user mode could make requests to DCL with a change mode to supervisor
> call.

What do you mean "killed it on the VAX"? Changing mode means trapping to
the OS. Doing a system call means trapping to the OS. Is a change mode
any more costly than any system call? No.

Are you claiming there is some extra performance penalty here?

You could argue that the changing of modes carried a performance
benefit, since it meant you did not need to switch context to another
process, and you did not need to flush TLBs and so on, since the memory
mapping is unchanged. Changing modes effectively just changed what parts
of memory was accessible, apart from kernel mode which allowed some
instructions not allowed otherwise.
And that is also why implementing the whole thing on a processor with
fewer modes isn't really a big deal. It's just a question of what your
page table looks like. And that can obviously be changed whenever you
trap into the OS anyway.

Johnny

[D.J.]

On Mon, 07 Mar 2022 17:03:45 GMT, sc...@slp53.sl.home (Scott Lurndal)

I know the 730 I used was slower than the 780 on main campus. I think
it used fewer vt102 terminals as well.

One of the professors tried to run ADA on the 730. Incredibly slow.
--
Jim

[Fred Smith]

The only advantage with the 730 I used was it had the REAL*16 (128 bit IEEE floating point) built in, the 750 & 780 machines required upgrades. So the 730 was actually faster for operations using real*16 operations.

It was also faster because nobody wanted to use it.

[Andreas Eder]

On Mo 07 Mär 2022 at 11:47, Peter Flass <peter...@yahoo.com> wrote:

> Scott Lurndal <sc...@slp53.sl.home> wrote:
> I’m always amazed when I try to use some piece of software I used to use
> years ago how primitive it seems now. Back then non-ISPF TSO or DOS EDLIN
> seemed like usable, if not much fun, pieces of software. Playing with old
> systems like TSS or Multics it seems like my biggest problem is lack of a
> decent editor.

Well, on Multics you have Emacs!
That should be enough for everyone :-)

'Andreas

[Peter Flass]

Some systems (Sigma) had different register sets for different processor
modes. Memory is cheap these days, why not different caches?

--
Pete

[Peter Flass]

I’ve managed to get fifty years in without having to learn emacs. I don’t
want to have to start now.

--
Pete

[Scott Lurndal]

Indeed, it's difficult to compare systems designed 40 to 50 years ago
with modern processors.

But even today, nobody uses more than two of the four rings on Intel
processors. (well, technically, one can consider VM-X/SVM a ring,
and SMM mode can also be considered a ring, and in both cases,
crossing the ring boundary isn't cheap - see VMEXIT).

[Johnny Billquist]

On 2022-03-08 05:13, Fred Smith wrote:
> On 2022-03-08, D.J <chuckt...@gmail.com> wrote:
>> On Mon, 07 Mar 2022 17:03:45 GMT, sc...@slp53.sl.home (Scott Lurndal)
>> wrote:
>>> D.J. <chuckt...@gmail.com> writes:
>>>> I didn't have access to the 11/780. The campus I was on had the
>>>> 11/730. What differences for it ?
>>>
>> >From the perspective of the average user, there was no difference
>>> between the 11/730, 11/750 or 11/780 other than absolute performance.
>>
>> I know the 730 I used was slower than the 780 on main campus. I think
>> it used fewer vt102 terminals as well.

Like Chuck said. Performance.

>> One of the professors tried to run ADA on the 730. Incredibly slow.
>> --
>> Jim
>
> The only advantage with the 730 I used was it had the REAL*16 (128 bit IEEE floating point) built in, the 750 & 780 machines required upgrades. So the 730 was actually faster for operations using real*16 operations.

VAX don't do IEEE floating point. But yes, H_FLOAT in hardware was an
addon on those machines. Otherwise it had to be done in software, which
was indeed slower.

> It was also faster because nobody wanted to use it.

Only if the larger machines were in use, of course. :-)
But yeah. Being along on a machine usually helped.

Johnny

[Peter Flass]

OS/2 uses three (and no, it’s not completely dead yet)

--
Pete

[Charlie Gibbs]

I took a look at emacs a couple of years ago.
I found its mindset to be too foreign for me,
e.g. in things like tab handling.

My fingers speak vi. That's usually enough.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgi...@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

[Vir Campestris]

On 08/03/2022 14:49, Peter Flass wrote:
> Some systems (Sigma) had different register sets for different processor
> modes. Memory is cheap these days, why not different caches?

Because you'll get more bang for your buck by having one big cache
instead of two small ones.

Cache still isn't cheap.

Andy

[Scott Lurndal]

Indeed. However, many high-end server processors[*] implement some form of
programmable cache partitioning where portions of the cache (at any or
all levels of hierarchy) can be reserved for certain applications (or rings), and
then there are PCI Express steering tags, which allow inbound DMA to
be directed to one or more of the cache levels without going through
memory first.

[*] e.g. ARMv8 processors like the Neoverse N2 with MPAM.

[Bob Eager]

On Tue, 08 Mar 2022 19:47:05 +0000, Charlie Gibbs wrote:

> I took a look at emacs a couple of years ago.
> I found its mindset to be too foreign for me,
> e.g. in things like tab handling.
>
> My fingers speak vi. That's usually enough.

I have exactly the opposite. I started UNIX in 1975, although vi took a
while to appear. I continued to use 'ed' because my terminal was a bit
basic.

Then I got a PC with a simplified emacs that was marketed as part of a
'word processor'. My fingers know that (but I also use 'ed' in extremis,
usually in single user mode on a basic console).



--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

[Charles Richmond]

On 3/6/2022 12:34 PM, Peter Flass wrote:
> Johnny Billquist <b...@softjar.se> wrote:

>> On 2022-03-04 22:23, Paul Rubin wrote:
>>> Peter Flass <peter...@yahoo.com> writes:

>>>> It would have to be hard to tell, since the VAX hardware was a lot faster
>>>> than the PDP-10. I enjoyed working with both systems.
>>>
>>> For the first N years, VAXes were much slower than the faster 10's.
>>
>> Not really. The KL10 was about 1.5 MIPS, while the original VAX-11/780
>> was 1 MIPS.
>>
>> Speed parity was basically achieved with the VAX-11/785. After that, the
>> VAXen just were becoming faster.
>>
>> The PDP-10 was never a speed daemon. It was helped a lot by being
>> offloaded for terminal I/O by the front end processor. But with the
>> spreading of ethernet, all of that work started moving back to the
>> PDP-10 itself, at which point you really felt the pain. 40 users on a
>> -2060 was usually not all that much fun, I can tell you. Heck, even 20
>> was painful.
>>
>>> Faster VAXes appeared later, and eventually overtook the 10 mostly due
>>> to improved chip technology. The main VAX for a long time was the
>>> original 11/780 (introduced 1977) which was the canonical 1 MIP machine.
>>> A KL-10 (introduced 1975) was maybe 3x that, about equivalent(?) to the
>>> VAX 8600 that that came out in 1984.
>>
>> KL-10 was about 1.5x. The 8600, introduced in 1984 was 4x the 11/780,
>> and was noticeably faster than the KL-10.
>>
>>> I don't know about today, but legend has it that a few 11/780's were
>>> kept operational for decades after that model's obsolescence, to serve
>>> as benchmark hosts for MIPs rating of newer cpus.
>>
>> I think I heard such stories, but I never put any value to them. Another
>> story/problem is that the original MIPS definition was also based on a
>> specific version of OS and compiler. And as these evolved, the
>> VAX-11/780 actually became significantly faster than 1 MIPS. Which
>> exposed a problem with the whole MIPS definition. And also meant keeping
>> any VAXen around for reference was pretty pointless.
>>
>> And that's a big reason DEC themselves never used MIPS. They instead
>> talked about VUPs. Where a VAX-11/780 was by definition 1 VUP. And it
>> was more properly based on the actual processing speed, and not
>> depending on various software.
>>
>> Johnny
>>
>
> IBM never used MIPS either, but rated processors relative to each other. I
> always thought they did this to avoid comparisons to other vendors’
> machines, but it was probably as much because it was meaningless, as you
> say.
>
MIPS in Outer Space

The processor used in the original Sony PlayStation is currently guiding
a space probe the size of a grand piano towards Pluto? Yep, the same
MIPS R3000 CPU that once ran Final Fantasy VII and Metal Gear Solid was
repurposed by NASA in 2006 to fire thrusters, monitor sensors, and
transmit data from the New Horizons space probe.

https://www.theverge.com/2015/1/15/7551365/playstation-cpu-powers-new-horizons-pluto-probe

--

Charles Richmond


--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

[Charles Richmond]

"The Dinner Cafe's food stays hot!!! You can feel the food burning in
your stomach hours later..." ;-)

And how many advertising jingles can you sing... from television
commercials that were shown 40 years ago??? I can sing quite a few...
Perhaps I can make money with this... people might pay me *not* to
sing!!! ;-)

"A gentleman is a man who can play the bagpipes... and doesn't."

[Peter Flass]

Charles Richmond <code...@aquaporin4.com> wrote:
> On 3/7/2022 4:02 PM, Vir Campestris wrote:
>> On 07/03/2022 16:53, Johnny Billquist wrote:
>>> On 2022-03-06 20:17, Paul Rubin wrote:
>>>> Johnny Billquist <b...@softjar.se> writes:
>>>>> The KL10 was about 1.5 MIPS, while the original VAX-11/780 was 1 MIPS.
>>>>
>>>> Ah ok, for some reason I had thought the KL10 was faster than that.
>>>> EIther way: "36 bits -- a full DEC"  ;-)
>>>
>>> You are not alone. Lots of people seem to think the KL10 was way
>>> faster than it was.
>>>
>>> Anyway, I still appreciate the 36-bit quote. But deep down inside, I'm
>>> a PDP-11 person. :-D
>>>
>>
>> TOPS-10 was where I first met assembler.
>>
>> I thought the KL10 was _slower_ than that.
>>
>> And how come I can still remember the instruction word format
>> (9-4-1-4-18) 40 years later?
>>
>> Andy
>>
>
> "The Dinner Cafe's food stays hot!!! You can feel the food burning in
> your stomach hours later..." ;-)
>
> And how many advertising jingles can you sing... from television
> commercials that were shown 40 years ago??? I can sing quite a few...
> Perhaps I can make money with this... people might pay me *not* to
> sing!!! ;-)
>

Do you have a GoFundMe page?

> "A gentleman is a man who can play the bagpipes... and doesn't."
>
>



--

Pete

[Anne & Lynn Wheeler]

Peter Flass <peter...@yahoo.com> writes:
> IBM never used MIPS either, but rated processors relative to each other. I
> always thought they did this to avoid comparisons to other vendors’
> machines, but it was probably as much because it was meaningless, as you
> say.

IBM tries stamp out industry standard benchmark numbers for their
mainframes. I had worked with Jim Gray at IBM Research on System/R
(original SQl/Relational implementation) and he then palmed off some
stuff on me when he left for Tandem ... where he pioneers DBMS TPC
benchmarks
http://www.tpc.org/information/who/gray5.asp

Periodically some mainframe numbers manage to leak. Industry standard
MIPS benchmark wasn't instructions/sec but number of program iterations
compared to the standard's processor ... assumed to be one MIP machine
(and easier to find for IBM's non-mainframe systems).

IBM mainframe this century

z900, 16 processors, 2.5BIPS (156MIPS/proc), Dec2000
z990, 32 processors, 9BIPS, (281MIPS/proc), 2003
z9, 54 processors, 18BIPS (333MIPS/proc), July2005
z10, 64 processors, 30BIPS (469MIPS/proc), Feb2008
z196, 80 processors, 50BIPS (625MIPS/proc), Jul2010
EC12, 101 processors, 75BIPS (743MIPS/proc), Aug2012
z13, 140 processors, 100BIPS (710MIPS/proc), Jan2015
z14, 170 processors, 150BIPS (862MIPS/proc), Aug2017
z15, 190 processors, 190BIPS* (1000MIPS/proc), Sep2019

* pubs say z15 1.25 times z14 (1.25*150BIPS or 190BIPS)
* z16, 200?? processors, ???BIPS (???MIPS/proc),

Max configured z196 was $30M ($600,000/BIPS) and in that timeframe,
cloud megadatacenters (with half million or more systems) standard was
E5-2600 blades benchmarked at 500BIPS. This was shortly before IBM sold
off its blade server business ... but IBM had E5-2600 base list price of
$1815 ($3.60/BIPS). However, cloud megadatacenters had been saying for
at least a decade that they assembled their own systems for 1/3rd the
cost of brand name blade servers ($1.20/BIPS) ... likely contributing to
IBM selling off its blade server business ... this was also about the
time that server chip maker press said that they were shipping half
their product directly to cloud megadatacenters.

z196 pubs also claimed that over half the per processor performance
improvement from z10 to z196 was the introduction of cache miss (memory
latency) compensation features (that had been in other platforms in some
cases for decades) ... out-of-order execution, branch prediction,
speculative execution, etc.

Big cloud operators (with dozen or more megadatacenters around the
world, each with half million or more systems) had so drastically
reduced their system costs that power & cooling were becoming
increasingly large part of their costs ... and they were putting
pressure on Intel/AMD to significantly increase computational power
efficiency (and looking at moving to ARM, originally designed for low
power, battery use, computational power efficiency offsetting increasing
the number of systems). They had so decreased cost of systems that they
could justify complete upgrade of all systems when there was improvement
computational power efficiency. Also start seeing TPC including
computational efficiency in benchmarks, being able to calculate
electrical power cost per transaction ... and IBM still participates for
their non-mainframe systems.
https://www.tpc.org/tpcc/results/tpcc_results5.asp?orderby=hardware

trivia: 50+ yrs ago, IBM 195 mainframe had out-of-order execution but
conditional branches drained the pipeline ... so most 360&370 codes ran
at half the 195 throughput. Shortly after joining IBM, the 195 group
tried to suck me into helping with hyperthreading the 195 ... simulating
two processor with two threads, each running at half machine throughput.
In this description of the shutdown of ACS/360 (executives were afraid
it would advance the state of art too fast and IBM would loose control
of the market) ... there is reference to multithreading patents
https://people.cs.clemson.edu/~mark/acs_end.html

new work for 195 (including multithread) was canceled when it was
decided to add "virtual memory" to all 370s ... and it wasn't believed
that adding virtual memory to 195 was practical. Also claims that at the
time, MVT/MVS two-processor SMP systems were claimed to only have
1.2-1.5 system throughput of single processor (because of their
multiprocessor system software overhead) ... which would have more than
offset any benefit of having a multithreaded (simulated two processor)
195.

other trivia: in the morph from cp67->vm370, they simplified and/or
dropped (including dropping cp67 multiprocessor support). after joining
IBM, one of my hobbies was enhanced production operating systems for
internal datacenters ... including world-wide, sales&market support
"HONE" systems. The US HONE systems had been consolidated in Palo Alto
in the mid-70s (when facebook 1st moves into silicon valley, it was into
a new bldg built next door to the former US HONE datacenter). Their
VM370 was enhanced to have eight loosely-coupled (cluster, shared DASD)
single-system image, aka cluster with load balancing and fall-over
across the complex. I had added lots of CP67 features/function back into
VM370 and then (initially for HONE) added tightly-coupled (shared
memory) multiprocessor into VM370 release 3 ... giving them 16 processor
complex (at the time I considered largest IBM mainframe single-system
image complex; some ACP/TPF complexes may have had eight loosely-coupled
system complex but ACP/TPF didn't have tightly-coupled support so was
limited to one processor/system), With very short multiprocessor
pathlengths and some games with "cache affinity" ... could get two
processor machine with twice the throughput of single processor machine
(improved cache hit rate offsetting the multiprocessor software
overhead).

--
virtualization experience starting Jan1968, online at home since Mar1970

[Ahem A Rivet's Shot]

On Fri, 23 Dec 2022 10:34:13 -1000
Anne & Lynn Wheeler <ly...@garlic.com> wrote:

> Big cloud operators (with dozen or more megadatacenters around the
> world, each with half million or more systems) had so drastically
> reduced their system costs that power & cooling

I think the cleverest twist in system cooling has to be the trick of
immersing the whole thing in an inert fluid that boils at 50C with a
fan assisted condenser at the top.

[Anne & Lynn Wheeler]

Anne & Lynn Wheeler <ly...@garlic.com> writes:
> IBM mainframe this century
>
> z900, 16 processors, 2.5BIPS (156MIPS/proc), Dec2000
> z990, 32 processors, 9BIPS, (281MIPS/proc), 2003
> z9, 54 processors, 18BIPS (333MIPS/proc), July2005
> z10, 64 processors, 30BIPS (469MIPS/proc), Feb2008
> z196, 80 processors, 50BIPS (625MIPS/proc), Jul2010
> EC12, 101 processors, 75BIPS (743MIPS/proc), Aug2012
> z13, 140 processors, 100BIPS (710MIPS/proc), Jan2015
> z14, 170 processors, 150BIPS (862MIPS/proc), Aug2017
> z15, 190 processors, 190BIPS* (1000MIPS/proc), Sep2019
>
> * pubs say z15 1.25 times z14 (1.25*150BIPS or 190BIPS)
> * z16, 200?? processors, ???BIPS (???MIPS/proc),

other trivia: 1980, STL (since renamed silicon valley lab) was bursting
at the seams and were moving 300 people from the IMS group to offsite
bldg (with dataprocessing back to STL datacenter). They had tried
"remote 3270" terminals, but found the human factors totally
unacceptable (especially compared to channel attached 3270 controlers in
STL bldg). I get con'ed into doing channel extender support
... allowing channel attached controllers to be placed at offsite bldg
... with no perceptable human factors difference between offsite and
inside STL.

Then the hardware vendor tries to get IBM to release my support, but
there are some engineers in POK playing with some serial stuff who get
that vetoed (because they were afraid if it was in the market, it would
make it harder to get their stuff released).

In 1988, the IBM branch wants me to help LLNL standardize some stuff
they are playing with, ... which quickly becomes FCS (including some
stuff that I had done in 1980), initially full-duplex 1gbit, 2gbit
aggregate, 200mbytes/sec

The POK people finally get their stuff released in 1990 with ES/9000 as
ESCON, when it is already obsolete (17mbytes/sec). Some POK engineers
start playing with FCS and define a heavy weight protocol that
drastically reduces the native throughput, which eventually ships as
FICON. The most recent public benchmark I can find is z196 "peak I/O"
which gets 2M IOPS aggregate using 104 FICON. About the same time there
was a FCS announced for E5-2600 claiming over million IOPS (two such FCS
getting higher throughput than 104 FICON) ... and E5-2600 blade at
500BIPS is ten times processing of max configured z196 50BIPS.

[Charlie Gibbs]

On 2022-12-23, Anne & Lynn Wheeler <ly...@garlic.com> wrote:

> Peter Flass <peter...@yahoo.com> writes:
>
>> IBM never used MIPS either, but rated processors relative to each other.
>> I always thought they did this to avoid comparisons to other vendors’
>> machines, but it was probably as much because it was meaningless, as you
>> say.
>
> IBM tries stamp out industry standard benchmark numbers for their
> mainframes.

After all, MIPS really stands for
"Meaningless Indication of Processor Speed".

[Vir Campestris]

On 23/12/2022 21:42, Ahem A Rivet's Shot wrote:
> I think the cleverest twist in system cooling has to be the trick of
> immersing the whole thing in an inert fluid that boils at 50C with a
> fan assisted condenser at the top.

The problem with that is hot spots under the bubbles. You'll need a
decent heat spreader too.

Andy

[D.J.]

The Cray YMP-2 had a non-conductive fluid that flowed across the
circuit boards, then out to a head exchanger.
--
Jim

[Anne & Lynn Wheeler]

Charlie Gibbs <cgi...@kltpzyxm.invalid> writes:
> After all, MIPS really stands for
> "Meaningless Indication of Processor Speed".

... "stamping out" benchmarks for mainframes ... not just MIPS
(conflating that they are actual count of instructions frequently
highlighting significant RISC/CISC differences ... rather than industry
benchmark is number of program iterations per second compared to
reference platform) ... but also TPC (transactions/sec, $$/transaction,
power/transaction) and other of the ilk ... however participate in
benchmarks for their non-mainframe platforms.

reminiscence of the enormous marketing FUD from the 70s Future System
days where internal politics from the Future System project was killing
off 370 efforts ... and the lack of new IBM 370 products was credited
with giving the 370 clone makers their market foothold (leaving IBM
marketing little else but "Fear, Uncertainty, and Doubt")

some FS details:
http://www.jfsowa.com/computer/memo125.htm
http://people.cs.clemson.edu/~mark/fs.html

before that ... killing off ACS/360 because executives were afraid that
it would advance state-of-the-art too fast and IBM would loose control
of the market:
https://people.cs.clemson.edu/~mark/acs_end.html

above list some of the ACS/360 features that don't show up until more
than 20yrs later with ES/9000.

another FUD trivia: 3880 was designed to handle the 3mbyte/sec 3380
transfer speed ... along with data streaming channel architecture
(previously enormous channel protocol chatter with end-to-end handshake
for ever byte transferred, 3mbyte channels allowed multi-byte transfer
per end-to-end handshake). The trout/3090 effort had number of channels
assuming 3880 was similar to the previous 3830 but with 3380 3mbyte/sec
transfer. However, 3880 had special hardware path for data transfer but
everything else was done by an extremely slow "vertical" microcode
processor (not the much faster 3830 "horizontal" microcode processor).
When trout/3090 finally found out that the 3880 channel busy would be
significantly larger than anticipated, they realized that had to
significantly increase the number of channels ... in order to achieve
IOPS required to achieve targeted system throughput. It turns out that
the increase in channels required an additional (expensive) TCM. They
joked that they were going to bill the 3880 organization for the
increase in 3090 manufactoring cost (additional TCM).

Note that marketing eventually respins the significant increase in
channels for 3090 (compared to previsious mainframe genereations)
... needed to compensate for the enormous increase 3880 channel
busy ... as making the 3090 and wonderful I/O machine.

This is somewhat analogous to the peak I/O z196 benchmark of 2M IOPS
reqired 104 FICON (FICON protocol running over FCS) compared to IOPS
for single native FCS of over a million.

recent post on linkedin
https://www.linkedin.com/pulse/mainframe-channel-io-lynn-wheeler/

[Peter Flass]

Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
> On 2022-12-23, Anne & Lynn Wheeler <ly...@garlic.com> wrote:
>
>> Peter Flass <peter...@yahoo.com> writes:
>>
>>> IBM never used MIPS either, but rated processors relative to each other.
>>> I always thought they did this to avoid comparisons to other vendors’
>>> machines, but it was probably as much because it was meaningless, as you
>>> say.
>>
>> IBM tries stamp out industry standard benchmark numbers for their
>> mainframes.
>
> After all, MIPS really stands for
> "Meaningless Indication of Processor Speed".
>

On the other tentacle, comparing one IBM processor to another makes the
most sense for current customers looking to upgrade. “Oh, this new one is
twice as fast as what we have now.” MIPS would be a lot less meaningful to
this group.

--
Pete

[Scott Lurndal]

Burroughs used "RPM" (Relative Performance Measure) to compare both within
the Burroughs mainframes and between Burroughs and IBM mainframes.

RPM was derived from the results of running a basket of typical customer
applications:

* On-line Banking Simulator
* COBOL 74 Cross Reference
* Document Editor (COBOL74)
* Factory Material Requirements Planning
* Grocery Warehouse Inventory (Forte 2)
* DMPALL Disk to Disk Transfer
* Treasury Tax and Loan System

These applications were also run on various IBM machines for
apples-to-apples comparisions.

These measure whole-system performance (CPU, I/O Subsystem, etc)
rather than pure CPU speed.

[Charlie Gibbs]

On 2022-12-24, Peter Flass <peter...@yahoo.com> wrote:

> Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
>
>> On 2022-12-23, Anne & Lynn Wheeler <ly...@garlic.com> wrote:
>>
>>> Peter Flass <peter...@yahoo.com> writes:
>>>
>>>> IBM never used MIPS either, but rated processors relative to each other.
>>>> I always thought they did this to avoid comparisons to other vendors’
>>>> machines, but it was probably as much because it was meaningless, as you
>>>> say.
>>>
>>> IBM tries stamp out industry standard benchmark numbers for their
>>> mainframes.
>>
>> After all, MIPS really stands for
>> "Meaningless Indication of Processor Speed".
>
> On the other tentacle, comparing one IBM processor to another makes the
> most sense for current customers looking to upgrade.

At least for CPU-bound jobs.

> “Oh, this new one is twice as fast as what we have now.” MIPS would be
> a lot less meaningful to this group.

"Oh wow, my bubble sort runs in half the time now!"

[D.J.]

On Sat, 24 Dec 2022 11:17:54 -0600, D.J. <chuckt...@gmnol.com>
wrote:

Heat exchanger.
--
Jim

[Anne & Lynn Wheeler]

Peter Flass <peter...@yahoo.com> writes:
> On the other tentacle, comparing one IBM processor to another makes the
> most sense for current customers looking to upgrade. “Oh, this new one is
> twice as fast as what we have now.” MIPS would be a lot less meaningful to
> this group.

the previous story about no. of channels and i/o throughput for 3090
... was to have sufficient concurrent work load to keep cpu busy (in
aggregate) ... i/o throughput power matching cpu throughput power.

the story this was the justification of making all 370s, virtual memory
machines ... customer asked me a decade ago to track down the decision;
found somebody that reported to the executive. Bascially (OS/360) MVT
storage management was so bad that region sizes had to be usually four
times larger than actually used ... as a result it restricted number of
concurrently executing regions for typical 1mbyte 370/165 to four
... insufficient to keep processor adequately justified and busy.

Going to 16mbyte virtual memory, allowed increasing number of
concurrently executing regions by four times ... with little or no
paging. Original VS2 was SVS ... very similar to running MVT in a CP67
16mbyte virtual machine. The biggest code change was for channel program
copies with virtual addresses translated to real ... OS/360 running in
CP67 virtual machines had I/O channel programs with virtual addresses
and CP67 "CCWTRANS" made copies of the virtual machine channel programs
where the virtual addresses replaced with real addresses.

OS/360 had libraries executed by application programs, generating I/O
channel programs and then invoking (kernel SVC0) EXCP to invoke the
channel program. In VS2/SVS (and later MVS), EXCP had same problem (as
CP67) making I/O channel program copy, replacing virtual addresses with
real addresses. The initial VS2 implementation borrowed CP67 CCWTRANS
and crafted it into EXCP.

old archived post from decade ago with pieces of the email exchange
about MVT (bad) storage management was motivation for making all 370s,
virtual memory machines.
http://www.garlic.com/~lynn/2011d.html#73

other trivia is seen in EC12->z13 numbers (from upthread post), max
configurations, had EC12/75BIPS going to z13/100BIPS ... but EC12 had
101 743MIPS processors while z13 had 140 710MIPS processors (1/3rd
increase in aggregate MIPS by having 40% increase in number of
processors with slightly lower MIPS).

one of my other comparisons was communication group fiercely fighting
off client/server and distributed computing, also trying to block
release of mainframe TCP/IP support ... when they lost, somewhat because
of univ. demand ... the communication group changed their tactic and
said that since they had corporate strategic responsibility for
everything that crossed datacenter walls, it had to be shipped through
them. What shipped, used nearly a while 3090 processor getting
44kbytes/sec aggregate throughput. I then did the changes for RFC1044
and in some tuning tests at Cray Research between IBM 4341 (about
1+mips) and cray, got sustained channel I/O throughput (about 500 times
improvement in bytes moved per instruction executed).

A few years later, the communication group hired silicon valley
contractor to implement TCP/IP directly in VTAM. What he demo'ed had TCP
running much faster than (SNA) LU6.2. He was then told that everybody
"knows" thaa a "proper" TCP/IP implementation is much slower than LU6.2
... and they would only be paying for a "proper" implementation.

In that time-frame there was analysis that had (mainframe) pathlength
for VTAM/LU6.2 at 160K instructions and 15 buffer copies ... while UNIX
TCP/IP pathlength was 5K instructions and 5 buffer copies. Other
history about IBM (mainframe) downfall
https://www.linkedin.com/pulse/ibm-downfall-lynn-wheeler/
and
https://www.linkedin.com/pulse/john-boyd-ibm-wild-ducks-lynn-wheeler/

[Anne & Lynn Wheeler]

Charlie Gibbs <cgi...@kltpzyxm.invalid> writes:
> After all, MIPS really stands for
> "Meaningless Indication of Processor Speed".

... as an aside, IBM mainframe has hyping its faster processor Ghz and
no hardware multi-threading ... somehow trying to imply it corresponded
to faster instruction execution ... when the mainframe didn't come close
to approaching processor power of other platforms i.e. totally lacked
out-of-order (and multi-threaded) cache miss compensation until z196 and
then only started to evolve the technology.

this century articles started to appear that (cache miss) memory
latency, when measured in count of processor cycles is comparable to 60s
IBM 360 mainframe disk access latency, when measured in count of 360
mainframe processor cycles.

The (relatively) huge wait for 360 mainframe for disk I/O was some of
the motivation for software multiprogramming and multithreading.

This started to appear at the hardware level with caches (and cache
misses), with waiting for memory is the modern equivalent to 60s waiting
for disk I/O ... giving rise to things like hardware multithreading,
out-of-order execution, branch prediction and speculative execution

IBM mainframes were very late to this game, while at the same time, they
were exhacerbating the memory latency problem with increasing processor
Ghz speeds ... emphasizing faster Ghz speeds while discounting industry
standard MIPS benchmarks (which had better correlation with actually
processor throughput, not physically counting instructions ... but
counting program iterations compared to the reference platform).

[Peter Flass]

Head Exchanger is what you need after using windoze.

--
Pete

[Anne & Lynn Wheeler]

D.J. <chuckt...@gmnol.com> writes:
> The Cray YMP-2 had a non-conductive fluid that flowed across the
> circuit boards, then out to a head exchanger.

IBM water cooled machines had flow sensor on inboard fluid side but not
on outboard side of heat exchanger ... and a customer machine outboard
side lost water flow ... by the time the thermal sensor registered
temperature was increasing (and shutoff power) ... it was too late and
circuits fried. All heat exchangers were then retrofitted with flow
sensor on the outboard side.

as periodically mentioned, during Future System project (in first half
of 70s), 370 projects were being shutdown (FS was going to completely
replace 370s and completely different). When FS imploded there was mad
rush to get stuff back into the 370 product pipelines, including kicking
off quick&dirty 3033 & 3081 in parallel.
http://www.jfsowa.com/computer/memo125.htm

The 370 emulator minus the FS microcode was eventually sold in 1980 as
as the IBM 3081. The ratio of the amount of circuitry in the 3081 to its
performance was significantly worse than other IBM systems of the time;
its price/performance ratio wasn't quite so bad because IBM had to cut
the price to be competitive. The major competition at the time was from
Amdahl Systems -- a company founded by Gene Amdahl, who left IBM
shortly before the FS project began, when his plans for the Advanced
Computer System (ACS) were killed. The Amdahl machine was indeed
superior to the 3081 in price/performance and spectaculary superior in
terms of performance compared to the amount of circuitry.]

... snip ...

the enormous number of circuits for 3081 helped motivate TCMs ... to
pack them in reasonable sized physical volume
https://www.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV2137.html

... note above marketing respinning the enormous number of circuits,
also the increased heat density significantly exacerbated sensitivity to
loss of cooling.

Note initial 3081D was two processor claiming 5mips/processor (although
several benchmarks were slower than 4.5mips 3033). IBM then doubled the
cache size for 3081K claiming 7mips/processor (aka from improved cache
hit rate, with some of those benchmarks now equivalent to 4.5mips 3033
or slightly better, see previous post increasingly machine throughput
was becoming increasingly sensitive to cache miss and wating on memory)
... or two processor aggregate of 14mips claimed. By comparison, the
single processor Amdahl benchmarked at around 13mips.

shutdown of ACS/360
https://people.cs.clemson.edu/~mark/acs_end.html

[Vir Campestris]

On 24/12/2022 17:17, D.J. wrote:
> The Cray YMP-2 had a non-conductive fluid that flowed across the
> circuit boards, then out to a head exchanger.

Liquid cooling is not uncommon.

Boiling liquid cooling has all sorts of problems, which is what Steve
suggested.

Andy

[Charlie Gibbs]

I can't help but visualize a car pulled over to the side of the road
with its radiator boiling over. Maybe Tesla will bring it back.

[Thomas Koenig]

D.J <chuckt...@gmnol.com> schrieb:

Not sure I'd want to have my head exchanged, I'd stay well clear
of that machine :-)

[Quadibloc]

On Friday, March 4, 2022 at 12:06:39 PM UTC-7, Peter Flass wrote:

> It would have to be hard to tell, since the VAX hardware was a lot faster
> than the PDP-10. I enjoyed working with both systems.

I briefly used OpenVMS, and I noted one feature that it had because
VAX hardware was modern and fast... and thus it had very large disk
files.

You could put square brackets after a file name, and get previous
versions of the file. I'm pretty sure they wouldn't have offered _that_
facility with TOPS-10 or TOPS-20.

Otherwise - the operating system was a way to ask for the
program you wanted to run by name. As long as it wasn't as
incomprehensible as IBM's JCL for OS/360, for the most part,
they're all good... but _one_ notable feature of the PDP-10
environment is the text editor TECO, which was the inspiration
for EMACS.

John Savard

[D.J.]

Yeah, I can see that would be a problem if a leak happened.
--
Jim

[Niklas Karlsson]

On 2022-12-30, Quadibloc <jsa...@ecn.ab.ca> wrote:
>
> but _one_ notable feature of the PDP-10 environment is the text editor
> TECO, which was the inspiration for EMACS.

Wasn't EMACS originally implemented in TECO macros? Hence the name,
"Editing MACroS".

Niklas
--
You know you're in trouble when the Russians are adding safety
features to your design.
-- Maciej Ceglowski on Buran, the Space Shuttle clone

[D.J.]

Yeah, typo. I did correct it, but maybe the correction didn't make it.
Too few new charactrers.
--
Jim

[Charlie Gibbs]

On 2022-12-30, Thomas Koenig <tko...@netcologne.de> wrote:

> D.J <chuckt...@gmnol.com> schrieb:
>
>> On Sat, 24 Dec 2022 11:54:10 +0000, Vir Campestris
>> <vir.cam...@invalid.invalid> wrote:
>>
>>> On 23/12/2022 21:42, Ahem A Rivet's Shot wrote:
>>>
>>>> I think the cleverest twist in system cooling has to be the trick of
>>>> immersing the whole thing in an inert fluid that boils at 50C with a
>>>> fan assisted condenser at the top.
>>>
>>> The problem with that is hot spots under the bubbles. You'll need a
>>> decent heat spreader too.
>>

>> The Cray YMP-2 had a non-conductive fluid that flowed across the
>> circuit boards, then out to a head exchanger.
>
> Not sure I'd want to have my head exchanged, I'd stay well clear
> of that machine :-)

This reminds me of a couple of scenes from _Red Dwarf_
(perhaps with a bit of _Sleeper_ thrown in for good measure).

[Charlie Gibbs]

On 2022-12-30, Niklas Karlsson <nikke.k...@gmail.com> wrote:

> On 2022-12-30, Quadibloc <jsa...@ecn.ab.ca> wrote:
>
>> but _one_ notable feature of the PDP-10 environment is the text editor
>> TECO, which was the inspiration for EMACS.
>
> Wasn't EMACS originally implemented in TECO macros? Hence the name,
> "Editing MACroS".

I thought it was "Eight Megabytes And Constantly Swapping".

> You know you're in trouble when the Russians are adding safety
> features to your design.
> -- Maciej Ceglowski on Buran, the Space Shuttle clone

They could probably do it with the 737 MAX, too.

[Niklas Karlsson]

On 2022-12-30, Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
> On 2022-12-30, Niklas Karlsson <nikke.k...@gmail.com> wrote:
>
>> On 2022-12-30, Quadibloc <jsa...@ecn.ab.ca> wrote:
>>
>>> but _one_ notable feature of the PDP-10 environment is the text editor
>>> TECO, which was the inspiration for EMACS.
>>
>> Wasn't EMACS originally implemented in TECO macros? Hence the name,
>> "Editing MACroS".
>
> I thought it was "Eight Megabytes And Constantly Swapping".

Well, yes, that's the _real_ name. But not the official story. :-)

"Emacs is a fine operating system, but lacks a decent text editor," as
some say.

I'm not really an Emacs person (don't much care what others edit with,
though), but I do run it for one sole purpose. There's a domestically
developed bulletin board system called KOM, and the most feature-rich
client is implemented in Emacs LISP.

>> You know you're in trouble when the Russians are adding safety
>> features to your design.
>> -- Maciej Ceglowski on Buran, the Space Shuttle clone
>
> They could probably do it with the 737 MAX, too.

Probably.

> Microsoft is a dictatorship.
> Apple is a cult.
> Linux is anarchy.
> Pick your poison.

I mix and match. I run Windows at home for games, with a Linux shell
server that I use for, among other things, usenet. My workstation at
work is a Mac, and the servers are all Linux.

I also have an iPhone for private use and an Android phone for work.

I like to keep up to date with all the major factions.

Niklas
--
Microsoft's software "Wizards" show that their marketing department
is envisioning Tolkien but their coders are more into Pratchett.
-- Anthony de Boer, asr

[Rich Alderson]

Quadibloc <jsa...@ecn.ab.ca> writes:

> On Friday, March 4, 2022 at 12:06:39 PM UTC-7, Peter Flass wrote:

>> It would have to be hard to tell, since the VAX hardware was a lot faster
>> than the PDP-10. I enjoyed working with both systems.

The VAX-11/780 wished it was as fast as the PDP-10.

> they're all good... but _one_ notable feature of the PDP-10
> environment is the text editor TECO, which was the inspiration
> for EMACS.

TECO originated on the PDP-1 at MIT. The name was originally an acronym for
"Tape Editor and COrrector" (referring to paper tape on the Friden Flexowriter).
DEC did implementations for each architecture, and MIT did their own
implementations for the PDP-6 and PDP-10 (running their own OS, the
Incompatible Timesharing System).

EMACS was implemented in the MIT dialect for the PDP-10, after a real-time
video mode was created for that TECO.

Old .sig:

Rich Alderson Last LOTS Tops-20 Systems Programmer, 1984-1991
Current maintainer, MIT TECO EMACS (v. 170)
last name @ XKL dot COM Customer Interface, XKL LLC


--
Rich Alderson ne...@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

[Peter Flass]

Quadibloc <jsa...@ecn.ab.ca> wrote:
> On Friday, March 4, 2022 at 12:06:39 PM UTC-7, Peter Flass wrote:
>
>> It would have to be hard to tell, since the VAX hardware was a lot faster
>> than the PDP-10. I enjoyed working with both systems.
>
> I briefly used OpenVMS, and I noted one feature that it had because
> VAX hardware was modern and fast... and thus it had very large disk
> files.
>
> You could put square brackets after a file name, and get previous
> versions of the file. I'm pretty sure they wouldn't have offered _that_
> facility with TOPS-10 or TOPS-20.

TOPS-20 supports file versioning. I had to look this up, because memory
begins to fail after 50 years.

--
Pete

[Quadibloc]

On Friday, December 30, 2022 at 8:08:33 PM UTC-7, Peter Flass wrote:

> TOPS-20 supports file versioning. I had to look this up, because memory
> begins to fail after 50 years.

Was that something you had to specifically request, though? Because
OpenVMS basically versioned all files by default. To an extent that I
would have thought to be far too wasteful to countenance on older
systems.

John Savard

[Christian Brunschen]

In article <k19c5j...@mid.individual.net>,

Niklas Karlsson <nikke.k...@gmail.com> wrote:
>Well, yes, that's the _real_ name. But not the official story. :-)
>
>"Emacs is a fine operating system, but lacks a decent text editor," as
>some say.
>
>I'm not really an Emacs person (don't much care what others edit with,
>though), but I do run it for one sole purpose. There's a domestically
>developed bulletin board system called KOM, and the most feature-rich
>client is implemented in Emacs LISP.

I am reminded of this (rather old) joke:

Q: What's the name of the kernel file in the GNU operating system?

A: /vmunix.el

// Christian

[Johnny Billquist]

TOPS-20 always have versions of files, just like VMS and RSX.
However, you could set both TOPS-20 and VMS to automatically purge older
versions.

Also, the notation was not with any square brackets.

In VMS, it is DEV:[DIRECTORY]FILENAME.EXT;VERSION
In TOPS-20, it is DEV:<DIRECTORY>FILENAME.EXT.VERSION

unless my brain suddenly developed another bit error. :-)

(VMS and RSX do also support the TOPS-20 style syntax.)

And version can be left out, which always gives you the latest version
when opening, and a new version when creating. There are some special
values possible on version as well.

Johnny