[Info-vax] VSI roadmap

[Jan-Erik Söderholm]

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