[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