[Info-vax] wrong file format

[Arne Vajhøj]

On 1/7/2021 10:26 PM, Dave Froble wrote:
> On 1/7/2021 7:42 PM, Arne Vajhøj wrote:
>> On 1/7/2021 3:35 PM, 1tim.... at gmail.com wrote:
>>> On Thursday, January 7, 2021 at 11:24:06 AM UTC-7, Stephen Hoffman
>>> wrote:
>>>> On 2021-01-07 17:44:40 +0000, 1tim.... at gmail.com said:
>>>>> So do I, a product with a data dictionary and routines that use
>>>>> it to get at data. Short of making a relational or object
>>>>> oriented Database part of the OS, some extensions to RMS would go
>>>>> a long ways to being useful and shouldn't be that hard to
>>>>> implement. Once you start wandering into relational operators and
>>>>> joins, stuff get more complex and at that point you really should
>>>>> have a database...
>>>> Given there's a widely-used, portable, and robust SQL database
>>>> already ported to OpenVMS, and the port was integrated with the
>>>> lock manager, and it's free... ...Tweaks around the edges of RMS
>>>> which would require app code changes, and replacing or acquiring
>>>> CDD/Repository—for a fraction of what SQL provides—don't seem
>>>> optimal.
>>
>>> Don't disagree with what you are saying, but going to a database is a
>>> "rip and replace" option, vs incorporating some convenient features
>>> into legacy code.
>>
>>> If I'm supporting a large application with a large codebase, I'm not
>>> interested in ripping out the guts and making it use a relational
>>> database. I am, however, interested in making incremental
>>> improvements and simplifying code where possible.
>>
>> If the code was very well structured then the changes of switching
>> to a RDBMS would be isolated to some persistence code (Data Access Layer
>> if one likes that term).
> 
> Not a chance.  Even the logic of how to access and update the data can 
> be very different.  Many times the entire logic of tasks will need to be 
> re-visited, not just the data access.

No layer above the DAL should know anything about how it is persisted,
so changes to how data is persisted will be limited to there.

But it requires a high level of abstraction.

>> Unfortunatetly we don't always live in a perfect world.
> 
> Perhaps the most un-perfect is the attempts to make things sound easier 
> than they actually are.

Stuff like what I describe is pretty standard in newer applications.

>>> The ROI isn't there for most companies to replace the existing file
>>> system. The ROI is there to fold in incremental improvements in the
>>> course of doing enhancements and new development. The ability to do
>>> sets of data easily makes importing and exporting data to outside
>>> systems easier, or exposing data via web services easier. It's a lot
>>> easier to create a service that grabs a bunch of records in a single
>>> call than to have to loop and accumulate the data for the call. I
>>> suspect many of us have had to implement something like this. (Yes,
>>> solutions like Connex exist)
>>
>> Some things are hard to do incremental. Switching from RMS
>> index-sequential files to relational database may be one
>> of them - at least I don't see 100% idx -> 75% idx + 25% rdbms ->
>> 50% idx + 50% rdbms -> 25% idx + 75% rdbms -> 100% rdbms as
>> am easy road. Unless we are talking totally isolated applications.
> 
> When the entire logic of a task is to read (and perhaps lock) one or 
> more records, use the data in the record(s) to make some decisions, and 
> then update one or more of the records, using a RDBMS usually doesn't 
> fit that logic.

I would say that it fits very nicely with RDBMS.

You just need support for transactions and support for
transaction isolation level repeatable read or serializable.

Most RDBMS have that.

Arne