From: arne@vajhoej.dk   
      
   On 8/16/2025 7:24 PM, Arne Vajhøj wrote:   
   > On 8/16/2025 4:29 PM, Robert B. Carleton wrote:   
   >> On Sat, 16 Aug 2025 16:06:50 -0400, Arne Vajhøj wrote:   
   >>   
   >>> On 8/16/2025 2:00 PM, Robert B. Carleton wrote:   
   >>>> On Fri, 15 Aug 2025 09:48:25 -0400, Arne Vajhøj wrote:   
   >>>>> For non-Rdb usage there are no license or technical reasons to prefer   
   >>>>> OCI over  AWS, Azure or GCP.   
   >>>>   
   >>>> As an aside, How many non-Rdb users never moved off of using RMS in   
   >>>> their applications? It seems like some of those would be candidates for   
   >>>> moving to the cloud.   
   >>>   
   >>> I assume you mean RMS index-sequential files.   
   >> I did.   
   >>>   
   >>> There must be a lot. If I were to guess then it is still the most common   
   >>> VMS persistence technology.   
   >   
   >> I'm not much of a coder, but I assume that rewriting code already using   
   >> index-sequential files would be a non-starter for some. Maybe VSI can   
   >> maneuver this situation into something like IBM has with their data sets.   
   >> New development incrementally modernizing these systems, rather than   
   >> replacing them.   
   >   
   > Index-sequential files in Pascal, Basic and Cobol are pretty   
   > slick in my opinion.   
   >   
   > What type of modernization do you want?   
   >   
   > I can a few things:   
   > 1) A decent C API (direct RMS calls sucks as API)   
   > 2) Get rid of 32K limit - but that will likely require a new file system   
   > 3) Add transaction support begin/commit/rollback to API   
      
   Note that BDB actually solve all 3 problems.   
      
   (but does not support the nice Pascal/Basic/Cobol interfaces)   
      
   https://www.vajhoej.dk/arne/articles/vmstd5.html   
      
   People may want to grab version 4 (Sleepycat license) instead   
   of recent version (AGPL).   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)