[Info-vax] VSI roadmap

[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.


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486