[Simh] OT - Windows - Re: Alpha simulator performance

[Villy Madsen]

It has been a number of decades since I last seriously programmed under VMS.
Actually the 11/750 was announced just prior to us starting a Call Center
project on a 11/70.  The announcement of the '750 caused me to do a quick redo
of the project budget.  The cost of the '750 project coming in less than the '70
was a bonus.

The only real mistake that we made was deciding to go with Basic rather than
Fortran.  We had a number of issues with Basic and in fact ended up do some of
the critical parts of the APP in Fortran speeded things up.  (at one point the
Basic compiler would stop (with no messages) compiling when the code segment hit
64K.

If we had stuck with Fortran, we would not have had the problem of pummeling one
of the programmers whenever they used a gosub or a dynamically allocated string.
Gosubs because there was no traceback  and dynamic  strings because we didn't
want the overhead.

RMS was a joy for us - so much more reliable than what we had used with BP2 in
the past.

Pretty archaic by today's standards - but - it lasted for more than 25 years,
until the need that had driven it's creation disappeared.  It was Y2K compliant
- they contracted me to do (I had left the company some 20 years before).  It
did have some pains just prior to final termination.  It had problems as the
call volume dropped down to almost nothing.  It kept complaining that it wasn't
getting any calls!

We used all three types of RMS files, VMS mailboxes, the queue management
software was a doubly linked linklist of doubly linked  linklists (of calls).
One linklist for each minute of the day.  We had an audit routine that would
periodically traipse through the linklists - checking them for saneness.  I
think it took a month - to get all of the mistakes out.  After that it just
worked and worked and worked.  Never stressed the 11/750 - we ran a simulation
the showed that the 11/750 could have easily handled 10x the peak load that we
expected over the planned 5 year life.  It ran on the '750 until it was moved to
a cluster.

Do I miss having a natively supported file system like RMS - I sure do.  Far
simpler than using a relational database where I don't need the capability of
ad-hoc queries.

I won't call the lack of RMS an advantage - and I don't classify the imposition
of file data structures on an application is I don't think a negative thing.

Sure there are times when you need such things, but looking at the quality of
much of the software that we see these days, I really wonder how much of an
advantage the freedom to do almost anything with anything really is...

Also - as far as the VAX hardware is concerned - remember that it was the first
hardware to support no ex.  And then of course, if you were using Oracle, it
disabled the feature.....

Those were the good old days in more ways than one....

Villy


-----Original Message-----
From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On
Behalf Of Sergey Oboguev
Sent: April 22, 2012 17:04
To: Nathan Cutler
Cc: SIMH
Subject: Re: [Simh] OT - Windows - Re: Alpha simulator performance

Hi Nathan,

I believe the issue was not whether Windows is exact replica of VMS, but whether
there are grounds to believe Windows is substantially inferior to VMS.

On specific aspects you mentioned, it is certainly not. Windows does have help
systems superior to that of VMS Help: hypertext based, with TOC, navigation,
search, context help, tooltips etc.

Absence of RMS equivalent in any modern operating system is an advantage
compared to VMS. It was a doubtful idea to build the database into the kernel in
the first place, and to impose file data structuring on the applications. May be
it was an interesting experiment for its time, and in homogenous environment,
but it was a failed one. Rdb was an explicit admission of this failure, obvious
admission anyway: database layer does not belong to the standard part of the
executive, it belongs either to a server process (replaceable, customizable and
remote-able) or (for personal databases) in the library. Another aspect of RMS
-- imposing structuring on files -- is the bane to anyone attempting to use VMS
in heterogeneous environments. Long-term, it were bad ideas to use structured
(non-stream) text files, and also to fork file contents in to two segments (data
and attributes that are required for the interpretation of data structure), one
of which is hidden and gets lost when trying to transfer the file across
heterogeneous environment.

As for scripting, Windows does offer a variety scripting languages (both
Microsoft supported and open-source standards), and many of Windows components
are exposed for management either as callable COM/DCOM objects or via WMI/WBEM
or through the registry. Admittedly, scripting capabilities came somewhat late. 
However this is just the reflection of the fact that Windows was developed and
targeted as an operating system for desktop market first, where GUI-level
management interface certainly had to take a priority; managing via scripting
had to be a second priority. Nevertheless it had been available for many years
now.

Now, I am not quite sure about the "modality" of complaints about Windows vs. 
VMS. If they are an expression of just purely personal preferences, unrelated to
any objective comparative merits, akin to acquired taste (e.g. based on vested
effort, attachment to acquired knowledge, emotional nostalgia etc.), than this
of course is not a debatable subject. However what I do not see is any
objectively justifiable grounds for such complaints. (At least on a significant
scale, generally of course it may be possible to find corner cases that are
implemented better in this system or in that.)

> There is one area where Windows has VMS beat, though: eye-candy.

It would be more to the point to rephrase it as usability and productivity.

> there's also the 'minor detail' that VMS was never ported to the x86 platform.

Such porting would not have changed the fate of VMS very much. Windows won
desktop space because it provided expanding continuity of massive desktop
application base on the expanding continuity of deployed desktop hardware. Or to
put it in other way, because it swam with the strong current of market
collapsing to standardization rather than against it.

VMS stood no more chances for desktop than, some years earlier, DEC non-x86 PCs
with no software applications for them, at the time when market already
collapsed to standardization on IBM PC compatibles with thriving software
development ecosystem (Gordon Bell in his memories is quite acidic about this
situation).

Taking over the desktop meant also taking over the large part of software
development resources. Therefore if VMS x86 port were available, VMS could have
fared better in server space than it did, but it would have been undercut by the
shortage of 3rd party development support anyway.
_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh