[Info-vax] a cool database... as replacement for RMS index-sequential files:: Was: VSI working on alternatives to Oracle Classic database:

[Stephen Hoffman]

On 2021-01-20 17:06:43 +0000, gérard Calliet said:

> Le 20/01/2021 à 16:40, Arne Vajhøj a écrit :
>> For an existing VMS application then converting is most likely a good 
>> thing in the long perspective, but since it means changes, then it 
>> needs some analysis on when to do it.
> My question is just about that.

I've been migrating key-value to SQLite and ilk as the results are more 
flexible, and are far easier to extend.

Key-value store migrates into a relational database trivially.

Have I been migrating everything? No. Some of it. Yes. And using 
relational databases with newer code.

The test suite for the SQLite app rivals or surpasses that for OpenVMS 
itself. It's extensive. Dr. Hipp and folks are quite good at testing.

And for those that think SQLite is for relatively small environments, 
sure, but pragmatically so too is OpenVMS—nowadays. Scales of computing 
and of apps have changed. 2 TiB isn't as big as it used to be, etc.

> I received a lot of opinions about conversion from applications based 
> on indexed-sequential to relational database which are saying it 
> represents a huge structural transformation, because of the very 
> different philosophies (for example about how to normalize, how to deal 
> with cobol redefines or occurs clauses, etc,...).

Not in my experience.  An indexed-sequential migration is direct. Can 
you also choose to re-normalize or alter or update your storage, or 
your data design? Sure.

There are and can be concerns around the source code, because RMS is 
integrated with COBOL, BASIC, etc., and SQLite or Oracle Rdb or 
otherwise is not, and there'll either need to be calls replaced, or an 
abstraction layer added between the source code and the data store. 
Oracle Rdb can implement its own abstraction layer with the precompiler 
and which can help with this effort, though that precompiler then ties 
you into Rdb.  This is an incremental process, and can take a while to 
design, deploy, and to then migrate.

Mapping from RMS calls to key-value in a relational database is 
straightforward. You have one or more keys, and associated data. That's 
one table within the relational database. Maybe a table and a few 
singleton tables to hold index values if you're using a particular 
local allocation sequence not otherwise supported by your chosen 
database. It's also fairly common to see multiple key-value indexed 
files and some app-associated configuration data files and related 
baggage transition into one database, with multiple tables. 
Normalization tends to involve discussions of adding support for UTF-8 
encoding or (human-)language-specific sorts or such; more 
enhancement-focused.

> I think there are been a lot of work done on that in the mainframe 
> environments, and a lot of commercial proposals. It seems they are 
> dealing with non trivial issues.

Mainframes have some interesting ideas, such as the approach used to 
insulate System i from the hardware.

Few ideas of which are arguably within reach of VSI, at its present 
scale and budget.

And mainframe sites aren't going to migrate to OpenVMS in sufficient 
numbers to matter, if they decide to migrate off IBM at all.

> But perhaps something can be done and there are innovative methods for 
> that. I have not a definitive opinion on that. And because of what you 
> have told, I was a little bit curious.

Mainframes were something DEC marketing was focused on an aeon or three 
ago, and IMO that focus was and remains ill-considered; aimed at the 
wrong end of the IT market.

Download SQLite or such and try it. Yes, it's more complex than RMS 
key-value stores. More flexible, too. Most data design changes are 
vastly easier, though. So to is ad-hoc reporting, etc.

BTW: there's a new edition (2018) of Fowler's Refactoring book 
available, for those familiar. The earlier edition was a good 
discussion of how to refactor and how to update an existing code base, 
which then makes it easier to further adapt and change and update your 
code.



-- 
Pure Personal Opinion | HoffmanLabs LLC