[Info-vax] Moving away from OpenVMS

[johnson.eric at gmail.com]

> 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

I'm advocating a level of abstraction that matched what current code was doing.  I don't see it as low level of abstraction vs higher level abstraction. I see it as - providing a way for current code to be recompiled on a new CPU and still have real time access to the data sets that are currently warehoused in an existing VMS cluster.  Real time access through native APIs. 

One of the themes in this thread is that everyone wishes HP would just port VMS to x86. I certainly think that's a good technolgical move for VMS but I don't think it will happen.

So if that's not going to happen - is there a way to provide the benefit of an x86 CPU upgrade without completely uprooting out of the VMS investment?  I think the answer lies in providing a very low latency high speed pipe between a Linux box and a vms node.

Such a pipe would enable one to get access to the files in a way that native vms code would want it and not the "narrow" view that NFS/Samba provides. Its not just files either  dont forget about things like SYS$TRNLNM.  And just as important - share access with other systems and processes in a clustered environment so that they are oblivious to the fact that some parts of the system are now puppet mastered from an x86 box. 

I can understand the comparisons to CORBA, ORBs, DCOM, SOAP, RESTful, web services, etc and their history of hype. I think some of those complexities can be avoided by keeping a simpler process model and not trying to be so general. I see this approach as being philosophically closer to the ATA over Ethernet mindset than CORBA. 

EJ