[Info-vax] CRTL and RMS vs SSIO

[Arne Vajhøj]

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