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

Sure, any query on any column "works" on a relational database table.

But the performance goes down the drain if there is not an index
matching the query that is running. The performance then depends on
the speed of the system and storage, how much was cached and so on.

Can be fine as long as the table is small, but there is usually
a "knee" where the cache can't hold the full table, and then the
runtime first makes a jump and then more or less grows linearly
with the size.

The performance with a matching index is only depending on the number
of matching records, not the total number of records.

The upside is that the query “work” no matter if there is an index or not.
You will not get an runtime error and you get the expected result.

Another unrelated point is that production SQL code should never
have “select-star” for queries. Any select should always specify the
columns needed for each query. It’s OK for ad-hoc interactive queries.