[Info-vax] Message from HP.

[johnwallace4 at yahoo.co.uk]

On Tuesday, 10 December 2013 17:55:33 UTC, g... 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. 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. 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. 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. 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. 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 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.
> 
> 
> 
> (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

Can we try a slightly different approach, acknowledging the understood 
problems, but looking more analytically at what will actually be needed in 
three years, rather than what's been available for the last three decades (much 
of which is of historical interest but maybe not relevant in 2015).

Bear in mind that I have no idea what's still in Bliss, and that sounds to be 
important. Also, I know I'm grossly oversimplifying, I'm playing at being a 
manager.

Core AMD64 support: doesn't exist for VMS, but the AMD64 system hardware 
exists, and is tried tested and proven with various other OSes. Details like 
memory management, two modes vs 4 modes, etc, need sorting but are presumably 
not insurmountable (SMOP, right?).

Peripherals: systems being designed today won't have that many direct-connect 
peripherals. Generic Quickpath support presumably already exists for VMS on 
IA64, why would QuickPath on x86-64 be a huge effort? 

Lots of stuff (generic serial, printers, automation devices, X11 graphics, etc) 
connects via LAN and is therefore hopefully supportable with not too much 
effort.

Storage will frequently be on a SAN nowadays (or could readily be migrated to 
one?), connected via a PCIe or whatever card, drivers for which already exist 
for VMS on IA64 (and for other OSes on x86-64).

For direct attach storage, might customers accept (initially) that the 
available space is still limited by ODS2 - after all, the applications aren't 
suddenly going to need more storage than they've had for the last ten years, 
even if the disks (local or SAN) can provide it. 

SCS over the CI is dead, SCS over the LAN is the answer. Effort needed?

The distributed lock manager would be essential (otherwise it isn't really 
VMS). 

Would anybody care if they couldn't (initially) direct-connect (T)MSCP devices? 
That's what MSCP serving (or a SAN inteface) is for, isn't it? 

And so on.

Basically, think about what likely VMS-centric applications will need three or 
five years from now, not what's historically been available for the last three 
decades.


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

Probably not, under current management. If you're an auto manufacturer making 
cars and minibuses, and can't make minibuses profitable even though others can, 
do you close the minibus business down or sell it off? Which would current HP 
management do?


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

Sector 7 claim already to have that (maybe Transoft too). But the *system* underneath doesn't behave like VMS does. Sometimes that doesn't matter. 
Sometimes it does.


"even if you could get the whole VMS function base to work on x64 iron, it 
would remain a niche sized system. "

Is it necessary to have the whole VMS function base (from day 1, or ever)?

Yes it would be niche. Niche markets can be profitable if played right. One 
size does not fit all.


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

Indeed. But first consider just how much of VMS you really need to make a 
worthwhile port. (Ignoring, for now, minor details like cooperation from HP HQ).



I shouldn't really attempt to trivialise this because it won't be a small task. But it's hard to see why it wouldn't be significantly smaller than the Alpha port or the IA64 port. (Good job, because the engineering resources, inside or outside HP, may well be more limited too).

As my old boss used to say, "nobody ever said the job was going to be easy". 
But he never had the pleasure of doing business with HP.