[Info-vax] wrong file format

[Stephen Hoffman]

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:
>> 
>> Given there's a widely-used, portable, and robust SQL database already 
>> ported to OpenVMS, and the port was integrated with the lock manager, 
>> and it's free... ...Tweaks around the edges of RMS which would require 
>> app code changes, and replacing or acquiring CDD/Repository—for a 
>> fraction of what SQL provides—don't seem optimal.
> 
> Don't disagree with what you are saying, but going to a database is a 
> "rip and replace" option, vs incorporating some convenient features 
> into legacy code.

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.

For OpenVMS updates, there's also the discussion and trade-offs around 
looking and working on older approaches, and looking at what work will 
be advantageous for new work, and refactoring, and substantial app 
updates.

Unfortunately, RMS is always going to be (comparatively) old and slow, 
and enhancement efforts around the edges aren't going to make it 
appreciably faster, nor appreciably more capable, nor more interesting 
to a whole lot of new work.

> If I'm supporting a large application with a large codebase, I'm not 
> interested in ripping out the guts and making it use a relational 
> database. I am, however, interested in making incremental improvements 
> and simplifying code where possible.

If this follows the usual model, prolly also under-funded, 
under-staffed, and/or under-maintained, and—if the app is resident on 
HDD—ripe for SSD.

> The ROI isn't there for most companies to replace the existing file 
> system. The ROI is there to fold in incremental improvements in the 
> course of doing enhancements and new development. The ability to do 
> sets of data easily makes importing and exporting data to outside 
> systems easier, or exposing data via web services easier. It's a lot 
> easier to create a service that grabs a bunch of records in a single 
> call than to have to loop and accumulate the data for the call. I 
> suspect many of us have had to implement something like this. (Yes, 
> solutions like Connex exist)

SSDs can mask multitudes of coding issues. Cheaply.

For HDDs, increasing MBF and/or GBC settings can sometimes help with 
various app designs; increased memory usage to try to compensate for 
slower I/O.

MBF: RAB$B_MBF / XAB$_MULTIBUFFER_COUNT / FDL CONNECT etc.
GBC: FAB$W_GBC / SET FILE filename /GLOBAL_BUFFERS=count etc.

For apps that write lots of stuff, file extension sizes are a fairly 
common performance throttle, though too-low extension sizes can 
sometimes be masked by larger storage cluster factors.

> It's funny how years later, clever code usually turns out to not be.

As for dragging stuff off RMS and into a relational database, I've done 
that and in various contexts. Incrementally. Usually with an app API 
that isolates the file system layer, and/or by incrementally moving 
hunks of the data into the database.

But I don't see RMS getting anything akin to a WHERE clause, either. 
Record caching hints seems unlikely, too.



-- 
Pure Personal Opinion | HoffmanLabs LLC