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

[Simon Clubley]

On 2014-02-04, Bill Gunshannon <bill at server3.cs.scranton.edu> wrote:
> 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:
>>> 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).
>

Oh, I know. I just picked one example to keep it simple. The issue
here is that POSIX is a interface offered by a operating system
to it's applications and requires some form of operating system
underneath to implement that POSIX required functionality.

>> 
>> 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.
>

For people who are happy with a userland VMS API layer running on top
of a operating system which doesn't resemble VMS (such as Linux/Unix)
then that's certainly a option.

For people who want something which implements the unique kernel level
functionality of VMS then that's where NewVMS running either on
bare metal or on top of a microkernel comes in.

>> 
>> 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?
>

No. :-)

You are confusing the services provided _by_ QNX to it's userland
applications (in the form of POSIX) with the services required from
the microkernel to implement QNX itself.

Simon.

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