[Info-vax] wrong file format

[1tim....@gmail.com]

On Thursday, January 7, 2021 at 2:11:22 PM UTC-7, Stephen Hoffman wrote:
> On 2021-01-07 20:35:57 +0000, 1tim.... at gmail.com said: 
> 
> > On Thursday, January 7, 2021 at 11:24:06 AM UTC-7, Stephen Hoffman wrote: 
<snip>
> There is no "rip and replace" option. Not in this context of OpenVMS, 
> nor in the context of most of the older apps. These are ncremental, or 
> it's a wholesale migration to a different app and platform. 
> 
</snip>

this is where we part.

consider an application with a large number of files, supporting 1500 users across 40 locations. Consider the application has multiple tools accessing the RMS files. If the system is tightly integrated, you don't peel off one or two files and shove them in a relational database. Something as simple as a customer master, will impact sales, receivables, purchasing (vendors can be customers), customer specific pricing, customer specific part numbers, price contracts, consignment inventory, customer history, analytics, etc. Trying to incrementally move to something other than RMS is costly.

The design considerations for Branch mapping - we do things like embedded branch numbers into the logicals used to access files. switching between branches is easy. finding branch specific files is easy. The mechanics are invisible to the programmer. it is literally as simple as saying Branch(fileNumber) = "00423". Security is enforced at the RTL level (shared images used by all applications). Some I/O functions are a join of multiple files, hidden from the developer or the user. A read of the Item master, for example is returning a single record built from two ISAM files behind the scenes. This is handled via a user exit that is called in place of the normal I/O, again handled by the RTL behind the scenes.  Any record returned by an I/O could be a view into multiple files. The application doesn't know or care.

It would be a multi-year project to find all the instances where outside tools, tools using soft file declarations - i.e. dictionary based access, etc. just to move one file out of RMS. It doesn't become easier to move multiple. You have applications that were not designed to build quires and deal with record sets.  We're in the more than a million dollar territory, for just a small subset. You're in the territory where we scrap OpenVMS and look at other platforms and products. The ROI is not there to stay on VMS and rip out RMS code for even a handful of files. 

It also isn't there to simply bolt on a few new applications that talk to the database - you lose all the integrated tools and things that hide RMS particulars from you.

We put hooks in our I/O routines and replicate data to an Oracle database (not my choice) in near real-time. works pretty good, but the plumbing to get it into oracle is probably too complex. (we capture metadata about the I/O operation, push it into a DMQ message queue, pull it out using JAVA on the other end, use JNI to get data, and then commit to Oracle) It is, however very fast and robust. I digress. we use this for stuff outside VMS. This also eliminates stuff like Connx.

anyway, it would be far less disruptive and far more cost effective to get some improvement from RMS, than to try and replace parts of it. this would extend the life of VMS greatly.
IMNSHO

your mileage may vary.