[Info-vax] VMS internals design, was: Re: BASIC and AST routines

[Dave Froble]

On 11/25/2021 9:01 AM, Simon Clubley wrote:
> On 2021-11-24, Chris Townley <news at cct-net.co.uk> wrote:
>> On 24/11/2021 21:45, Hunter Goatley wrote:
>>> On 11/24/2021 1:14 PM, Simon Clubley wrote:
>>>>
>>>> VMS should have been designed 5-10 years later on than when it was.
>>>>
>>>
>>> In a thread of backpedaling inanities, that has to be the most inane.
>>>
>>> Hunter
>>
>> +1
>>
>
> I am seriously annoyed by that comment Hunter because you have
> completely missed (either accidentally or deliberately) the point
> I am making (and have made before).

You may not be the only one who can be annoyed ...

> Compared to later operating system designs the internal design
> of VMS is a direct product of the 1970s mindset because it is
> ugly, hard to alter, not modular, full of internal hacks such
> as jumping internally all over the place and was designed when
> it was getting close to the end of when assembly language was
> considered to be both an acceptable system implementation language
> and an application language.

Two statements clearly at odds, and both totally accurate:

1) The VAX 11/780 was a wonderful computer offering greatly enhanced 
capabilities and performance.

2) The VAX 11/780 was a slow pig of a computer and wasted way too much floor 
space and cost way too much, and had almost no memory.

It all depends on one's perspective, doesn't it?  The perspective of 1978 or the 
perspective of 2021.  If ugly hacks and jumping around were implemented to 
attempt to get a bit of performance out of the pig, well what's wrong with that? 
  But no, you Simon wish to judge VMS (which was written specifically for the 
VAX) from the perspective of 2021.  You're of course free to do so, but those 
who lived the years of VMS can see and announce your prejudice.

> VMS has given us great things such as world-leading clustering,
> but that doesn't change the ugly nature of its internal design.
>
> This has caused major problems going forward as people tried to
> enhance VMS. One such example is the need for a combined 32-bit/64-bit
> address space.

Solving a "need" is a problem?

> Another such example is playing out right now as we speak.
>
> The engineers at VSI are talented, experienced and generally skilled
> overall. However, due to how VMS was designed, it has taken even these
> skilled people over 7 years so far to port VMS to x86-64 and they will
> not be finished until the middle of next year at the earliest.

VMS was designed and implemented for VAX, not generic computers.

> As far as porting operating systems to a new architecture goes, that's
> pathetic (but due to no fault of the above skilled engineers I hasten to add).
>
> And even then, the port is not finished. After that, they need to provide
> a filesystem that's suitable for today's hardware and today's disk sizes.
>
> They have already had two goes at this and abandoned them. At current
> schedules, you can easily add another couple of years for a new filesystem.
>
> For comparison, I would expect a port of Linux to a new architecture to
> take about 6-12 months to achieve first boot (if you also had to do
> the compiler work as well) and about another 6-9 months after that
> to deliver initial versions of the port into the hands of the customers.

Don't want no stinkin Linux ...

> How many people would have stayed with VMS if they knew in 2014 that
> it would take another 8 years before they had VMS on x86-64

Me!  Me me me me me me ....

> and another
> couple of years after that before they had a filesystem suitable for
> today's hardware ?

ODS2 works for me ....

> I say things that people don't like to hear. They are also the same
> things that need to be said.

What need?  And what makes you think we don't already know?


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