[Info-vax] VSI roadmap

[Jan-Erik Söderholm]

Den 2023-08-18 kl. 22:39, skrev Dave Froble:
> On 8/18/2023 1:58 PM, Jan-Erik Söderholm wrote:
>> Den 2023-08-18 kl. 18:42, skrev Dave Froble:
>>> On 8/18/2023 10:12 AM, dthi... at gmail.com wrote:
>>>> On Thursday, August 17, 2023 at 7:10:15 PM UTC-4, Arne Vajhøj wrote:
>>>>> On 8/17/2023 11:21 AM, Marc Van Dyck wrote:
>>>>>> Arne Vajhøj explained :
>>>>>>> * the CDD replacement
>>>>>>
>>>>>> Any details about this ?
>>>>> The roadmap just says:
>>>>>
>>>>> <quote>
>>>>> * VDD (replacement for CDD)
>>>>> </quote>
>>>>>
>>>>> I don't know anything about VDD.
>>>>>
>>>>> Maybe some VSI people can enlighten us.
>>>>>
>>>>> It could be important for sites still using CDD today.
>>>>>
>>>>> I have not used CDD since late 80's/early 90's and
>>>>> I hated it.
>>>>>
>>>>> Arne
>>>>
>>>> While CDD made multi-language synchronization of record layouts easier ON
>>>> VMS, it made it difficult when you wanted to move/port code to other
>>>> platforms, which did not have language compiler constructs for 
>>>> accessing CDD.
>>>> We moved part of our application suite to Linux to take advantage of 
>>>> some OS
>>>> features, and needed to extract the record layouts into include files 
>>>> for the
>>>> Linux compilers. From that point on, we found it easier to instruct our
>>>> programmers to keep extracted include file directories in synch rather 
>>>> than
>>>> maintain the VMS-only CDD layouts in combination with the include layouts.
>>>>
>>>> I certainly understand that from VSI's compatibility perspective that they
>>>> would want it to prevent a lot of customer code rework by having a CDD
>>>> construct available on x86_64. If VSI is internally creating a new version
>>>> (VDD) it makes me think that Oracle has already said that they aren't
>>>> planning to port CDD to x86_64.
>>>>
>>>
>>> Ok, water over the dam, under the bridge, and out to sea.
>>>
>>> The real problem is that a really bad design was adopted by DEC to make 
>>> record
>>> definitions part of the program (code) rather than part of the 
>>> database.  When
>>> the record definitions are part of the database, it really doesn't 
>>> matter what
>>> language or OS is in use, as long as the database capabilities include
>>> extraction of the record definitions and access to the data.
>>>
>>> So, either there is a central repository of record definitions, such as 
>>> CDD,
>>> or a single copy of include files, or, each program might have it's own
>>> definitions.
>>
>> We create the (Rdb) database tables as we need them.
>> Then extract include files (done with the built-in DBA tool RMU).
>> The record definitions are loaded into a text library (TLB).
>> Finally COPY'ed from the TLB into the Cobol source files.
>>
>> The RMU tool support extracting records in these languages:
>> SQL, ANSI_SQL, RDO, C, Cobol and Pascal.
>>
>> This replaced the use of CDD that was a hazle to maintain
>> just for the record definitions.
>>
>> A live example of extracting a Cobol record definition:
>>
>> $ rmu /extract -
>>       /item=table -
>>       /language=cobol -
>>       /opt=(match="MK078T", nohead) -
>>       mk000db
>>
>> ** Table: MK078T
>>
>> 01 MK078T.
>>     05 MK078T_ARTIKELNR                picture X(10).
>>     05 MK078T_SERIENR                  picture S9(18) comp.
>>     05 MK078T_PROCESS                  picture X(10).
>>     05 MK078T_STATUS                   picture X(1).
>>     05 MK078T_STORED_TIME              SQL_TIMESTAMP.
>>     05 MK078T_ID                       picture S9(18) comp.
>>
>> $
>>
>> Only change in the Cobol sources was to replace the "include from
>> dictionary" with a "include module".
>>
>> * EXEC SQL
>> *   INCLUDE FROM DICTIONARY 'ME_DIC:MK.MKRDB.RDB$RELATIONS.MK078T'
>> * END_EXEC.
>>
>> EXEC SQL
>>   INCLUDE MODULE MK078T_SCO FROM LIBRARY 'MAHVLIB'
>> END_EXEC.
>>
>> So, from an application point of view, it is still a single
>> place for record definitions, just in a other way.
>>
>>
>>>
>>> With CDD, at least there is a single place for record definitions, and many
>>> are stuck with the basic design.  So it is good that VSI is providing 
>>> such a
>>> utility.
>>>
>>> Opinion, the whole design still sucks ...
>>>
>>
> 
> Ok, understand what you are doing.
> 
> Caviet, I've never used Rdb.
> 
> Another, I've only used SQL2000 from Microsoft.
> 
> Regardless, consider the following:
> 
> SELECT * From CustomerTable Where Country is "USA"
> 
> And where country is not a key.
> 
> In RMS this cannot be done, without scanning all records, and use some type 
> of mapping of the record definition, CDD, include file, in program 
> definition. However, if the database contains the record definitions, then 
> the database would return a recordset of the records with Country equal to 
> USA.
> 
> Yes, all records would be scanned internally, but database products do this 
> rather quickly and efficiently, and transparent to the request.  Would work 
> on any system that supports the database.
> 
> Just not anywhere as nice with RMS and "external to the database" record 
> definitions.
> 
> 


Another thing from the past...

There was once a package from DEC called "Database Integrator", or DBI.
One part of that kit was "Rdb Transparent Gateway for RMS".

With that, you created record descriptions for your RMS files,
either in CDD or as plain text files.

Then you connected to the RMS gateway from the SQL prompt (or an
application) and run your usual SELECT/INSERT/UPDATE statements.
To the user (or the application) it just looked as an Rdb table.

You could even use one real Rdb table and one RMS file in the same
SELECT and join them just as with two Rdb tables.

We still have the part called "Rdb Transparent Gateway for Oracle"
in production use (Alpha). That let us get access to an Oracle DB
running on an IBM AIX system using the same Rdb development toolset.
In use to read warehouse balances to our VMS applications.

A very nice kit, sadly dropped by Oracle, they thought that such
"database integrations" should be done from the other end.