[Info-vax] CRTL and RMS vs SSIO

[Stephen Hoffman]

On 2021-10-09 23:55:05 +0000, Greg Tinkler said:

> Such passion, love it.
> 
> As for stream vs not stream, that appears to be a religious type issue 
> so we will need to disagree on that.
> 
> As for the original 2 issues from the paper 10 years ago.
> 1) updating a random range of bytes in a file, and loosing some updates
>      Using RMS correctly will fix this problem.  It is straight forward 
> to build a sample using DCL, of all things, to get and update 2 random 
> fix length records on the same disk block by 2 separate process and the 
> data not be lost.  This does not loose either updates.
> 2) multiple processes writing to a ORG:SEQ files concurrently.
>    RMS supports this if you use SYS$PUT() and have the file marked as 
> shared.  NB you need to put a record otherwise you have a teared 
> update, i.e. where part of the record is written then part of 
> some-elses record then ... This is independent of VMS or *nix, it the 
> same issue.

RMS is a database, and databases are quite common on OpenVMS and other 
platforms.

Some databases will support recovery from crashes, replication across 
multiple hosts, failover, clustering, and other factors.

For transactional databases, rollbacks are really handy; where you make 
a series of updates and then discover (for whatever reason) you cannot 
complete the sequence. This might be due to an app-detected issue, or 
an app or system crash during the update sequence. If all of the 
updates are made, the app then issues the commit. If all cannot be 
made, the database rolls back to the initial state.

Without transactional processing (in the absence of RMS journaling and 
lacking DECdtm integration), recovering from multi-part and multi-file 
RMS updates get really gnarly when some part of the whole sequence 
blows out.

Various databases found on OpenVMS will completely bypass RMS, too.

Some of the available databases for OpenVMS and other platforms have 
some other interesting features, too. One very common database has a 
portable database format across disparate operating systems, for 
instance. You can copy the database file from (for instance) Linux to 
OpenVMS, and can read and write the database file from within the 
database client and its APIs; without requiring any sort of database 
export/import or database reformatting.

Above is before we get to discussions of (for instance) graph databases 
and object databases and other sorts, which aren't as common on 
OpenVMS. PostgreSQL does have some capabilities here, too. As do other 
databases.

-- 
Pure Personal Opinion | HoffmanLabs LLC