[Info-vax] wrong file format

Arne Vajhøj arne at vajhoej.dk
Thu Jan 7 11:56:13 EST 2021


On 1/7/2021 11:41 AM, Stephen Hoffman wrote:
> On 2021-01-07 15:54:02 +0000, Arne Vajhj said:
>> On 1/6/2021 10:39 PM, Dave Froble wrote:
>>> On 1/6/2021 7:02 PM, 1tim.... at gmail.com wrote:
>>>> A set of records is what most businesses are dealing with, like item 
>>>> lookups based on attributes, getting order history, processing lines 
>>>> on an order, etc.
>>>>
>>>> then as a next go round, maybe simple joins on keys...but that 
>>>> begins to increase complexity, where maybe a native RDB or OODB 
>>>> starts making sense.
>>>
>>> What you're suggesting is pretty much what decent RDBMS products 
>>> provide, along with many other advantages.
>>>
>>> Rdb should have been made a part of the normal VMS distribution.  It 
>>> would have made VMS much more desirable, and locked more people into 
>>> it's advantages.
>>
>> Interesting idea.
> 
> That inclusion sorta-kinda happened; the Rdb run-time was (briefly) 
> integrated with the OpenVMS licensing.

But that just meant that programs compiled and linked with Rdb elsewhere
could run on VMS right?

>                                          With the sale to Oracle, that 
> ended—somewhere around 1995.

> But the availability of Rdb for integration into OpenVMS is—for the 
> purposes of this discussion and for the next decade, and absent Oracle 
> deciding to sell some or all of Rdb to VSI—somewhere between unlikely 
> and not happening.

True.

> I've pointed at SQLite as an alternative database before. PostgreSQL 
> might become another option, if the SSIO-related corruptions can be 
> resolved.

Given that SQLite is available on VMS today, then that makes it
more relevant.

And if someone need a server, then such are also available
including MySQL/MariaDB (even though the version is slightly behind).

>>> In my own personal opinion, and I'm biased, the greatest flaw of RMS 
>>> was not including record and field definitions associated with ISAM 
>>> and Relative files.
>>
>> If I remember correctly, then the "vision" back then was to store such 
>> info in CDD as part of VAX Information Architecture.
> 
> Correct; CDD/Repository was to hold that data.
> 
> DATATRIEVE still supports CDD/Repository as do various other tools, and 
> DATATRIEVE added text-based record storage data.

I remember very little about CDD. Mostly that I did not like it.  :-)

Arne




More information about the Info-vax mailing list