On 13 Nov 2023 at 17:44:15 GMT, "Pancho" <Pancho.Jones@proton.me> wrote:

> Looking back on it now. I think the strangest thing about VMS was the
> Manual Set.

Chap I shared an office with at SLAC back in the 80s was one of these
hoarders. We not only had the current set of VMS doc in the office, but the
complete previous set too, while he had the set before that in his garage at
home.

He was the sort of chap who, if you asked him for the 3-page doc that you'd
loaned him a month previously, could unerringly poke into the 3-foot high pile
(er, one of the piles, sorry), on his desk and pull it out straight away, with
zero search time. This made complaining about the paper piles futile. "Works
for me!"

--
Tim

On Mon, 13 Nov 2023 17:44:15 +0000, Pancho wrote:

> Looking back on it now. I think the strangest thing about VMS was the
> Manual Set.

I was part of one, fairly large, project on VAX/VMS. I thought the oddest
part of it was the way the usual collection of programmer's utilities were
implemented as a handful of multi-function development tools, i.e. one
program that handled all source file management tasks, another to take
care of all comms tasks, etc. I've never met any other OS that was
structured that way.

Several years later I did another project on DEC Alpha Servers running
Tru64 UNIX, which I preferred to VMS, being a UNIX fanatic. Tru64 UNIXwas
pretty much a straight-forward port of UNIX System V functions and
programing tools onto a MACH-based kernel. This was amazingly fast for the
era and fairly bullet-proof.

--

Martin | martin at
Gregorie | gregorie dot org

On 13/11/2023 22:00, Martin Gregorie wrote:
> On Mon, 13 Nov 2023 17:36:53 +0000, Chris Townley wrote:
>
>> On 13/11/2023 17:32, Charlie Gibbs wrote:
>>> On 2023-11-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>>> On 11/13/2023 5:26 AM, Pancho wrote:
>>>>
>>>>> I don't really know the performance penalty of emulators.
>>>>
>>>> The overhead of a non-JIT instruction set emulation must be huge.
>>>
>>> Back in my Amiga days, I played with the Transformer, a software
>>> emulation of an 8088 on a 68000. It would run MS-DOS, but very slowly
>>> - I figured about a 10x slowdown.
>>> Once just for giggles I ran Z80MU (a Z80 emulation for MS-DOS) under
>>> the Transformer. Under these two levels of emulation I fired up the
>>> CP/M BASIC interpreter and typed "PRINT SIN(whatever)". It came back
>>> with the correct answer - 7 seconds later.
>>>
>>>
>> That sounds like the Sinclair scientific calculator in the early 70s
>
> I had one of the really small 4 function calculators in 1975. IIRC it
> wasn't all that slow (similar speed to a slide rule if each calculation
> required both slide and cursor to be moved for each calculation) but its
> main drawbacks was being really too small and fiddly, I used to be pretty
> good with the mechanical, electrically driven FACIT desktop calculators
> and I'd say the Sinclairs were just a little faster than those Facits.
>
> However, I got an HP 21 (RPN0 calculator in 1977 and that was much faster
> AND much stronger and better made: still have it and it still works, but
> got an HP 21 (programmable too). That got replaced by an HP 28s in 1990
> and is still in daily use.
>
No this was the earlier scientific calculator, and a few years earlier.
When you pressed a function, the screen would go blank for about 7
seconds. |But at the time, and the price it was phenomenal!

--
Chris

In article <krfh9mFu9jrU2@mid.individual.net>,
Bob Eager <news0009@eager.cx> wrote:
>On Mon, 13 Nov 2023 16:26:19 +0000, Scott Dorsey wrote:
>
>> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>>>
>>>> How does that compare with a real VAX or a PDP/11?
>>>
>>> One VUPS is supposed to be one original VAX CPU running VMS.
>>
>> Right, so this is about a Vax 6000 or so, right?
>
>No. Original VAX. An 11/780.

That's one VUPS. But the Pi emulator is about thirty.

>A VAX 6000 (one CPU) was about 7 VUPs, as I recall.

Hmm, I remember it as being faster. Which machine was about 30 VUPS?
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On Mon, 13 Nov 2023 22:00:13 -0000 (UTC), Martin Gregorie wrote:

> On Mon, 13 Nov 2023 17:36:53 +0000, Chris Townley wrote:
>
>> On 13/11/2023 17:32, Charlie Gibbs wrote:
>>> On 2023-11-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>>> On 11/13/2023 5:26 AM, Pancho wrote:
>>>>
>>>>> I don't really know the performance penalty of emulators.
>>>>
>>>> The overhead of a non-JIT instruction set emulation must be huge.
>>>
>>> Back in my Amiga days, I played with the Transformer, a software
>>> emulation of an 8088 on a 68000. It would run MS-DOS, but very slowly
>>> - I figured about a 10x slowdown.
>>> Once just for giggles I ran Z80MU (a Z80 emulation for MS-DOS) under
>>> the Transformer. Under these two levels of emulation I fired up the
>>> CP/M BASIC interpreter and typed "PRINT SIN(whatever)". It came back
>>> with the correct answer - 7 seconds later.
>>>
>>>
>> That sounds like the Sinclair scientific calculator in the early 70s
>
> I had one of the really small 4 function calculators in 1975. IIRC it
> wasn't all that slow (similar speed to a slide rule if each calculation
> required both slide and cursor to be moved for each calculation) but its
> main drawbacks was being really too small and fiddly, I used to be
> pretty good with the mechanical, electrically driven FACIT desktop
> calculators and I'd say the Sinclairs were just a little faster than
> those Facits.
>
> However, I got an HP 21 (RPN0 calculator in 1977 and that was much
> faster AND much stronger and better made: still have it and it still
> works, but got an HP 21 (programmable too). That got replaced by an HP
> 28s in 1990 and is still in daily use.

Correction: the HP 21 is nor programmable but the HP 28S is.

--

Martin | martin at
Gregorie | gregorie dot org

On 11/13/2023 4:42 PM, Bob Eager wrote:
> On Mon, 13 Nov 2023 16:06:59 -0500, Arne Vajhøj wrote:
>
>> On 11/13/2023 4:03 PM, Bob Eager wrote:
>>> On Mon, 13 Nov 2023 16:26:19 +0000, Scott Dorsey wrote:
>>>> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>>>>>
>>>>>> How does that compare with a real VAX or a PDP/11?
>>>>>
>>>>> One VUPS is supposed to be one original VAX CPU running VMS.
>>>>
>>>> Right, so this is about a Vax 6000 or so, right?
>>>
>>> No. Original VAX. An 11/780.
>>>
>>> A VAX 6000 (one CPU) was about 7 VUPs, as I recall.
>>
>> I think he meant that the VAX 6000 was about 30 VUPS.
>>
>> It depends on what 6000. A 6n0 is 32 VUPS but a 4n0 is 7 VUPS.
>
> Is that a single CPU, as I stated?

Yes.

But VUPS benchmarks are usually/always single-threaded
so it would not run much faster with 6 CPU's. 6 CPU's
is 6 x 7 or 6 x 32 VUPS not 42 or 192 VUPS.

Arne

On 11/13/2023 4:03 PM, Bob Eager wrote:
> On Mon, 13 Nov 2023 16:26:19 +0000, Scott Dorsey wrote:
>
>> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>>>
>>>> How does that compare with a real VAX or a PDP/11?
>>>
>>> One VUPS is supposed to be one original VAX CPU running VMS.
>>
>> Right, so this is about a Vax 6000 or so, right?
>
> No. Original VAX. An 11/780.
>
> A VAX 6000 (one CPU) was about 7 VUPs, as I recall.
>

The 6000 used the NVAX, correct? On a VAXstation 4000 Model 90A I get 26-27
VUPS. I'd think the 6000 would be similar.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 11/13/2023 7:25 PM, Dave Froble wrote:
> On 11/13/2023 4:03 PM, Bob Eager wrote:
>> On Mon, 13 Nov 2023 16:26:19 +0000, Scott Dorsey wrote:
>>> Ahem A Rivet's Shot  <steveo@eircom.net> wrote:
>>>>>
>>>>> How does that compare with a real VAX or a PDP/11?
>>>>
>>>>     One VUPS is supposed to be one original VAX CPU running VMS.
>>>
>>> Right, so this is about a Vax 6000 or so, right?
>>
>> No. Original VAX. An 11/780.
>>
>> A VAX 6000 (one CPU) was about 7 VUPs, as I recall.
>
> The 6000 used the NVAX, correct?  On a VAXstation 4000 Model 90A I get
> 26-27 VUPS.  I'd think the 6000 would be similar.

Depends on what 6000.

200 models - 2.8
300 models - 3.9
400 models - 7
500 models - 13
600 models - 32

(1-6 CPU's)

Arne

On Mon, 13 Nov 2023 23:42:16 +0000, Chris Townley wrote:

> On 13/11/2023 22:00, Martin Gregorie wrote:
>> On Mon, 13 Nov 2023 17:36:53 +0000, Chris Townley wrote:
>>
>>> On 13/11/2023 17:32, Charlie Gibbs wrote:
>>>> On 2023-11-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>
>>>>> On 11/13/2023 5:26 AM, Pancho wrote:
>>>>>
>>>>>> I don't really know the performance penalty of emulators.
>>>>>
>>>>> The overhead of a non-JIT instruction set emulation must be huge.
>>>>
>>>> Back in my Amiga days, I played with the Transformer, a software
>>>> emulation of an 8088 on a 68000. It would run MS-DOS, but very
>>>> slowly - I figured about a 10x slowdown.
>>>> Once just for giggles I ran Z80MU (a Z80 emulation for MS-DOS) under
>>>> the Transformer. Under these two levels of emulation I fired up the
>>>> CP/M BASIC interpreter and typed "PRINT SIN(whatever)". It came back
>>>> with the correct answer - 7 seconds later.
>>>>
>>>>
>>> That sounds like the Sinclair scientific calculator in the early 70s
>>
>> I had one of the really small 4 function calculators in 1975. IIRC it
>> wasn't all that slow (similar speed to a slide rule if each calculation
>> required both slide and cursor to be moved for each calculation) but
>> its main drawbacks was being really too small and fiddly, I used to be
>> pretty good with the mechanical, electrically driven FACIT desktop
>> calculators and I'd say the Sinclairs were just a little faster than
>> those Facits.
>>
>> However, I got an HP 21 (RPN0 calculator in 1977 and that was much
>> faster AND much stronger and better made: still have it and it still
>> works, but got an HP 21 (programmable too). That got replaced by an HP
>> 28s in 1990 and is still in daily use.
>>
> No this was the earlier scientific calculator, and a few years earlier.
> When you pressed a function, the screen would go blank for about 7
> seconds. |But at the time, and the price it was phenomenal!

The HP21 came out in 1975 was functionally identical to the earlier HP35,
but was a bit smaller and using a different case design and runs off two
AA NiCd cells.

The HP28S came out in 1988 and is quite flat (160 x 90 x 19 mm) and runs
for around a year on a set of three N-batteries.

--

Martin | martin at
Gregorie | gregorie dot org

On Monday, November 13, 2023 at 3:40:19 PM UTC-8, Martin Gregorie wrote:
> On Mon, 13 Nov 2023 17:44:15 +0000, Pancho wrote:
>
> > Looking back on it now. I think the strangest thing about VMS was the
> > Manual Set.
> I was part of one, fairly large, project on VAX/VMS. I thought the oddest
> part of it was the way the usual collection of programmer's utilities were
> implemented as a handful of multi-function development tools, i.e. one
> program that handled all source file management tasks, another to take
> care of all comms tasks, etc. I've never met any other OS that was
> structured that way.

I think that's one of the amusing quirks of VMS. It has a command interpreter that's almost like a text adventure game parser in its flexibility. There's a command definition utility to tell DCL the mapping from commands to the actual .EXE that handles it, so sometimes it's not at all obvious what program(s) implement which features.

I wouldn't say the programmer's utilities are any more monolithic under VMS than UNIX, but there can be a dozen or so different functions provided by a common verb like "SET", "SHOW", or "ANALYZE", with DCL using the command definition tables to activate the right program, and that's very unusual.

> Several years later I did another project on DEC Alpha Servers running
> Tru64 UNIX, which I preferred to VMS, being a UNIX fanatic. Tru64 UNIXwas
> pretty much a straight-forward port of UNIX System V functions and
> programing tools onto a MACH-based kernel. This was amazingly fast for the
> era and fairly bullet-proof.

Tru64 UNIX was quite well-regarded. Tru64, and OpenVMS Alpha, both had CPU hardware counter-based performance profiling just like Linux's "perf", but years earlier (Linux perf was first released in 2009).

Here's a paper from April 2001 describing how "DCPI/ProfileMe" let you drill down to see how your code was performing at the instruction level. https://www.mikerohard.de/alphalinuxperformance3.html

And here's a paper from 2003 describing DCPI on OpenVMS. https://www.zx.net..nz/mirror/h71000.www7.hp.com/openvms/journal/v2/articles/dcpi.pdf

Regards,
Jake Hamby

On 11/13/23 1:26 AM, Ahem A Rivet's Shot wrote:
> On Sun, 12 Nov 2023 22:48:31 -0500
> "56d.1152" <56d.1152@ztq9.net> wrote:
>
>> I always liked VMS - well ahead of its time.
>> HOPING some basement-dwelling guru will create
>> a Pi-runnable version with some more "modern"
>> features added.
>>
>> Hey, there's a Plan-9 for Pi ... there could be
>> a VMS as well !
>
> Plan 9 was designed to be portable and released as source code. VMS
> was designed for the VAX and while it has been ported to the PC the source
> code has not been released. Any port to the Pi would have to be done by VMS
> Software who make their money selling commercial VMS licenses.

Alas yes ........

Hmmmm - but WHO is buying such licenses, and for WHAT ???
VMS is allegedly WELL obsolete, yet they're making money
from ports.

Admittedly it will be difficult to separate VMS from the
hardware/peripherials it was written for. However if it
can be ported, more or less, to i86 then it should be less
of a prob to port THAT to ARM.

Plan-9 was writ to be "more portable". It is kinda hard to
deal with regardless of underlying hardware however. It was
intended for "distributed systems", not use on a single
box/processor, so you get that added complexity thrown in
for free.

There are some "ancient systems" that still see use. DOS
is one of them - compact/efficient and still fair for
embedded projects. CP/M derivs are also seen. OS9 is another -
and yes it's still developed and for-sale. Most of the
"big iron" systems from the 60s/70s went away however.
"Simplicity" seems to play a role in "longevity". VMS ...
well, it was REALLY GOOD ... so, somewhere, it's hanging
on - enough so people will PAY for it.

On Mon, 13 Nov 2023 23:02:11 -0500
"56d.1152" <56d.1152@ztq9.net> wrote:

> There are some "ancient systems" that still see use. DOS
> is one of them - compact/efficient and still fair for
> embedded projects. CP/M derivs are also seen. OS9 is another -
> and yes it's still developed and for-sale. Most of the
> "big iron" systems from the 60s/70s went away however.

Z/OS is still around and capable of running OS-360 binary
applications as well as more modern unix based systems.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On 2023-11-13 13:50, Arne Vajhøj wrote:
> On 11/13/2023 5:26 AM, Pancho wrote:
>> On 12/11/2023 21:47, Bob Eager wrote:
>>> On Sun, 12 Nov 2023 21:43:35 +0000, Pancho wrote:
>>>
>>>> On 12/11/2023 21:05, The Natural Philosopher wrote
>>>>
>>>>> My impression of a Pi Zero is that it would knock a PDP/11 into the
>>>>> middle of next week, and then some.
>>>>>
>>>>>
>>>> Yeah, I would have expected 100s or 1000s of VUPS.
>>>
>>> On an emulator?
>>
>> More than 30.
>>
>> I don't really know the performance penalty of emulators.
>
> The overhead of a non-JIT instruction set emulation
> must be huge.

Depending on the instructions and data, the overhead is somewhere
between 10:1 to 100:1. In some extreme cases it can be way worse.

Johnny

On 2023-11-14 00:40, Martin Gregorie wrote:
> On Mon, 13 Nov 2023 17:44:15 +0000, Pancho wrote:
>
>> Looking back on it now. I think the strangest thing about VMS was the
>> Manual Set.
>
> I was part of one, fairly large, project on VAX/VMS. I thought the oddest
> part of it was the way the usual collection of programmer's utilities were
> implemented as a handful of multi-function development tools, i.e. one
> program that handled all source file management tasks, another to take
> care of all comms tasks, etc. I've never met any other OS that was
> structured that way.

What other OSes do you have experience with?

Source management is usually handled by one single program, even on most
systems today. Be that cvs, svn, git or whatever.

And have you ever looked at find under Unix? That's a swiss army knife
if you ever saw one...

Johnny

On 2023-11-13 18:57, Jake Hamby (Solid State Jake) wrote:
> On Monday, November 13, 2023 at 9:44:19 AM UTC-8, Pancho wrote:
>> On 13/11/2023 15:12, Bob Eager wrote:
>>>
>>> That's a more realistic figure, and what has been observed (by me).
>> Observed figures are always more realistic, they are, after all, real.
>>
>> Apparently, my rPi5 has arrived today, but I'm not going to test the
>> emulator. I'm happy to leave the VMS part of my life, in the past.
>>
>> Looking back on it now. I think the strangest thing about VMS was the
>> Manual Set.
>
> Why is it strange that so much printed documentation was released with VMS? To me, the real strangeness is in learning all the proprietary APIs documented in all of those printed manuals. :) Thank goodness HP made all the documentation available in PDF form and often HTML as well for free in the early 2000's. The current VSI docs site is even better, with better HTML rendering of the original documents.

Do you think all the propietary APIs and libraries under Unix are any
different?
Nowadays there is POSIX (didn't even exist back when VMS was designed),
but POSIX only covers a small fraction of the libraries people use in
development.

Online documentation like man-pages is helpful, but it's usually not
nearly as deep as the VMS paper docs. The fact that the VMS docs were
made available as HTML and PDF was a nice improvement.

Johnny

On 13/11/2023 17:36, Chris Townley wrote:
> On 13/11/2023 17:32, Charlie Gibbs wrote:
>> On 2023-11-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>>> On 11/13/2023 5:26 AM, Pancho wrote:
>>>
>>>> I don't really know the performance penalty of emulators.
>>>
>>> The overhead of a non-JIT instruction set emulation
>>> must be huge.
>>
>> Back in my Amiga days, I played with the Transformer, a
>> software emulation of an 8088 on a 68000.  It would run
>> MS-DOS, but very slowly - I figured about a 10x slowdown.
>> Once just for giggles I ran Z80MU (a Z80 emulation for
>> MS-DOS) under the Transformer.  Under these two levels
>> of emulation I fired up the CP/M BASIC interpreter and
>> typed "PRINT SIN(whatever)".  It came back with the
>> correct answer - 7 seconds later.
>>
>
> That sounds like the Sinclair scientific calculator in the early 70s
>
No, that came back with the *wrong* answer...if it worked at all.

--
“But what a weak barrier is truth when it stands in the way of an
hypothesis!”

Mary Wollstonecraft

On Tue, 14 Nov 2023 10:30:18 +0100, Johnny Billquist wrote:

> On 2023-11-14 00:40, Martin Gregorie wrote:
>> On Mon, 13 Nov 2023 17:44:15 +0000, Pancho wrote:
>>
>>> Looking back on it now. I think the strangest thing about VMS was the
>>> Manual Set.
>>
>> I was part of one, fairly large, project on VAX/VMS. I thought the
>> oddest part of it was the way the usual collection of programmer's
>> utilities were implemented as a handful of multi-function development
>> tools, i.e. one program that handled all source file management tasks,
>> another to take care of all comms tasks, etc. I've never met any other
>> OS that was structured that way.
>
> What other OSes do you have experience with?
>
ICL: UDAS, OLDAS, George 1`,2 and 3, VME/B
Stratus: VOS
IBM: OS/400
DEC: VAX/VMS, TruUNIX (Alpha server)
PC: DOS, Windows, Unix, RedHat Linux
6809, FLEX, OS/9
68000: OS/9 68000
Stratus: VOS
Tandem: Nonstop OS
RPI: Debian Linux
..
Source management is usually handled by one single program, even on most
> systems today. Be that cvs, svn, git or whatever.
>
Indeed, I used CVS for years, now using Git

> And have you ever looked at find under Unix? That's a swiss army knife
> if you ever saw one...
>
Use it a lot, also apropos,

--

Martin | martin at
Gregorie | gregorie dot org

On 11/14/2023 4:27 AM, Johnny Billquist wrote:
> On 2023-11-13 18:57, Jake Hamby (Solid State Jake) wrote:
>> On Monday, November 13, 2023 at 9:44:19 AM UTC-8, Pancho wrote:
>>> On 13/11/2023 15:12, Bob Eager wrote:
>>>>
>>>> That's a more realistic figure, and what has been observed (by me).
>>> Observed figures are always more realistic, they are, after all, real.
>>>
>>> Apparently, my rPi5 has arrived today, but I'm not going to test the
>>> emulator. I'm happy to leave the VMS part of my life, in the past.
>>>
>>> Looking back on it now. I think the strangest thing about VMS was the
>>> Manual Set.
>>
>> Why is it strange that so much printed documentation was released with
>> VMS? To me, the real strangeness is in learning all the proprietary
>> APIs documented in all of those printed manuals. :) Thank goodness HP
>> made all the documentation available in PDF form and often HTML as
>> well for free in the early 2000's. The current VSI docs site is even
>> better, with better HTML rendering of the original documents.
>
> Do you think all the propietary APIs and libraries under Unix are any
> different?
> Nowadays there is POSIX (didn't even exist back when VMS was designed),
> but POSIX only covers a small fraction of the libraries people use in
> development.
>
> Online documentation like man-pages is helpful, but it's usually not
> nearly as deep as the VMS paper docs. The fact that the VMS docs were
> made available as HTML and PDF was a nice improvement.

The VMS API (SYS$, LIB$ etc.) is tiny by todays standard.

Windows is huge. Win32, MFC, OLE/COM/ATL, .NET FX, WinRT etc.
are probably a factor 100 bigger than VMS.

Linux is a bit more tricky to measure, because it is not very well
defined what to count: Linux kernel, glibc/musl, curses,
Xlib + Xt + GTK/Qt, hundreds of development libraries available
via distro package manager. I will claim that a "typical"
Linux development machine has a lot more API's installed
than VMS has.

The non-OS platform API's are also way bigger than VMS API
(Java + Maven repo, .NET Core + NuGet, Python + PyPi,
JS + npm etc.).

Arne

On 11/14/2023 7:39 AM, Martin Gregorie wrote:
> On Tue, 14 Nov 2023 10:30:18 +0100, Johnny Billquist wrote:
>> Source management is usually handled by one single program, even on most
>> systems today. Be that cvs, svn, git or whatever.
>
> Indeed, I used CVS for years, now using Git

Last one among the common with separate executables was probably RCS.

But I really don't see the big difference between:

vcsname vcscommand ... running vcsname.exe

and

vcscommand ... running vcscommand.exe

Arne

On 11/14/2023 4:30 AM, Johnny Billquist wrote:
> On 2023-11-14 00:40, Martin Gregorie wrote:
>> On Mon, 13 Nov 2023 17:44:15 +0000, Pancho wrote:
>>
>>> Looking back on it now. I think the strangest thing about VMS was the
>>> Manual Set.
>>
>> I was part of one, fairly large, project on VAX/VMS. I thought the oddest
>> part of it was the way the usual collection of programmer's utilities
>> were
>> implemented as a handful of multi-function development tools, i.e. one
>> program that handled all source file management tasks, another to take
>> care of all comms tasks, etc. I've never met any other OS that was
>> structured that way.
>
> What other OSes do you have experience with?
>
> Source management is usually handled by one single program, even on most
> systems today. Be that cvs, svn, git or whatever.
>
> And have you ever looked at find under Unix? That's a swiss army knife
> if you ever saw one...
>

Do you mean Unix find or Gnu find? Gnu people lost track of the Unix
Paradigm long ago.

bill

On 11/13/2023 7:29 PM, Arne Vajhøj wrote:
> On 11/13/2023 7:25 PM, Dave Froble wrote:
>> On 11/13/2023 4:03 PM, Bob Eager wrote:
>>> On Mon, 13 Nov 2023 16:26:19 +0000, Scott Dorsey wrote:
>>>> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>>>>>
>>>>>> How does that compare with a real VAX or a PDP/11?
>>>>>
>>>>> One VUPS is supposed to be one original VAX CPU running VMS.
>>>>
>>>> Right, so this is about a Vax 6000 or so, right?
>>>
>>> No. Original VAX. An 11/780.
>>>
>>> A VAX 6000 (one CPU) was about 7 VUPs, as I recall.
>>
>> The 6000 used the NVAX, correct? On a VAXstation 4000 Model 90A I get 26-27
>> VUPS. I'd think the 6000 would be similar.
>
> Depends on what 6000.
>
> 200 models - 2.8
> 300 models - 3.9
> 400 models - 7
> 500 models - 13
> 600 models - 32
>
> (1-6 CPU's)
>
> Arne
>
>

Well, when looking back, I'd think that one might remember the latest version of
any line of computers. For example, the VAXstation 4000 line had multiple
versions of the NVAX CPU, and the 90A I referenced was a later, but not the
latest, version. The model 96 was the last and best.

Not that I have any use for one, but I've always desired to acquire a MicroVAX
3100 model 98. Same CPU as the VAXstation 4000 model 96.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Mon, 13 Nov 2023 19:29:14 -0500, Arne Vajhøj wrote:

> On 11/13/2023 7:25 PM, Dave Froble wrote:
>> On 11/13/2023 4:03 PM, Bob Eager wrote:
>>> On Mon, 13 Nov 2023 16:26:19 +0000, Scott Dorsey wrote:
>>>> Ahem A Rivet's Shot  <steveo@eircom.net> wrote:
>>>>>>
>>>>>> How does that compare with a real VAX or a PDP/11?
>>>>>
>>>>>     One VUPS is supposed to be one original VAX CPU running VMS.
>>>>
>>>> Right, so this is about a Vax 6000 or so, right?
>>>
>>> No. Original VAX. An 11/780.
>>>
>>> A VAX 6000 (one CPU) was about 7 VUPs, as I recall.
>>
>> The 6000 used the NVAX, correct?  On a VAXstation 4000 Model 90A I get
>> 26-27 VUPS.  I'd think the 6000 would be similar.
>
> Depends on what 6000.
>
> 200 models - 2.8 300 models - 3.9 400 models - 7 500 models - 13 600
> models - 32
>
> (1-6 CPU's)

That''s why I qualified my statement with "(one CPU)"

On 11/14/2023 10:07 AM, Bob Eager wrote:
> On Mon, 13 Nov 2023 19:29:14 -0500, Arne Vajhøj wrote:
>> On 11/13/2023 7:25 PM, Dave Froble wrote:
>>> On 11/13/2023 4:03 PM, Bob Eager wrote:
>>>> On Mon, 13 Nov 2023 16:26:19 +0000, Scott Dorsey wrote:
>>>>> Ahem A Rivet's Shot  <steveo@eircom.net> wrote:
>>>>>>>
>>>>>>> How does that compare with a real VAX or a PDP/11?
>>>>>>
>>>>>>     One VUPS is supposed to be one original VAX CPU running VMS.
>>>>>
>>>>> Right, so this is about a Vax 6000 or so, right?
>>>>
>>>> No. Original VAX. An 11/780.
>>>>
>>>> A VAX 6000 (one CPU) was about 7 VUPs, as I recall.
>>>
>>> The 6000 used the NVAX, correct?  On a VAXstation 4000 Model 90A I get
>>> 26-27 VUPS.  I'd think the 6000 would be similar.
>>
>> Depends on what 6000.
>>
>> 200 models - 2.8 300 models - 3.9 400 models - 7 500 models - 13 600
>> models - 32
>>
>> (1-6 CPU's)
>
> That''s why I qualified my statement with "(one CPU)"

Just to be sure that everybody agrees about numbers.

200/300/400/500/600 are generational models independent of number
of CPU's.

A 210 is a 200 model with 1 CPU. 1 x 2.8 VUPS.

A 420 is 400 model with 2 CPU's. 2 x 7 VUPS.

A 660 is a 600 model with 6 CPU's. 6 x 32 VUPS.

Arne

On 2023-11-14 13:39, Martin Gregorie wrote:
> On Tue, 14 Nov 2023 10:30:18 +0100, Johnny Billquist wrote:
>
>> On 2023-11-14 00:40, Martin Gregorie wrote:
>>> On Mon, 13 Nov 2023 17:44:15 +0000, Pancho wrote:
>>>
>>>> Looking back on it now. I think the strangest thing about VMS was the
>>>> Manual Set.
>>>
>>> I was part of one, fairly large, project on VAX/VMS. I thought the
>>> oddest part of it was the way the usual collection of programmer's
>>> utilities were implemented as a handful of multi-function development
>>> tools, i.e. one program that handled all source file management tasks,
>>> another to take care of all comms tasks, etc. I've never met any other
>>> OS that was structured that way.
>>
>> What other OSes do you have experience with?
>>
> ICL: UDAS, OLDAS, George 1`,2 and 3, VME/B
> Stratus: VOS
> IBM: OS/400
> DEC: VAX/VMS, TruUNIX (Alpha server)
> PC: DOS, Windows, Unix, RedHat Linux
> 6809, FLEX, OS/9
> 68000: OS/9 68000
> Stratus: VOS
> Tandem: Nonstop OS
> RPI: Debian Linux

So in which way do you think VMS is so different than all of the above?
I only know a few of the ones you list, but I do know a bunch of others.
And to me, there is nothing I would say is strange, unique or even
special about how VMS does things.

It is a bit different than under Unix-like systems, since commands don't
necessarily have a 1:1 mapping to a binary. But apart from that, I fail
to see much of a difference.

And with alias for things, along with symlinks, Unix isn't really any
different there either.

> Source management is usually handled by one single program, even on most
>> systems today. Be that cvs, svn, git or whatever.
>>
> Indeed, I used CVS for years, now using Git
>
>> And have you ever looked at find under Unix? That's a swiss army knife
>> if you ever saw one...
>>
> Use it a lot, also apropos,

Well, apropos is just a simple tool for one thing. Which is just a way
to search man-pages. find on the other hand can be used for almost
anything, and the number of switches/options available is more than any
person can memorize. Admittedly, all the operations are related to
files, but then again, almost anything is a file under Unix. ;-)

Johnny

On 2023-11-14 15:43, bill wrote:
> On 11/14/2023 4:30 AM, Johnny Billquist wrote:
>> On 2023-11-14 00:40, Martin Gregorie wrote:
>>> On Mon, 13 Nov 2023 17:44:15 +0000, Pancho wrote:
>>>
>>>> Looking back on it now. I think the strangest thing about VMS was the
>>>> Manual Set.
>>>
>>> I was part of one, fairly large, project on VAX/VMS. I thought the
>>> oddest
>>> part of it was the way the usual collection of programmer's utilities
>>> were
>>> implemented as a handful of multi-function development tools, i.e. one
>>> program that handled all source file management tasks, another to take
>>> care of all comms tasks, etc. I've never met any other OS that was
>>> structured that way.
>>
>> What other OSes do you have experience with?
>>
>> Source management is usually handled by one single program, even on
>> most systems today. Be that cvs, svn, git or whatever.
>>
>> And have you ever looked at find under Unix? That's a swiss army knife
>> if you ever saw one...
>>
>
> Do you mean Unix find or Gnu find?  Gnu people lost track of the Unix
> Paradigm  long ago.

With find it don't matter. Even the original is crazy. The one tool
where the Unix paradigm got completely lost...

GNU have indeed gone crazy with options to programs as well, I admit.
Not to mention the added craziness of Red Hat...

Johnny