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

[Bill Gunshannon]

In article <lcrbhq$49u$1 at dont-email.me>,
	Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
> On 2014-02-04, Bill Gunshannon <bill at server3.cs.scranton.edu> wrote:
>>
>> So, based on more recent comments here, I draw these conclussions.
>>
>> 1. Actually porting the original VMS, while probably possible, is not
>> a practical solution.
>>
> 
> Totally agree with this; this is simply not a viable option.
> 
>> 2. Apparently the idea that nothing but the original VMS is capable of
>> doing the job is no longer true.
>>
> 
> I have not thought that was true for many years now.
> 
>> 3. A VMS API and userland running on some other underlying kernel would
>> meet the needs and satisfy the majority of remaining VMS users.
>>
> 
> I don't know here if you still think of a microkernel as just another
> Unix style kernel. If you still think this, you _really_ need to do
> some reading/research on microkernels because you are _way_ wrong.
> 
> A POSIX level VMS API emulation is absolutely not, in any way, shape or
> form, even the slightest bit comparable to the servers/tasks you would
> implement on top of a microkernel to produce something which looked
> like VMS to the userland applications.

Earlier comments (not by me) refering to microkernels said they, too,
supported POSIX calls.  My point in stressing POSIX is if people are
actually going to do this it should be done in a manner that doesn't
paint VMS into a corner, again.  POSIX is, as far as I know, the only
standardized API out there.

> 
>> 4. "a re-implementation of vms system services, rtl, etc, has been done,
>> using unix ipc mechanisms, etc
>>
> 
> That's a viable option if all you do want is a POSIX level emulation
> on top of a Unix kernel and is another option to be considered.
> 
> However, that is not what people like myself are talking about when
> suggesting a microkernel approach.

So what are you suggesting?  Another real tight niche that VMS can get
locked into again?  If the layer between the new VMS and some kernel is
not something standard then you risk VMS once again being on a deadend
platform base.

> 
>> 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.
>>
> 
> Once again, talking about running a VMS layer on top of a POSIX base
> makes sense when your underlying operating system is Unix 

Here is where you seem to be confused.  POSIX != Unix.  The API may
look like Unix and it may even have been based on Unix but today,
it is an API standard and is supported by many different non-unix
OSes incuding Windows and QNX (more on this in a minute).

>                                                            but it
> makes no sense when talking about reimplementing VMS on top of a
> microkernel. In the latter case, the operating system _is_ (New)VMS,
> not Unix; it's just that it's implemented on top of a microkernel
> instead of the underlying physical hardware.

No argument from me on this point. That's what I am calling for.
But, you seem to think that somehow microkernel and POSIX are
mutually exclusive.  I just looked and most of the stuff I saw
listed microkernel and POSIX in the same breath.

> 
> If you don't understand this, then you have your abstraction layers
> all confused.

Well, given that VMS is not going to be re-written from scratch for
a new hardware platform, the abstraction layer is what needs to be
written to make VMS run on something other than it's current, dying,
hardware platforms.  I am merely suggesting that it needs to be an
API that is not going to face the same uncertainty and eventual death
that VMS now faces.At this point in time, that seems to mean POSIX.

> 
> Simon.
> 
> PS: And as for real time latency issues, once again don't forget QNX
> is implemented as a microkernel architecture. That's no guarantee it's
> possible with the FreeVMS design, but the QNX case does show that
> it's something which is not impossible to achieve.

Up to this point, I had not mentioned QNX because I thought they had
gone under.  But a quick look shows that they released some of their
source (for some reason!) but are still in business.  So, yes, they
are yet another possble host for a VMS abstraction layer.  And, yes,
they are microkernel and, yes, they are POSIX.  See my point?

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>