[Info-vax] Message from HP.

[Bill Gunshannon]

In article <l899ro$11t$2 at dont-email.me>,
	David Froble <davef at tsoft-inc.com> writes:
> Jan-Erik Soderholm wrote:
>> David Froble wrote 2013-12-11 00:52:
>>> gce at gce.com wrote:
>>>> It seems unlikely that there is sufficient expertise at HP to do a
>>>> port of VMS again without significant growth to its VMS engineering
>>>> group. The codebase has been ported twice now, so it's a bit easier
>>>> to do than the first 2 times, but since the path has been in part to
>>>> compile macro2 and Bliss (and there was a lot more of the former) a
>>>> new compiler backend would be needed. The old work on x86 did not get
>>>> far, and would need heavy rework even if its code can be located any
>>>> more, since it would make sense only to target x86-64. More
>>>> importantly, though, even if you could get the whole VMS function
>>>> base to work on x64 iron, it would remain a niche sized system.
>>>
>>> Yes it would, but it might just be very valuable to those still using 
>>> VMS.
>>> In my opinion, it isn't something that should compete with desktop PCs,
>>> tablets, and smart phones.
>>>
>>>> Consider that a new filesystem is obviously needed now, if only
>>>> because single disks twice the size ODS5 can support are readily
>>>> available now, and that will get worse.
>>>
>>> Well, the current filesystem seems to work for current users. 
>>> Personally, I
>>> don't see the disk size an immediate problem, unless disks VMS can us
>>> become no longer available.
>>>
>>>> I am reminded of the kludges
>>>> DOS-11 used when block count exceeded 65535... Beside that, new
>>>> drivers are needed for current other peripherals and that's hard to
>>>> get support for.
>>>
>>> Not for current users.
>>>
>>>> The Windows model is closer to that of VMS (since it
>>>> descends from it (morganatically?) but replicating a closed source
>>>> model like that looks impossible to me. Other generic application
>>>> code also is handled differently in VMS from other systems. There
>>>> have been efforts over the years to find ways to support other OS
>>>> functions (most notably unix fork) inside VMS.
>>>
>>> Current users may not think fork is an issue, nor some other things also.
>>>
>>>> Today I suspect that
>>>> it would make more sense to try and support VMS specific things on
>>>> top of some other system, Linux being one I would consider first.
>>>
>>> I know little about Linux, but my guess is that this might be harder than
>>> porting VMS to x86, and, most likely would not be compatable with other
>>> versions of Linux, thus putting VMS capabilities right back where they
>>> started, not really compatable with Unix/Linux.
>>>
>>>> That would be an interesting effort, to bring in ASTs, forks, DLM,
>>>> and also a usable ODS compatible filesystem and record handling
>>>> system in. Figuring out some way to run VMS binaries (unless by
>>>> emulation) on x86 would be no piece of cake either, so at best you'd
>>>> want to be able to rebuild sources.
>>>
>>> I'd definitely want the compilers.  (At least MACRO, Bliss, and Basic.)
>>>
>>> :-)
>>>
>>>> I am hard put to imagine why
>>>> anyone would want to bring ALL the nuances of RMS over anywhere else
>>>> - there are loads of odd capabilities in there - but something that
>>>> would handle 95% of the cases and 99.99% of what is used is likely
>>>> doable. This does not sound like something a corporal's guard tasked
>>>> also to fix any bugs found and to try to keep existing VMS running
>>>> with some current peripherals is likely to have spare time to do. And
>>>> if done, would HP promote and sell it, when their promotion of the
>>>> current VMS capabilities even in areas where data integrity and
>>>> security are key has been so lacking? It would be perhaps more useful
>>>> to get together lists of functions that exist now only in VMS, and
>>>> see whether outsiders might be able to recreate them elsewhere with
>>>> some value enough to justify the work.
>>>
>>> Forget HP.  If such is to happen, It will need to happen in a similar
>>> manner to Linux, user groups with an interest in seeing it happen. 
>>> Possibly
>>> VMS versions of RedHat and other Linux providers.
>>>
>>>> (If HP gives up on VMS, it would be most decent of them to open
>>>> source the VMS sources, as much as they can, but any third party
>>>> would have to figure out answers to the above anyway, and I suspect
>>>> what might be needed can be done currently by third parties if they
>>>> had justification to do it.)
>>>>
>>>> Glenn Everhart
>>>
>>> Yes, everything would depend upon HP making as much of VMS as possible 
>>> open
>>> source.  For some of the stuff they cannot, well, lots is obsolete, and
>>> could be replaced, if needed.
>>>
>>> I've pondered the idea of some remaining users with deep pockets
>>> threatening HP to open source the OS, or face a class action lawsuit. 
>>> Yeah,
>>> most of us probably don't like lawyers.  If such should happen, HP would
>>> look at the cost of defending, regardless of the merits of the case, 
>>> vs the
>>> cost of releasing the code.
>> 
>> As far as I see it, VMS is of low value without Rdb.
>> I do not see a "newVMS" that hasn't Rdb in the picture.
>> And Rdb is, as I'm sure everyone know, not owned by HP.
>> 
>> 
> 
> There is probably more than a few VMS sites that do not use RDB.  Just 
> because you use it doesn't mean that your environment is typical.

Other than running on VMS, what does RDB offer that is not available
from any other DBMS?

> 
> If there was an open source VMS, or more than one, it would be up to 
> Oracle as to whether they would want to run RDB on such systems. 
> Though, I don't have a clue what else they would do with it.

Dump it.  See question above.

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>