[Info-vax] Moving away from OpenVMS

[Eric Johnson]

On Thursday, May 17, 2012 5:33:28 PM UTC-4, JF Mezei wrote:

> One of the many values of VMS was its rich set or proprietary system
> services.
>
> Any shop that has developped a lot of stuff on VMS over decades is bound
> to have developped many dependencies on VMS specific stuff.

Here's a thought on a way to begin disentangling oneself from the platform.  It attacks the problem from a slightly different angle so it may not work for everyone.

Consider a C program that made use of functions like SYS$CONNECT, SYS$OPEN, and SYS$TRNLNM.  It would be nice if one could just re-compile that on Linux and run it.  But of course, you can't do that.  If it was that easy, these threads wouldn't exist here on comp.os.vms.

Being rhetorical here, why can't one just recompile it?  Well, for starters the compiler won't be able to find the include files you need.  Files like rmsdef.h, namdef.h, fabdef.h, etc won't be there.

With a little bit of effort, you can get those to be accepted by gcc nearly as is.  You have to deal with a few common issues such as __int64 and pragmas for packing, but beyond that, they are just straight up headers.  There's nothing that unnatural about them apart from Digital's fondness for the dollar sign.

But that doesn't satisfy the linker now does it?  The linker of course asks for an implementation to SYS$TRNLNM and whatever else you might have called from starlet.h.  So what do you do?

Instead of attempting to implement your own solution of SYS$TRNLNM, why not forward that invocation back to a peer process on VMS?  Same for SYS$CONNECT, SYS$OPEN, or LBR$GET_MODULE or any of the other common user mode pieces of functionality.

If you get the native headers to compile on linux, it's fairly easy to write code to perform a deep copy of the entire structures that are passed into those routines.  

The idea here is a bit like an RPC model.  One would completely replicate the function call such that the runtime on linux is completely unaware that the execution is on linux rather than on VMS.  But the underlying SYS$ functionality is still performed on VMS.  Everything is copied back including the return value.

I realize there are a lot of "yeah, buts" to be placed here.  I'll preemptively enumerate some of them.

1) But what about ASTs?
2) But what about network performance/latency?
3) What about C library routines (eg: fopen, read, stat, etc).
4) How should the vms server process match up to the client linux process?
5) But why would you do this??!!  How does this help??

For now, I'll just address (5) and address other topics if there's really interest in the thought here.  And these are nothing more than thoughts.  I have no product to offer and no intent to do so.  It's more of an intellectual curiosity to see if the ideas are useful.

As I see it, there are really two issues confounding VMS systems.  First, the Itanium CPU is moribund.  Regardless of HP's announcement, it's clear the x86 has surpassed it and will continue to be the future for the mainstream commodity world.  Second, VMS is effectively at the end of the line.  Tragic, but true.

It's understandable that those problems get lumped together, but it might be useful to see them as separate problems.

I think I can articulate an approach that at least enables you to move your CPU load off of VMS while mapping out the nature of your dependency to VMS.  If one can successfully remote the access to VMS, you are turning your VMS nodes into a sophisticated "SAN head".  Once all of the execution is then on another OS, you can then begin the task of redirecting those pieces to other solutions.

One of the features of VMS that I think a lot of people admire is how easy it is to just "add a node" to the cluster.  It's a great way to expand your capacity.  It also makes it easier to migrate to newer hardware.  One can bring in the newer nodes and then slowly retire the older ones.

I think an effective migration strategy off of VMS has to consist of finding a way to get a "linux node" to be as near "peer like" as possible in that VMS cluster.  Linux processes would have to be brokered through another process on a VMS node, but I think one can get very far with this approach and then ultimately cut the cord.

The approach doesn't work for everyone.  I think it works best for a system that is still growing and would need greater performance and capacity in the future.  Systems that are mature should probably stay where they are.  Also, it's an approach that would require one to have access to most of the code too.

Rather than write a tome on the topic, I thought I'd quickly sketch out the idea, and see if there was interest in fleshing it out more.

EJ