[Info-vax] Message from HP.

[David Froble]

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.