[Info-vax] wrong file format

[Stephen Hoffman]

On 2021-01-09 22:00:27 +0000, 1tim.... at gmail.com said:

> 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:...
>> 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 incremental, or 
>> it's a wholesale migration to a different app and platform.

>From more than a few of these... Work and updates on these apps is 
performed incrementally, or management eventually decides "enough!" and 
announces a migration project to a new app and new platform.

And yes, management can either fund the incremental work, or can 
throttle those efforts and which eventually leads to a replacement 
project. And in various organizations, funding for maintenance is 
tougher than funding for new work.

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

I'm well aware of systems performing this, and I've worked on, have 
refactored, and have migrated similar systems, as well as smaller and 
larger.

Though 1500 users isn't all that telling a scale, it's the speeds and 
feeds and storage involved that'll scale the production requirements.

I might tweak the indexed file settings for SYSUAF, if all those folks 
are really logging in and are not remote. Though these days, I'd tend 
to assume remote.

For some newer projects and newer app development, 1500 users might 
well suffice with a collection of Mac mini boxes, these days.

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

Yeah, that "where am I?" is pretty typical of the sort of code I've 
worked with. Though that's the sort of stuff that I usually migrate out 
of logical names and into configuration files, or into the 
configuration database, though. Outside of maybe using logical names 
for locating devices or files or directory paths, that is. For app 
configuration data that's not related to a device name or file or path, 
logical names tend to be... clunky.

And if there are multiple installations as appears to be the case here, 
moving the apps into kits. I can appreciate the effort involved here 
too, as RMS is a slog around app modifications and app upgrades—the 
difficulties involved here are how more than a few projects have ended 
up with lots of indexed files. Adding and modifying relational database 
tables is somewhat easier, and without disrupting the other 
unrelated-to-the-database-change apps.

And I usually prefer to do security at the OpenVMS level, variously 
with subsystem identifiers. An RTL-based approach can certainly work, 
but OpenVMS security works across all tooling. And subsystem 
identifiers avoid assigning identifiers to users, which can help 
isolate data access.

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

That's where the abstraction layer happens, and—as the work 
progresses—where SQL database queries make things far more flexible 
than does accessing something as rigid and intractable as an RMS 
indexed file can be. Easier queries can be really interesting, whether 
for enhancements and related, or for investigating and reporting data 
and trends.

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

More than a few of these get migrated off OpenVMS, as management can 
decide that OpenVMS and tooling is too inflexible.  Yeah, seems that 
already seems underway here, too. That relational database is where the 
queries that management is interested in are happening.

> 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

You're prolly not going to get much of a boost from RMS here.  Not on 
any reasonable timescale.  An SSD would be an obvious upgrade, if the 
apps are at all I/O constrained.  Maybe from OpenVMS x86-64 and faster 
hardware, and from whatever SSD/NVMe storage is supported there. And 
the RMS parameters that I'd mentioned earlier in the thread.

> your mileage may vary.

Ayup. Always does.


-- 
Pure Personal Opinion | HoffmanLabs LLC