https://vmssoftware.com/about/roadmap/

now has the following listed for H2:

* VMS 9.2-2 with support for
- cloud
- Oracle Linux KVM
- VMWare VMotion
- FC passthrough on VMWare
* native Bliss
* native Cobol
* native Basic
* Java 8 [pretty old by now, but if they get it running then Java 17
will hopefully follow soon]
* Python
* ActiveMQ
* SQLRelay client
* Tomcat 8.5 [also pretty old]
* the CDD replacement

I will cross my fingers and hope.

With all that then I think the main missing piece must be Rdb.

Arne

On 8/16/2023 4:21 PM, Arne Vajhøj wrote:
> https://vmssoftware.com/about/roadmap/
>
> now has the following listed for H2:
>
> * VMS 9.2-2 with support for
> - cloud
> - Oracle Linux KVM
> - VMWare VMotion
> - FC passthrough on VMWare
> * native Bliss
> * native Cobol

> * native Basic

Many atta-boys for this.

:-)

> * Java 8 [pretty old by now, but if they get it running then Java 17 will
> hopefully follow soon]
> * Python
> * ActiveMQ
> * SQLRelay client
> * Tomcat 8.5 [also pretty old]
> * the CDD replacement
>
> I will cross my fingers and hope.
>
> With all that then I think the main missing piece must be Rdb.

Not sure how that should be considered, since Rdb is not in VSI's hands.

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

On 8/16/2023 8:23 PM, Dave Froble wrote:
> On 8/16/2023 4:21 PM, Arne Vajhøj wrote:
>> https://vmssoftware.com/about/roadmap/
>>
>> now has the following listed for H2:
>>
>> * VMS 9.2-2 with support for
>>     - cloud
>>     - Oracle Linux KVM
>>     - VMWare VMotion
>>     - FC passthrough on VMWare
>> * native Bliss
>> * native Cobol
>
>> * native Basic
>
> Many atta-boys for this.
>
> :-)

It is definitely needed.

>> * Java 8 [pretty old by now, but if they get it running then Java 17 will
>> hopefully follow soon]
>> * Python
>> * ActiveMQ
>> * SQLRelay client
>> * Tomcat 8.5 [also pretty old]
>> * the CDD replacement
>>
>> I will cross my fingers and hope.
>>
>> With all that then I think the main missing piece must be Rdb.
>
> Not sure how that should be considered, since Rdb is not in VSI's hands.

There will be a lot of customers waiting for it - not being able to
start their migration until it at least is ready for test.

They do not wait less because it is Oracle and not VSI.

Obviously if they want to push for it they should push Oracle not VSI.

Arne

On 8/16/2023 9:41 PM, Arne Vajhøj wrote:
> On 8/16/2023 8:23 PM, Dave Froble wrote:
>> On 8/16/2023 4:21 PM, Arne Vajhøj wrote:
>>> https://vmssoftware.com/about/roadmap/
>>>
>>> now has the following listed for H2:
>>>
>>> * VMS 9.2-2 with support for
>>>     - cloud
>>>     - Oracle Linux KVM
>>>     - VMWare VMotion
>>>     - FC passthrough on VMWare
>>> * native Bliss
>>> * native Cobol
>>
>>> * native Basic
>>
>> Many atta-boys for this.
>>
>> :-)
>
> It is definitely needed.
>
>>> * Java 8 [pretty old by now, but if they get it running then Java 17
>>> will
>>> hopefully follow soon]
>>> * Python
>>> * ActiveMQ
>>> * SQLRelay client
>>> * Tomcat 8.5 [also pretty old]
>>> * the CDD replacement
>>>
>>> I will cross my fingers and hope.
>>>
>>> With all that then I think the main missing piece must be Rdb.
>>
>> Not sure how that should be considered, since Rdb is not in VSI's hands.
>
> There will be a lot of customers waiting for it - not being able to
> start their migration until it at least is ready for test.
>
> They do not wait less because it is Oracle and not VSI.
>
> Obviously if they want to push for it they should push Oracle not VSI.
>

Just out of curiosity, what do you do if Oracle says "No"?

bill

On 8/16/2023 10:33 PM, bill wrote:
> On 8/16/2023 9:41 PM, Arne Vajhøj wrote:
>> On 8/16/2023 8:23 PM, Dave Froble wrote:
>>> On 8/16/2023 4:21 PM, Arne Vajhøj wrote:
>>>> https://vmssoftware.com/about/roadmap/
>>>>
>>>> now has the following listed for H2:
>>>>
>>>> * VMS 9.2-2 with support for
>>>> - cloud
>>>> - Oracle Linux KVM
>>>> - VMWare VMotion
>>>> - FC passthrough on VMWare
>>>> * native Bliss
>>>> * native Cobol
>>>
>>>> * native Basic
>>>
>>> Many atta-boys for this.
>>>
>>> :-)
>>
>> It is definitely needed.
>>
>>>> * Java 8 [pretty old by now, but if they get it running then Java 17 will
>>>> hopefully follow soon]
>>>> * Python
>>>> * ActiveMQ
>>>> * SQLRelay client
>>>> * Tomcat 8.5 [also pretty old]
>>>> * the CDD replacement
>>>>
>>>> I will cross my fingers and hope.
>>>>
>>>> With all that then I think the main missing piece must be Rdb.
>>>
>>> Not sure how that should be considered, since Rdb is not in VSI's hands.
>>
>> There will be a lot of customers waiting for it - not being able to
>> start their migration until it at least is ready for test.
>>
>> They do not wait less because it is Oracle and not VSI.
>>
>> Obviously if they want to push for it they should push Oracle not VSI.
>>
>
> Just out of curiosity, what do you do if Oracle says "No"?
>
> bill

Hypothetical question, but, Ok ...

Short term, firm up numeric range locking, then whatever it takes for Postgre.

I've got to guess that without Rdb on x86, it would become less profitable for
Oracle. Perhaps they might sell/give it to VSI. Perhaps they would not want
the competition and hang on to it, just as their goal was to acquire it in the
first place.

Not very into the database world, so don't have a clue as to what customers
really want.

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

On 8/16/2023 10:33 PM, bill wrote:
> On 8/16/2023 9:41 PM, Arne Vajhøj wrote:
>> On 8/16/2023 8:23 PM, Dave Froble wrote:
>>> On 8/16/2023 4:21 PM, Arne Vajhøj wrote:
>>>> With all that then I think the main missing piece must be Rdb.
>>>
>>> Not sure how that should be considered, since Rdb is not in VSI's hands.
>>
>> There will be a lot of customers waiting for it - not being able to
>> start their migration until it at least is ready for test.
>>
>> They do not wait less because it is Oracle and not VSI.
>>
>> Obviously if they want to push for it they should push Oracle not VSI.
>
> Just out of curiosity, what do you do if Oracle says "No"?

If no Rdb on VMS x86-64, then Rdb on VMS I64/Alpha users will have
to look at options:
* migrate to another database on VMS x86-64
* migrate to another database on another platform

But so far the message from Oracle is that Rdb for VMS x86-64
will show up in 24Q1.

Source:
https://vmssoftware.com/docs/2022_accomplishments_webinar_20230110.pdf

So NO is currently speculation about Oracle changing
their mind.

It could happen. But so far no reason to expect so.

Arne

On 2023-08-16, Dave Froble <davef@tsoft-inc.com> wrote:
> On 8/16/2023 4:21 PM, Arne Vajhøj wrote:
>>
>> With all that then I think the main missing piece must be Rdb.
>
> Not sure how that should be considered, since Rdb is not in VSI's hands.
>

People don't buy systems unless they have _all_ the products they need
to run their applications on those systems.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Arne Vajhøj explained :

> * the CDD replacement

Any details about this ?
Many thanks in advance,

--
Marc Van Dyck

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

On 8/17/2023 7:10 PM, 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's a VSI-written replacement for CDD; it does
not use Rdb.

I've not used it yet.

--

--- Rob

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.

On 8/18/2023 10:12 AM, dthi...@gmail.com wrote:
> 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.

We don't speak for Oracle, but I do know that they have never stated that
CDD won't be ported to X86.

-- Rob

In article <77fe801a-48fc-4c08-880c-01642ae50349n@googlegroups.com>,
dthi...@gmail.com <dthittner@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.
>
>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.

I don't know that that follows. I can easily understand why a
company might want to reduce dependence on something controlled
by another company.

- Dan C.

On 8/18/2023 10:12 AM, dthi...@gmail.com wrote:
> On Thursday, August 17, 2023 at 7:10:15 PM UTC-4, Arne Vajhøj wrote:
>> 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.
>
> 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.

Sector 7 have a VX/CDD product for Linux.

But yes it is a portability problem.

I am also skeptical about how well it fits into a modern data strategy.

The dream of:
* have all data at a central server
* have all data definitions at a central server
* have all applications access the central data using the central data
definitions
may have seemed right in the 1980's.

But big companies today:
- has data on dozens/hundreds/thousands of servers
- data are a mix of structured and un-structured
- data is accessed using one or two handfulls of languages/frameworks on
multiple platforms from hundreds/thousands/tens-of-thousands of servers

CDD does not make much sense as a corporate strategy in such an environment.

But it is obviously needed for those VMS applications that use it and
are being migrated from Alpha/Itanium to x86-64.

Arne

On 8/18/2023 10:12 AM, dthi...@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.

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

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

On Wednesday, August 16, 2023 at 10:33:50 PM UTC-4, bill wrote:
> On 8/16/2023 9:41 PM, Arne Vajhøj wrote:
> > On 8/16/2023 8:23 PM, Dave Froble wrote:
> >> On 8/16/2023 4:21 PM, Arne Vajhøj wrote:
> >>> https://vmssoftware.com/about/roadmap/
> >>>
> >>> now has the following listed for H2:
> >>>
> >>> * VMS 9.2-2 with support for
> >>> - cloud
> >>> - Oracle Linux KVM
> >>> - VMWare VMotion
> >>> - FC passthrough on VMWare
> >>> * native Bliss
> >>> * native Cobol
> >>
> >>> * native Basic
> >>
> >> Many atta-boys for this.
> >>
> >> :-)
> >
> > It is definitely needed.
> >
> >>> * Java 8 [pretty old by now, but if they get it running then Java 17
> >>> will
> >>> hopefully follow soon]
> >>> * Python
> >>> * ActiveMQ
> >>> * SQLRelay client
> >>> * Tomcat 8.5 [also pretty old]
> >>> * the CDD replacement
> >>>
> >>> I will cross my fingers and hope.
> >>>
> >>> With all that then I think the main missing piece must be Rdb.
> >>
> >> Not sure how that should be considered, since Rdb is not in VSI's hands.
> >
> > There will be a lot of customers waiting for it - not being able to
> > start their migration until it at least is ready for test.
> >
> > They do not wait less because it is Oracle and not VSI.
> >
> > Obviously if they want to push for it they should push Oracle not VSI.
> >
> Just out of curiosity, what do you do if Oracle says "No"?
>
> bill

THEN YOU MAKE SURE SYNERGY PORTS THEIR DIBOL LANGUAGE ALONG WITH SQL CONNECT WHICH CONNECTS TO ORACLE

https://www.synergex.com/products-connectivity-open-source/

On 8/18/2023 12:45 PM, ultr...@gmail.com wrote:
> On Wednesday, August 16, 2023 at 10:33:50 PM UTC-4, bill wrote:
>> On 8/16/2023 9:41 PM, Arne Vajhøj wrote:
>>> On 8/16/2023 8:23 PM, Dave Froble wrote:
>>>> On 8/16/2023 4:21 PM, Arne Vajhøj wrote:
>>>>> With all that then I think the main missing piece must be Rdb.
>>>>
>>>> Not sure how that should be considered, since Rdb is not in VSI's hands.
>>>
>>> There will be a lot of customers waiting for it - not being able to
>>> start their migration until it at least is ready for test.
>>>
>>> They do not wait less because it is Oracle and not VSI.
>>>
>>> Obviously if they want to push for it they should push Oracle not VSI.
>>>
>> Just out of curiosity, what do you do if Oracle says "No"?
>
> THEN YOU MAKE SURE SYNERGY PORTS THEIR DIBOL LANGUAGE ALONG WITH SQL CONNECT WHICH CONNECTS TO ORACLE

I certainly hope that Synergy port their DIBOL (DBL) to VMS x86-64.

But it is not really related to the question at hand.

If no Rdb then current Rdb users will have a problem.

But it is not a connectivity problem.

There are already ways to connect from almost any VMS
language to almost any database.

Arne

On 8/18/2023 12:52 PM, Arne Vajhøj wrote:
> On 8/18/2023 12:45 PM, ultr...@gmail.com wrote:
>> On Wednesday, August 16, 2023 at 10:33:50 PM UTC-4, bill wrote:
>>> On 8/16/2023 9:41 PM, Arne Vajhøj wrote:
>>>> On 8/16/2023 8:23 PM, Dave Froble wrote:
>>>>> On 8/16/2023 4:21 PM, Arne Vajhøj wrote:
>>>>>> With all that then I think the main missing piece must be Rdb.
>>>>>
>>>>> Not sure how that should be considered, since Rdb is not in VSI's
>>>>> hands.
>>>>
>>>> There will be a lot of customers waiting for it - not being able to
>>>> start their migration until it at least is ready for test.
>>>>
>>>> They do not wait less because it is Oracle and not VSI.
>>>>
>>>> Obviously if they want to push for it they should push Oracle not VSI.
>>>>
>>> Just out of curiosity, what do you do if Oracle says "No"?
>>
>> THEN YOU MAKE SURE SYNERGY PORTS THEIR DIBOL LANGUAGE ALONG WITH SQL
>> CONNECT WHICH CONNECTS TO ORACLE
>
> I certainly hope that Synergy port their DIBOL (DBL) to VMS x86-64.
>
> But it is not really related to the question at hand.
>
> If no Rdb then current Rdb users will have a problem.
>
> But it is not a connectivity problem.
>
> There are already ways to connect from almost any VMS
> language to almost any database.

But before this speculative thread spins out of control.

https://vmssoftware.com/docs/2022_accomplishments_webinar_20230110.pdf

says:

<quote>
Any word from Oracle on RDB for x86? I have checked their website, and
so far,
nothing is mentioned in their compatibility matrix (just Alpha and Itanium).

Oracle communicated at the German HP Connect forum in September in
Böblingen, Germany, that the plan is to have RDB for x86 ready in Q1 2024.
</quote>

Until we hear otherwise that is what we should expect.

Arne

Den 2023-08-18 kl. 18:42, skrev Dave Froble:
> On 8/18/2023 10:12 AM, dthi...@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 ...
>

On 8/18/2023 12:45 PM, ultr...@gmail.com wrote:

> THEN YOU MAKE SURE SYNERGY PORTS THEIR DIBOL LANGUAGE ALONG WITH SQL CONNECT WHICH CONNECTS TO ORACLE

Bob still using that ASR33 ??

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

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...@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@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

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

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

On 8/18/2023 4:39 PM, Dave Froble wrote:
> On 8/18/2023 1:58 PM, Jan-Erik Söderholm wrote:
>> 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.

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

SELECT * From CustomerTable Where Country = '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.

Internally is a rather similar.

ORG=IDX:

key field => efficient lookup via index
not key field => full scan

RDBMS:

indexed field => efficient lookup via index
not indexed field => full scan

But seen from the application side the RDBMS is a lot easier:
* index can be added later if a performance problem is identified
* most databases allow for many indexes (MySQL allows up to 64 per table)
* the full scan is done within the database transparently to the
application
- less application code
- no application code changes when switching from not indexed to indexed

Arne

On 8/18/2023 5:08 PM, Jan-Erik Söderholm wrote:
> Den 2023-08-18 kl. 22:39, skrev Dave Froble:
>> 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.

For a tree based index lookup should be O(logn) and only O(1) for
hash based indexes.

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

There were other SQL problems ....

Arne