[Info-vax] Moving away from OpenVMS

[John Wallace]

On May 21, 2:50 am, Eric Johnson <johnson.e... at gmail.com> wrote:
> 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

Is there not some serious wheel-reinventing being looked at here? OK,
some organisations do prefer reinventing from scratch rather than
purchasing, but...

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

Sector7 has already been mentioned once in this thread. I only know
what I've read here and elsewhere, but their stuff would appear to
cover that, and a whole lot more too, if it's still around - I believe
their UK subsidiary company went away, but that doesn't mean they're
not still around. No idea what Sector7's costs or quality are, but I
know what re-inventing the wheel usually costs (and what its impact on
support is).

"The idea here is a bit like an RPC model. "

Fine idea. Then add a few other essentials such as generic security
services, location brokers and the like. In fact why not set the
wayback machine to the 1990s and call it CORBA (or, maybe less likely,
DCE)?

Bear in mind that for a lot of folks, whether it's right or it's wrong
according to contributors here, there is a short term goal to get off
VAX, Alpha, and Itanium, and a longer (but not long) term goal to get
completely off VMS regardless of the business impact of lost VMS
functionality e.g. by abandoning VMS-specific functionality such as
decent security, decent clustering, etc, by redesigning the
application from scratch for a commodity database on a commodity OS
(or going to IBM in some cases).

In view of the relatively short lifetime of the mixed OS
implementation, any investment in retaining VMS (real or emulated) may
need a reasonably short payback time in comparison with traditional
VMS projects (though maybe not in comparison with MS-centric projects
where a three year lifecycle seems remarkably common).

Not saying what you are suggesting is a bad idea (it isn't, at least
on paper), but wondering if there are particular reasons why you are
thinking of starting from a low level of abstraction when higher level
more functional stuff apparently already exists, especially if there
is a real budget for the project?