[Info-vax] VMS porting/rewrite, was: Re: [OT] Wirth style languages, was: Re: Obscure Ada compiler vendors?

[Simon Clubley]

On 2013-04-08, Keith Parris <keithparris_deletethis at yahoo.com> wrote:
> On 4/4/2013 11:01 AM, Stephen Hoffman wrote:
>> Rewriting all of OpenVMS?  That'd lead me to this state:
>> <http://www.youtube.com/watch?v=3L6i5AwVAbs>. Even if you were to be
>> successful with a rewrite, once you're done with that very substantial
>> and years-long effort and investment, you would have something
>> approximating current-day VMS. Not the features and functions that
>> folks would would want and would expect after all those years.
> ...

This is talking about a rewrite of the code from the ground up, maintaining
user level API compatibility, but with different and more modern internals.

>> The rest of the
>> market is not standing still here, and you're talking about a project
>> that took three or five years last time (Alpha to Itanium) for a fairly
>> straight port with very few changes, and with an engineering team that
>> was very familiar with VMS assigned to the effort full-time.   ~Thirty
>> million lines of Bliss and C and Macro32 is a huge project to
>> reconstitute.

This is talking about a port of the existing code base to a new
architecture.

These are two separate issues and people are mixing them up.

Which one are you thinking of Keith ? (This confusion showed up on the
mailing list as well, so I think it's important to know exactly what
you are thinking about here.)

>
> By this logic, the GNU project and Linux could never have caught up 
> with, much less surpassed or exceeded, UNIX capabilities.

The GNU project started out as building a compiler and replacing vendor
specific versions of Unix commands/utilities with their own. (Unix makes
it easy to replace things a bit at a time; VMS does not.)

However, the GNU project's own OS project, Hurd, stalled during development.

Linux is far cleaner internally than VMS is (when it comes to porting),
with a clean separation of architecture specific and non-specific
components, and was written from the beginning in a portable language.

As I mentioned on the mailing list recently, a group of university
students could probably port Linux to a new architecture in a reasonable
amount of time. That is simply not going to happen with the existing
VMS code base.

Furthermore, plugging new components into Linux or another Unix OS is
easy, especially at user (ie: non-privileged) level because the Unix
API is designed around the concept of lots of separate programs doing
their own thing, but linked together by well defined and _public_
interfaces.

For example, writing a new shell for Linux is relatively easy. How does
that compare to replacing DCL on VMS ?

Since porting the existing code base does not appear to be viable, that
leaves a new implementation which maintains the user level VMS API,
but with very different internals.

There was a experiment carried out in the 1990s with porting VAX/VMS to
a microkernel architecture using Mach. This was not a port of VMS to
another hardware architecture (the Mach microkernel ran on a VAX in
this case) and the result was not even remotely production ready,
but it did cover some of the issues which would be encountered.

I read the paper which came out of that research again this weekend and
it's worthwhile for anyone interested in this subject to actually read.
I only have the original PS version, but Paul has a PDF version on his
website at http://www.sture.ch/vms/Usenix_VMS-on-Mach.pdf

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world