[Info-vax] CRTL and RMS vs SSIO

[Stephen Hoffman]

On 2021-10-07 17:16:03 +0000, Dave Froble said:

> On 10/7/2021 11:34 AM, Stephen Hoffman wrote:
>> 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.
> 
> Most likely.
> 
>> 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.
> 
> I don't use C, so I don't know much about it.  But isn't this 
> capability already available?

The C standard functions—the equivalent of the BASIC calls OPEN, READ, 
WRITE, et al—are via RMS. There's no knob to tell C "don't do that".

The C default sequential file format creation format on OpenVMS is RMS 
VFC, which has been a perpetual source of confusion and consternation 
for users new to C on OpenVMS.

> Even RMS has the BLOCK I/O capability, at least from Basic.

C doesn't do sector I/O within the standard library, though the native 
platform calls are easily available.

> As far as I know, QIO doesn't know a thing about RMS.  Well, the 
> directory structure does know RMS, and to an extent is RMS.

$qio (and $io_perform) offer sector access through RMS (virtual), 
record access through RMS (virtual), or access to device through the 
file system (IO$_ACPCONTROL XQP), or direct access to the device driver 
and device (logical and physical I/O).

The VIRT_IO virtual I/O paths through RMS and through the XQP are 
cluster-aware, while the LOG_IO logical and PHY_IO physical I/O paths 
are not.

RMS provides record locking for cluster coordination, while the XQP 
provides coordination for the on-disk file system.

>> Better integrate and document the existing range-locking support 
>> available within DLM.
> 
> Yes, for sure.  And if needed, make it much better.
> 
>> 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.
> 
> Oh, no, Steve.  That is much too logical and reasonable.  Can't have 
> that.  We must insure that things stay totally screwed up.

I'd prefer an approach where there's some opportunity to ease new work 
and new APIs into production, and to also retire overtly-busted APIs.

Oracle Rdb was really good at that migration and for as far as that 
went, but most other apps and OpenVMS itself have not managed to copy 
that. Not successfully.

> Don't know how far work had progressed on alternate file systems.  
> Might or might not help to make RMS "just another capability".  But, 
> doing what you suggest would go a long way toward making VMS more 
> useful in the future.
> 
> I've got the suspicion that VMS clusters, while good, create some of 
> the problems in attempting to add new capabilities to VMS.  Need I 
> mention "MOUNT"?  Better segregation might help to add new and 
> different capabilities.  Not sure how easy that might be.

Oracle Rdb and some other databases have cluster access locking, 
whether using DLM or database-level locking.

Other databases can be single-host.

The SQLite port to OpenVMS supports DLM and clustering.

PostgreSQL has been adding replication and clustering:
https://www.postgresql.org/docs/9.5/different-replication-solutions.html

Whether an OpenVMS port of PostgreSQL can incorporate DLM calls is 
fodder for future discussions, once the SSIO prerequisite becomes 
available and a hypothetical future PostgreSQL port becomes stable. A 
stable PostgreSQL will interest some folks, with adoptions depending on 
both intrinsic interest and, um, potential extrinsic factors not yet in 
evidence.

And no, you need not mention MOUNT, having necessarily (re)written what 
MOUNT provides on several occasions.



-- 
Pure Personal Opinion | HoffmanLabs LLC