[Info-vax] wrong file format

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

On Thursday, January 7, 2021 at 11:24:06 AM UTC-7, Stephen Hoffman wrote:
> On 2021-01-07 17:44:40 +0000, 1tim.... at gmail.com said: 
> 
> > So do I, a product with a data dictionary and routines that use it to 
> > get at data. 
> > Short of making a relational or object oriented Database part of the 
> > OS, some extensions to RMS would go a long ways to being useful and 
> > shouldn't be that hard to implement. Once you start wandering into 
> > relational operators and joins, stuff get more complex and at that 
> > point you really should have a database...
> 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.
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

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

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)

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