[Info-vax] Reimplementing VMS, was: Re: HP adds OpenVMS Mature Product Support beyond the end of Standard Support

[Bill Gunshannon]

In article <lcr69l$3rs$1 at panix2.panix.com>,
	kludge at panix.com (Scott Dorsey) writes:
> Bill Gunshannon <billg999 at cs.uofs.edu> wrote:
>>
>>1. Actually porting the original VMS, while probably possible, is not
>>a practical solution.
> 
> This is surely true.  It might have been a practical solution a decade ago,
> but it has ceased to be.
> 
>>2. Apparently the idea that nothing but the original VMS is capable of
>>doing the job is no longer true.
> 
> This is true, and it's something of a shame since there are fewer and fewer
> commercial-grade operating systems out there.  On the other hand, networking
> and redundancy have reduced the need for commercial-grade systems too.
> 
>>3. A VMS API and userland running on some other underlying kernel would
>>meet the needs and satisfy the majority of remaining VMS users.
> 
> That's true, although it needs to be combined with a good dcl implementation

Thus my saying "and userland".  A good DCL implementation would be the 
first needed step in a userland.  :-)

> such as that of Boston Business Computing.  

Except that that is a commercial product and talk here has been about
something Open Source.  Don't the FreeVMS people have a head start on
a DCL implementation?

>                                            But it needs also to be a solid
> system underneath... perhaps not as solid as VMS, but solid.

But that goes back to my original comments.  I repeatedly brought up
security, stability, features, etc. and was repeatedly pointed at things
like a Mach Kernel.  Thus my suggestion that the target should be POSIX
so that the indiviual user (OK, shop) can pick the level of underlying
features they feel necessary.

> 
>>4. "a re-implementation of vms system services, rtl, etc, has been done,
>>using unix ipc mechanisms, etc
> 
> This is true, although again these all behave a little differently than the
> originals, if only in terms of timing because the kernel design is different.

OK, I left timing out of my original comments.  But, how many places
rely on this?  I know Bob Koehler has mentioned it but does it really
matter?  How many people who are using VMS for hard real-time now are
going to be interested in anything that downs't come with commercial
support?  Even if, as is now obvious, that means abandoning VMS entirely.

> 
>>Which leads us to the question:  Why is there not already a group
>>working on an Open Source Complete VMS API capable of running on
>>top of any POSIX infrastructure?  This would allow to pick their
>>underlying architecture based on their needs, be it: Linux, BSD,
>>Solaris, Mach, whatever.  Seesm this would make more sense than
>>the current "porting project" that meets several times a month.
>>And could be accomplished by pretty much the same people.
> 
> Mostly because the people who want VMS have either moved off to some other
> system by now, or they are willing to pay for a solution.  Remember, these
> are people who are using to paying for VMS support, so the notion of paying
> for reliable and supported software is not alien to them.

But this contradicts reality.  There is a group of people who meet to
discuss porting applications to VMS several times a month.  They are
not getting paid for this.  There is little if any doubt that these
people are very knowledgable in VMS, including internals.  Maybe they
need to re-target their efforts into the direction of porting VMS
functions and applications to other platforms rather than the other
way around.

What we really need is -lVMS

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>