[Info-vax] wrong file format

[Dave Froble]

On 1/9/2021 5:00 PM, 1tim.... at gmail.com wrote:
> 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.

Totally agree, as I may have mentioned.

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

Using logicals may work, but I sure would not do it that way.  Much 
better to have the split within the applications.

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

This is where I get confused.  Yes, possibly look at all options, but 
why specifically scrap VMS?  Should it not be included in the possible 
options?

Even starting over, VMS still has much to offer.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486