Mr Vijayan -

In response to your query I'll give my perspectives; I've been active
on info-vax for over 10 years, and in DECUS for ~25 so recall a fair
bit of history.

However I'd appreciate it if you did not use my name or attribute this
stuff in your article.

As to what you wanted to know...

I've watched the messages, and been worried by them and by the reports
of folks leaving OVMS that various friends have reported and which I've
encountered. Digital's management was for some time telling everyone
that OVMS was a "legacy" system, which term sounds like the term
"stabilized" to my ears. That started being used before DOS-11 was
dropped, before RSX11D/IAS got dropped, before development stopped on
RSX11M (though Mentec has restarted it as I hear), and so was bothersome
considering that I believe the OS is technically superior, and it no
longer has the disadvantage of running on slower iron than its competitors.
(Alpha processors are the fastest iron on the planet and look likely to 
stay that way into the next millenium, and OVMS is using them in full
64 bit mode now.) 

Lately, Digital management has been stating its intent to develop and
push OVMS development, and has added it again to the list of "strategic"
platforms. This is a serious turnaround and can help. The basic problem
in the perception space is that LOTS of folks still view VMS as something
that runs on VAX, and view VAX as a processor design that runs at below
10 Specmark89s, i.e., order(s) of magnitude slower than everyone's
processors. Even for the VAX architecture that's not true of current
models...the VLSI processes keep getting faster as they have been for
decades...but OVMS runs on Alpha now, where current models beat out
everything else, and announced models are looking like order of magnitude
100 SPECmark95 chips are near term things. By the 21st century, when
Merced will be out, those figures should be larger still, seeing they've
been increasing pretty continuously for everyone. So the old perception
that OVMS runs on slow expensive iron is wrong today, and will be wronger.

But people need to know this.

The scheme that you'll have read about on info-vax/comp.os.vms, which
was discussed as "Galaxies" at DECUS, seems to be the way Digital is
trying to address this. It's a technology path to addressing it, not
one of marketing (and I wish Digital would market OVMS more strongly!!)
but it seems valid. Basically, it'll let OVMS scale to very large
speeds for real problems better than anything else around. It exploits
some good design done years back and grows it, where nobody else has the
design infrastructure done that OVMS has.

Let me give some background.

Consider the barriers to very high bandwidth computing. Demand for compute
power is growing even faster than chip speeds. The problem has always been
how to do it usefully.

There have been massively parallel machines for 15 years and more, and
they handle a few problems, e.g., modelling the atmosphere, very well.
Problems that don't need much communications, not much I/O, but lots
of CPU cycles.

Most real world problems aren't like that. They do I/O, they communicate, they
don't easily factorize. Attempts at running on more CPUs has led to the
development of SMP machines, and of using client/server systems to spread the
work around in some areas. In the OVMS world they led to clusters too, but
the term for non-OVMS systems has meant something rather different and
that difference is critical; I'll discuss that in a moment. The problem
is that SMP machines share a copy of the operating system and have to
synchronize various things, notably file I/O. This takes some time from
EVERY CPU, so SMP really doesn't scale past ten or so processors (if it
gets even that high). Massively parallel systems use several copies of
the operating system, so get to more power, but they still must synchronize
their I/O. That's the killer in the real world. For demonstrations and
low-I/O problems, a server can make it LOOK like every processor has
access to all storage, but still, to get at a piece of storage all the
processors are making some one poor processor carry the ENTIRE load.
It doesn't scale. Get past the demo stage and you'll see the performance
slogs down.

The difference is that OVMS WILL scale. The others won't.

You see, the notion in Galaxies is to have a cluster in a box with some
shared memory. Potentially you can use this to have hundreds of processors
communicating. But one key difference here is that while you'll have
lots of copies of the OS, OVMS uses a distributed lock manager, running
on all processors, to synchronize its I/O. Thus, every processor that
can electrically get to a disk directly does so, and the I/O load gets
carried by lots of processors, not just one. This is fully supported now,
though Galaxies offers the notion that the inter cluster communication
can get a lot faster as well. This kind of synchronization exists ONLY
in OVMS clusters, and allows simultaneous access to disks from many
machines. (In the SCSI space that's why OVMS doesn't need or use
reserve/release commands as well.) Everything else has to use some
combination of servers, reserving devices for a system, and possibly
failover to achieve a semblance of the cluster effects, but cannot do the
simultaneous I/O that lets the many processors actually get work done.

So the strategy is to build something, based on good engineering done
all along, that will beat the competition by maybe an order of magnitude,
and use this to attract enough attention to OVMS to overcome the old
sticky perception that VMS is for old slow iron. Factors of 10 in performance
get hard to ignore.

To me that makes sense.

I will however add that OVMS has other advantages which Digital doesn't
mention much. They do talk about its ability to keep running in 7 x 24 x 365
situations...its robustness. But they don't mention that the good engineering
in it caused OVMS to use a 64 bit date representation from the first. Thus
there won't be a year 2000 problem with the basic OS...that date format
won't run out of gas till about 30,000 AD, by which time there might be a
new calendar anyway. The old Unix "seconds since 1/1/1970" runs out of
seconds in a 32 bit integer in 2038, and systems that have used two
characters for year have much more pervasive problems with date. People
have accidentally set OVMS system dates 1000 years ahead and had the
system run smoothly enough it took days to notice...there have been reports
of this, and utilities to fix the dates up afterwards discussed, on the
info-vax list.

OVMS also has major advantages in its manageability...OVMS clusters can
be managed from any node, and there are LOTS of tools for it, including
some beautiful graphical ones available free on the DECUS symposium
software collections. And it has major security advantages; Digital
has had a culture of great attention to detail in the security area for
as long as I've known people working in the area, and has been to the
wars, in that VMS systems were common targets for 20 years or so and
as a result the security design of the system has become incredibly
strong. And there are third party packages which do realtime monitoring,
file hiding, privilege audit or control, and the like on top of the
already impressive array of what Digital has. 

Some of the security groups, and comp.risks, lately have discussed that
the real need in using the Internet is not better browsers, but operating
systems that have real security models that let people do their work but
keep their critical data out of the hands of competitors. This is 
something that's already available in OVMS. I haven't seen it anywhere
else. It might someday be, but the industrial espionage problem exists
now. OVMS lets you deal with that, so you can get your work done without
opening up your critical data to everyone. It's a story that needs to
be told. I wish Digital would tell it also.

Digital is also working on file systems that can be managed more easily
as larger aggregates in OVMS. I wish that would go faster, but there
are folks working on it.

What I wish Digital would do more of is tell the story of OVMS in its
marketing message. It should be mentioned as robust (7x24x365) as some
ads say...that's true and important. But the quality message should be
more widespread. That is, its scalability should be mentioned...and the
fact that it's the ONLY system that has really scalable I/O. Also its
security. Security is getting more important as network connections are
getting ubiquitous, and people need to know the threats, BUT they need
to know how OVMS deals with them...or at least THAT OVMS deals with
them. I can set things on my OVMS system so that if I run a browser,
some access permissions change so that whatever it wants to do, it
can't get at certain areas of my system. Security holes in the browser
don't matter, because the underlying OS tools protect me from losing
my really vital stuff. Ditto holes or covert behavior in ANYTHING the
browser might download. That's one tip of the iceberg but will
illustrate the point.

In other words, the plan to fix the perception of OVMS is to be technically
too good to ignore. It makes sense, but I wish marketing were done a whole
lot more than it is to tell the whole story of why OVMS is a wonderful
system. There seem to be some folks at Digital that don't think OVMS will
ever grow, and if it's hard to buy and nobody mentions it, that
can be self fulfilling. But there is work going on that might override
that, so OVMS has some chance to grow. I just think there needs to be
more push to tell its story and to ensure that those who sell stuff
within Digital mention OVMS and tell what it can do to give it that
chance. The word "legacy" should not be used, but the word "quality",
which is what OVMS offers, should. That is really what OVMS offers.

Glenn C. Everhart
Everhart@Arisia.GCE.Com