Peter Flass <peter_flass@yahoo.com> writes:
>Johnny Billquist <bqt@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.

Johnny Billquist <bqt@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.

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

On 2022-03-06, Johnny Billquist <bqt@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.
\ / <cgibbs@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.

Rich Alderson wrote:
> Johnny Billquist wrote:
>> Rich Alderson wrote:
>>> The PDP-10 operating systems were mainframe oriented ab origine,
>>> unlike VMS.
>>
>> As you noted, Tops-10 originated in the monitor for the PDP-6. Is
>> that enough to call it mainframe?
>
> 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.

Some people will call any PDP-10 model a minicomputer with a perfectly
straight face. When asked why they don't consider it a mainframe, the
answer will kind of boil do to "it's not an IBM" (some hyperbole added
here). On the other end of the scale you can now hear the PDP-11
classified as a mainframe. Obviosly incorrectly, right? But I think
there's no stemming the tide on this.

People apparently have widely different and conflicting ideas what a
mainframe is. It seems a moot point to try to define it precisely.
Let's just say it's "the biggest computer around, capable of serving
many users". For DEC, that's the PDP-10 family.

Lars Brinkhoff <lars.spam@nocrew.org> writes:
> Some people will call any PDP-10 model a minicomputer with a perfectly
> straight face. When asked why they don't consider it a mainframe...

I remember hearing that DEC invented the term PDP (programmed data
processor) because they were afraid that if they called their product a
"computer", people would avoid it since real computers came only from
IBM. Calling it a PDP made it a different type of product, easier to
get past management because it didn't immediately evoke an IBM
comparison.

Once the PDP's became big enough to be considered real computers
(i.e. the PDP-10), they changed the name PDP-10 to DECsystem-10.

Rich Alderson <news@alderson.users.panix.com> writes:
>Johnny Billquist <bqt@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.

On 2022-03-06 19:34, Peter Flass wrote:
> Johnny Billquist <bqt@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

On 2022-03-07 16:07, Scott Lurndal wrote:
> Rich Alderson <news@alderson.users.panix.com> writes:
>> Johnny Billquist <bqt@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

On 2022-03-06 20:17, Paul Rubin wrote:
> Johnny Billquist <bqt@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

Johnny

D.J. <chucktheouch@gmail.com> writes:
>On Thu, 03 Mar 2022 14:30:52 GMT, scott@slp53.sl.home (Scott Lurndal)
>wrote:
>
>>"Stephen M. Jones" <smj@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 ?

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

Johnny Billquist <bqt@softjar.se> writes:
>On 2022-03-07 16:07, Scott Lurndal wrote:
>> Rich Alderson <news@alderson.users.panix.com> writes:
>>> Johnny Billquist <bqt@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).

Scott Lurndal <scott@slp53.sl.home> wrote:
> Johnny Billquist <bqt@softjar.se> writes:
>> On 2022-03-07 16:07, Scott Lurndal wrote:
>>> Rich Alderson <news@alderson.users.panix.com> writes:
>>>> Johnny Billquist <bqt@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).
>

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

On 2022-03-07 18:07, Scott Lurndal wrote:
> Johnny Billquist <bqt@softjar.se> writes:
>> On 2022-03-07 16:07, Scott Lurndal wrote:
>>> Rich Alderson <news@alderson.users.panix.com> writes:
>>>> Johnny Billquist <bqt@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.

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

Peter Flass <peter_flass@yahoo.com> writes:
>Scott Lurndal <scott@slp53.sl.home> wrote:
>> Johnny Billquist <bqt@softjar.se> writes:
>>> On 2022-03-07 16:07, Scott Lurndal wrote:
>>>> Rich Alderson <news@alderson.users.panix.com> writes:
>>>>> Johnny Billquist <bqt@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).
>>
>
>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.

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

On 2022-03-07 02:43, Rich Alderson wrote:
> Johnny Billquist <bqt@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

Johnny Billquist <bqt@softjar.se> writes:
>On 2022-03-07 18:07, Scott Lurndal wrote:
>> Johnny Billquist <bqt@softjar.se> writes:
>>> On 2022-03-07 16:07, Scott Lurndal wrote:
>>>> Rich Alderson <news@alderson.users.panix.com> writes:
>>>>> Johnny Billquist <bqt@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.

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

> Johnny Billquist <bqt@softjar.se> writes:
>>On 2022-03-07 18:07, Scott Lurndal wrote:
>>> Johnny Billquist <bqt@softjar.se> writes:
>>>> On 2022-03-07 16:07, Scott Lurndal wrote:
>>>>> Rich Alderson <news@alderson.users.panix.com> writes:
>>>>>> Johnny Billquist <bqt@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

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

> On 2022-03-07 18:07, Scott Lurndal wrote:
> > Johnny Billquist <bqt@softjar.se> writes:
> >> On 2022-03-07 16:07, Scott Lurndal wrote:
> >>> Rich Alderson <news@alderson.users.panix.com> writes:
> >>>> Johnny Billquist <bqt@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.

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

Dan Espen <dan1espen@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Johnny Billquist <bqt@softjar.se> writes:
>>>On 2022-03-07 18:07, Scott Lurndal wrote:
>>>> Johnny Billquist <bqt@softjar.se> writes:
>>>>> On 2022-03-07 16:07, Scott Lurndal wrote:
>>>>>> Rich Alderson <news@alderson.users.panix.com> writes:
>>>>>>> Johnny Billquist <bqt@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.

by design.

On 07/03/2022 16:53, Johnny Billquist wrote:
> On 2022-03-06 20:17, Paul Rubin wrote:
>> Johnny Billquist <bqt@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

Paul Rubin <no.email@nospam.invalid> writes:

> Lars Brinkhoff <lars.spam@nocrew.org> writes:
>> Some people will call any PDP-10 model a minicomputer with a perfectly
>> straight face. When asked why they don't consider it a mainframe...

> I remember hearing that DEC invented the term PDP (programmed data
> processor) because they were afraid that if they called their product a
> "computer", people would avoid it since real computers came only from
> IBM. Calling it a PDP made it a different type of product, easier to
> get past management because it didn't immediately evoke an IBM
> comparison.

It was not "IBM", but "GAO acquisition rules", which caused DEC to coin the
term "Programmed Data Processor" for their products, so that they could be sold
into individual departments rather than entire organizations in government
operated labs.

> Once the PDP's became big enough to be considered real computers
> (i.e. the PDP-10), they changed the name PDP-10 to DECsystem-10.

Mostly a Marketing Department decision...

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

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

> Rich Alderson <news@alderson.users.panix.com> writes:
>> Johnny Billquist <bqt@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.

--
Rich Alderson news@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 <news@alderson.users.panix.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Rich Alderson <news@alderson.users.panix.com> writes:
>>> Johnny Billquist <bqt@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.

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@slp53.sl.home (Scott Lurndal) writes:
>Rich Alderson <news@alderson.users.panix.com> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Rich Alderson <news@alderson.users.panix.com> writes:
>>>> Johnny Billquist <bqt@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.
>
>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.

On 2022-03-07 23:58, Scott Lurndal wrote:
> scott@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