[Info-vax] Message from HP.

[Jan-Erik Soderholm]

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.