[Info-vax] CRTL and RMS vs SSIO

[Dave Froble]

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?  Even RMS has the BLOCK I/O capability, at least from 
Basic.

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.

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

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.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486