[Info-vax] CRTL and RMS vs SSIO

[Dave Froble]

On 10/9/2021 2:22 PM, Arne Vajhøj wrote:
> On 10/9/2021 12:47 PM, Stephen Hoffman wrote:
>> On 2021-10-09 10:19:42 +0000, Greg Tinkler said:
>>> On Saturday, 9 October 2021 at 6:00:48 pm UTC+11, Vitaly Pustovetov
>>> wrote:
>>>>> So the main issue is file IO, so change CRTL to use RMS.> >> > gt
>>>> CRTL uses RMS for file I/O. But there is an issue with concurrent
>>>> access of multiple processes to the same file in stream mode. And we
>>>> had a choice - 1) rewrite half of Postgres by inserting file
>>>> locking; 2) add a new SSIO (Shared Stream IO) service to VMS.
>>>
>>> Sort of.
>>> RMS worked and has been working of 40+years and does not have these
>>> concurrent access issues!  NB there is no such thing at an OS level
>>> of stream anything, every thing is clumps of data being buffered is
>>> some way, the API that accesses that data from the higher levels may
>>> be stream based.  In this case it is CRTL's role to translate the
>>> clumps of data into/from stream API.
>>
>> RMS is a pretty good database, for its time.  Alas, its become rather
>> more dated, with an API design that is complex and limiting, and in
>> competitive terms RMS is badly feature-limited.
>>
>> If you need a key-value store and where the developer entirely owns
>> the fields used within the punched cards, and where y'all can fit your
>> files in 2 TiB (or bound volume sets, gag), RMS is still a fine choice.
>
> Hoff I think you are muddying the water here.
>
> This discussion has so far been about ORG:SEQ files.
>
> ORG:IDX files are a Key Value Store. But that is a totally
> different topic.
>
> Arne

No, it is not.  The OP declared that RMS should be used for that.

You are correct that we're concerned about stream files, but claims 
about RMS have been part of the discussion.

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