[Info-vax] CRTL and RMS vs SSIO

[Stephen Hoffman]

On 2021-10-07 01:25:57 +0000, Greg Tinkler said:

> My point is SSIO seems to be focused on just PostgreSQL, whereas an RMS 
> solution is much much easier to program, uses well tested code, and is 
> already cluster ready putting the team ahead of the game and not 
> building issues for the future.

...

Fix the existing RMS data corruption in 32-bit RMS and/or in the C 
library, and get PostgreSQL available on OpenVMS soonest. I expect this 
is the priority for VSI.

Everything else is aspirational.

Integrate stream file access support at the XQP and allow C and C++ and 
other non-punched-card-style app designs and stream- and OO-focused 
languages to optionally bypass RMS entirely.

Better integrate and document the existing range-locking support 
available within DLM.

And in aggregate, stop trying to make the current 32-bit RMS NoSQL 
database more complex than it already is, and re-architect such that 
32-bit RMS NoSQL database becomes just another available database, and 
preferably while providing room for 64-bit RMS rather than trying 
another OpenVMS Alpha V7.0-style 32-/64-bit or FAB/RAB/RAB64/NAM/NAML 
design, and make 32- or (hypothetical) 64-bit RMS not the sole 
persistent-storage "funnel" for structured file access for apps running 
on OpenVMS, short of those few using XQP or LOG_IO or PHY_IO. Existing 
RMS apps are already headed for "fun" as part of the upcoming 64-bit 
LBN work for VSI and for apps, and a whole lot of those apps just won't 
make it past messes similar to apps still tied to ODS-2 naming. I'd 
wager that most existing apps don't yet fully support ODS-5 naming, 
UTF-8 and all, too. Similar app messes with latent 32-bit RMS 
dependencies.


-- 
Pure Personal Opinion | HoffmanLabs LLC