On 18/08/2023 21:39, Dave Froble wrote:
> Caviet, I've never used Rdb.
>
> Another, I've only used SQL2000 from Microsoft.
>

Blimey! I have used Ingres, RDB and Oracle from VMS, plus Sysbase, DB2,
MySQL, Sqlite, various SQL Server, as well as a few others

It was Oracle that kept me going when I lost my VMS base, especially
PL/SQL, which of course got me interested in Ada

--
Chris

On 18/08/2023 23:47, Arne Vajhøj wrote:
> 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
>
>

I got quite good at optimising Oracle queries - easy under 10, 11, but
carp for 8. Ingres in its day wasn't bad - in the days of Ingres 6 it
was said to have the best optimiser.

We ran it on VMS as well!

--
Chris

On 8/18/2023 6:45 PM, Arne Vajhøj wrote:
> 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'

Come on Arne, give me a bit of a break. (Not vertibre) It's been over 20 years
since I used SQL. I think I got the idea across.

:-)

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

Doesn't matter for this discussion.

> 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

This is my point. When the record definitions (columns) are known to the
database, it can then use them for operations. Not so in the design of RMS. At
least without such as CDD and custom programs. Implementing custom utilities
that will work on any file/table is then possible.

--
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 7:29 PM, Chris Townley wrote:
> On 18/08/2023 21:39, Dave Froble wrote:
>> Caviet, I've never used Rdb.
>>
>> Another, I've only used SQL2000 from Microsoft.
>>
>
> Blimey! I have used Ingres, RDB and Oracle from VMS, plus Sysbase, DB2,
> MySQL, Sqlite, various SQL Server, as well as a few others
>
> It was Oracle that kept me going when I lost my VMS base, especially
> PL/SQL, which of course got me interested in Ada
>

And let's not forget Informix, Profile, RIM and, of course, DMS-11. :-)

bill

On 2023-08-18 22:39, Dave Froble wrote:
[...]

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

Maybe I missed something. I didn't see RMS in there anywhere.
So why are you bringing that up?

Rdb is not the same thing as RMS.

Johnny

On 8/20/2023 11:01 AM, Johnny Billquist wrote:
> On 2023-08-18 22:39, Dave Froble wrote:
> [...]
>
>> 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.
>
> Maybe I missed something. I didn't see RMS in there anywhere.
> So why are you bringing that up?
>
> Rdb is not the same thing as RMS.
>
> Johnny
>

The topic was the VSI replacement for CDD. CDD was/is used to provide record
definitions for RMS and anything else that needed such. My opinion is that the
lack of record definitions in any data store is poor design.

--
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 2023-08-20 18:00, Dave Froble wrote:
> On 8/20/2023 11:01 AM, Johnny Billquist wrote:
>> On 2023-08-18 22:39, Dave Froble wrote:
>> [...]
>>
>>> 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.
>>
>> Maybe I missed something. I didn't see RMS in there anywhere.
>> So why are you bringing that up?
>>
>> Rdb is not the same thing as RMS.
>>
>>   Johnny
>>
>
> The topic was the VSI replacement for CDD.  CDD was/is used to provide
> record definitions for RMS and anything else that needed such.  My
> opinion is that the lack of record definitions in any data store is poor
> design.

Well, in this case it was Rdb, wasn't it? But sure, you need record
definitions for anything/everything. And it's nice if that comes from
the same source. Which is what I think is what Jan-Erik was
describing/doing.

Data stored in Rdb, record definitions extracted with RMU to whatever
language used, then eventually included in the compilation.

Now, where did RMS come into this, and it would certainly seem that the
record definitions are available along with the data store.

How this is related to CDD is another question. But that apparently came
from the fact that Rdb is owned by Oracle, and so is CDD. And VSI have a
replacement for CDD, but Oracle also seem to be going to port Rdb to
x86-64. Unclear if they also care about CDD. But since VSI have a
replacement, that seems non-critical. Is CDD/VDD tied in with that RMU tool?

Johnny

Den 2023-08-20 kl. 19:30, skrev Johnny Billquist:
> On 2023-08-20 18:00, Dave Froble wrote:
>> On 8/20/2023 11:01 AM, Johnny Billquist wrote:
>>> On 2023-08-18 22:39, Dave Froble wrote:
>>> [...]
>>>
>>>> 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.
>>>
>>> Maybe I missed something. I didn't see RMS in there anywhere.
>>> So why are you bringing that up?
>>>
>>> Rdb is not the same thing as RMS.
>>>
>>>   Johnny
>>>
>>
>> The topic was the VSI replacement for CDD.  CDD was/is used to provide
>> record definitions for RMS and anything else that needed such.  My
>> opinion is that the lack of record definitions in any data store is poor
>> design.
>
> Well, in this case it was Rdb, wasn't it? But sure, you need record
> definitions for anything/everything. And it's nice if that comes from the
> same source. Which is what I think is what Jan-Erik was describing/doing.

Well, I was just describing how to get record defs for your Rdb tables
in a format that can be used directly by your programming language.

>
> Data stored in Rdb, record definitions extracted with RMU to whatever
> language used, then eventually included in the compilation.
>
> Now, where did RMS come into this, and it would certainly seem that the
> record definitions are available along with the data store.
>
> How this is related to CDD is another question. But that apparently came
> from the fact that Rdb is owned by Oracle, and so is CDD. And VSI have a
> replacement for CDD, but Oracle also seem to be going to port Rdb to
> x86-64. Unclear if they also care about CDD. But since VSI have a
> replacement, that seems non-critical. Is CDD/VDD tied in with that RMU tool?
>
>   Johnny
>

Not sure I follow... Why should CDD be "tied in" with RMU?
The "Rdb Management Utility".

If you have CDD, the compilers read records defs directly from CDD
and RMU has nothing to do with that.

If you do not have CDD, RMU can create record defs for you to be
later included by the compiler.

On 2023-08-20 19:44, Jan-Erik Söderholm wrote:
> Den 2023-08-20 kl. 19:30, skrev Johnny Billquist:
>> On 2023-08-20 18:00, Dave Froble wrote:
>>> On 8/20/2023 11:01 AM, Johnny Billquist wrote:
>>>> On 2023-08-18 22:39, Dave Froble wrote:
>>>> [...]
>>>>
>>>>> 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.
>>>>
>>>> Maybe I missed something. I didn't see RMS in there anywhere.
>>>> So why are you bringing that up?
>>>>
>>>> Rdb is not the same thing as RMS.
>>>>
>>>>   Johnny
>>>>
>>>
>>> The topic was the VSI replacement for CDD.  CDD was/is used to
>>> provide record definitions for RMS and anything else that needed
>>> such.  My opinion is that the lack of record definitions in any data
>>> store is poor design.
>>
>> Well, in this case it was Rdb, wasn't it? But sure, you need record
>> definitions for anything/everything. And it's nice if that comes from
>> the same source. Which is what I think is what Jan-Erik was
>> describing/doing.
>
> Well, I was just describing how to get record defs for your Rdb tables
> in a format that can be used directly by your programming language.

Right. Which means the record definitions are implicitly accessible
through the data store. Which was what David was complaining about not
being the case. I became confused because what you were explaining was
something done against Rdb, and David then complained about RMS, which I
didn't think you talked about at all. And David then talked about CDD,
which you also didn't mention either.

>> Data stored in Rdb, record definitions extracted with RMU to whatever
>> language used, then eventually included in the compilation.
>>
>> Now, where did RMS come into this, and it would certainly seem that
>> the record definitions are available along with the data store.
>>
>> How this is related to CDD is another question. But that apparently
>> came from the fact that Rdb is owned by Oracle, and so is CDD. And VSI
>> have a replacement for CDD, but Oracle also seem to be going to port
>> Rdb to x86-64. Unclear if they also care about CDD. But since VSI have
>> a replacement, that seems non-critical. Is CDD/VDD tied in with that
>> RMU tool?
>>
>>    Johnny
>>
>
> Not sure I follow... Why should CDD be "tied in" with RMU?
> The "Rdb Management Utility".

Never claimed it was. I did ask if there was a tie in. And by your
comment I think the answer is "no".

> If you have CDD, the compilers read records defs directly from CDD
> and RMU has nothing to do with that.
>
> If you do not have CDD, RMU can create record defs for you to be
> later included by the compiler.

Right.

So again - what did this have to do with RMS? You explained how you were
using Rdb, and somehow David slid into CDD and RMS from your explanation.

But maybe we can close that thread. If people want to talk about CDD,
then let's do that. :-)

Johnny

On 2023-08-18, Dave Froble <davef@tsoft-inc.com> wrote:
>
> Just not anywhere as nice with RMS and "external to the database" record
> definitions.
>

RMS was clearly designed by people who thought punched cards were cool...

Simon.

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

On 2023-08-18, ultr...@gmail.com <ultradwc@gmail.com> wrote:
>
> 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/

Two things Bob:

1) Porting Dibol to x86-64 VMS does nothing to solve the problems
discussed here.

2) If Synergex have decided not to port to x86-64 VMS (based on your
comments) then it might mean they no longer have enough VMS users to
justify the port.

In that case, you are looking at moving your Dibol code over to another
platform such as Linux. This is a problem that (for example) Ada users
have had to deal with as there will not be an Ada compiler for x86-64 VMS.

Simon.

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

On 21/08/2023 13:23, Simon Clubley wrote:
> On 2023-08-18, ultr...@gmail.com <ultradwc@gmail.com> wrote:
>>
>> 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/
>
> Two things Bob:
>
> 1) Porting Dibol to x86-64 VMS does nothing to solve the problems
> discussed here.
>
> 2) If Synergex have decided not to port to x86-64 VMS (based on your
> comments) then it might mean they no longer have enough VMS users to
> justify the port.
>
> In that case, you are looking at moving your Dibol code over to another
> platform such as Linux. This is a problem that (for example) Ada users
> have had to deal with as there will not be an Ada compiler for x86-64 VMS.
>
> Simon.

unless of course there comes an opensource port?

--
Chris

On 2023-08-21, Chris Townley <news@cct-net.co.uk> wrote:
> On 21/08/2023 13:23, Simon Clubley wrote:
>> On 2023-08-18, ultr...@gmail.com <ultradwc@gmail.com> wrote:
>>>
>>> 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/
>>
>> Two things Bob:
>>
>> 1) Porting Dibol to x86-64 VMS does nothing to solve the problems
>> discussed here.
>>
>> 2) If Synergex have decided not to port to x86-64 VMS (based on your
>> comments) then it might mean they no longer have enough VMS users to
>> justify the port.
>>
>> In that case, you are looking at moving your Dibol code over to another
>> platform such as Linux. This is a problem that (for example) Ada users
>> have had to deal with as there will not be an Ada compiler for x86-64 VMS.
>>
>> Simon.
>
> unless of course there comes an opensource port?
>

That will not happen. That simply will not happen.

Not only has the language been massively extended since the DEC days,
the language itself is only one part of a Synergex toolkit, which
includes, among other things, a GUI/character cell forms environment
integrated into Synergex Dibol user source code that would also need
to be duplicated.

IOW, this is no longer DEC ANSI DIBOL we are talking about.

Try to imagine the effort involved with implementing DEC Basic (or similar)
on Linux and then imagine several times that amount of work. That's the
amount of effort (at an absolute minimum) we are talking about here.

And this is based on my last knowledge of the language from a decade or
so ago before I changed jobs. Goodness knows how much else has been added
since then.

Simon.

PS: BTW Bob, you may wish to consider an upgrade to a TTY Model 43.
They have a much nicer keyboard than the ASR 33 and also support lowercase.

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

On 8/21/2023 1:29 PM, Simon Clubley wrote:

> PS: BTW Bob, you may wish to consider an upgrade to a TTY Model 43.
> They have a much nicer keyboard than the ASR 33 and also support lowercase.

Careful Simon, he'll think we're ganging up on him ...

And he might be correct ...

:-)

--
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 21/08/2023 18:29, Simon Clubley wrote:
> On 2023-08-21, Chris Townley <news@cct-net.co.uk> wrote:
>> On 21/08/2023 13:23, Simon Clubley wrote:
>>> On 2023-08-18, ultr...@gmail.com <ultradwc@gmail.com> wrote:
>>>>
>>>> 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/
>>>
>>> Two things Bob:
>>>
>>> 1) Porting Dibol to x86-64 VMS does nothing to solve the problems
>>> discussed here.
>>>
>>> 2) If Synergex have decided not to port to x86-64 VMS (based on your
>>> comments) then it might mean they no longer have enough VMS users to
>>> justify the port.
>>>
>>> In that case, you are looking at moving your Dibol code over to another
>>> platform such as Linux. This is a problem that (for example) Ada users
>>> have had to deal with as there will not be an Ada compiler for x86-64 VMS.
>>>
>>> Simon.
>>
>> unless of course there comes an opensource port?
>>
>
> That will not happen. That simply will not happen.
>
> Not only has the language been massively extended since the DEC days,
> the language itself is only one part of a Synergex toolkit, which
> includes, among other things, a GUI/character cell forms environment
> integrated into Synergex Dibol user source code that would also need
> to be duplicated.
>
> IOW, this is no longer DEC ANSI DIBOL we are talking about.
>
> Try to imagine the effort involved with implementing DEC Basic (or similar)
> on Linux and then imagine several times that amount of work. That's the
> amount of effort (at an absolute minimum) we are talking about here.
>
> And this is based on my last knowledge of the language from a decade or
> so ago before I changed jobs. Goodness knows how much else has been added
> since then.
>
> Simon.
>
> PS: BTW Bob, you may wish to consider an upgrade to a TTY Model 43.
> They have a much nicer keyboard than the ASR 33 and also support lowercase.
>

Actually I was thinking of ADA

--
Chris

On 8/21/2023 1:29 PM, Simon Clubley wrote:
> On 2023-08-21, Chris Townley <news@cct-net.co.uk> wrote:
>> On 21/08/2023 13:23, Simon Clubley wrote:
>>> 2) If Synergex have decided not to port to x86-64 VMS (based on your
>>> comments) then it might mean they no longer have enough VMS users to
>>> justify the port.
>>>
>>> In that case, you are looking at moving your Dibol code over to another
>>> platform such as Linux. This is a problem that (for example) Ada users
>>> have had to deal with as there will not be an Ada compiler for x86-64 VMS.
>>
>> unless of course there comes an opensource port?
>
> That will not happen. That simply will not happen.
>
> Not only has the language been massively extended since the DEC days,
> the language itself is only one part of a Synergex toolkit, which
> includes, among other things, a GUI/character cell forms environment
> integrated into Synergex Dibol user source code that would also need
> to be duplicated.
>
> IOW, this is no longer DEC ANSI DIBOL we are talking about.
>
> Try to imagine the effort involved with implementing DEC Basic (or similar)
> on Linux and then imagine several times that amount of work. That's the
> amount of effort (at an absolute minimum) we are talking about here.
>
> And this is based on my last knowledge of the language from a decade or
> so ago before I changed jobs. Goodness knows how much else has been added
> since then.

He seems to have been talking about Ada. :-)

In theory the size of the project does not rule out an
open source implementation. Almost all the worlds
biggest development tool chains are fully or partly
open source.

The size and the fact that it is for VMS makes it
unrealistic though.

But there are a few potential alternative paths
forward for Dibol on VMS.

If VSI implemented .NET on VMS, then Dibol would become
available, because it supports .NET as platform.

If Synergex decided to support JVM as platform, then
Dibol would become available on VMS, because VSI
supports Java.

Arne

On 8/21/2023 3:45 PM, Chris Townley wrote:
> On 21/08/2023 18:29, Simon Clubley wrote:
>> On 2023-08-21, Chris Townley <news@cct-net.co.uk> wrote:
>>> On 21/08/2023 13:23, Simon Clubley wrote:
>>>> 2) If Synergex have decided not to port to x86-64 VMS (based on your
>>>> comments) then it might mean they no longer have enough VMS users to
>>>> justify the port.
>>>>
>>>> In that case, you are looking at moving your Dibol code over to another
>>>> platform such as Linux. This is a problem that (for example) Ada users
>>>> have had to deal with as there will not be an Ada compiler for
>>>> x86-64 VMS.
>>>
>>> unless of course there comes an opensource port?
>>
>> That will not happen. That simply will not happen.
>>
>> Not only has the language been massively extended since the DEC days,
>> the language itself is only one part of a Synergex toolkit, which
>> includes, among other things, a GUI/character cell forms environment
>> integrated into Synergex Dibol user source code that would also need
>> to be duplicated.
>>
>> IOW, this is no longer DEC ANSI DIBOL we are talking about.
....
>
> Actually I was thinking of ADA

Ada is a good example of the problem with VMS and
open source.

Ada exist as open source (FSF GNAT).

At some point in time it did work on VMS (I still got
a VMS Alpha kit that works).

And there was also some effort to get GNAT running on
VMS Itanium, but I don't think it ever completed.

Nothing prevents a number of VMS Ada enthusiasts to port
a recent FSF GNAT to VMS x86-64.

But will it happen?

No.

There may be 25 people that have an opinion about what
DEC should have done in the late 80's, but there are only
10 people interested in porting open source to VMS.

Arne

On 8/21/2023 3:45 PM, Chris Townley wrote:
> On 21/08/2023 18:29, Simon Clubley wrote:
>> On 2023-08-21, Chris Townley <news@cct-net.co.uk> wrote:
>>> On 21/08/2023 13:23, Simon Clubley wrote:
>>>> On 2023-08-18, ultr...@gmail.com <ultradwc@gmail.com> wrote:
>>>>>
>>>>> 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/
>>>>
>>>> Two things Bob:
>>>>
>>>> 1) Porting Dibol to x86-64 VMS does nothing to solve the problems
>>>> discussed here.
>>>>
>>>> 2) If Synergex have decided not to port to x86-64 VMS (based on your
>>>> comments) then it might mean they no longer have enough VMS users to
>>>> justify the port.
>>>>
>>>> In that case, you are looking at moving your Dibol code over to another
>>>> platform such as Linux. This is a problem that (for example) Ada users
>>>> have had to deal with as there will not be an Ada compiler for
>>>> x86-64 VMS.
>>>>
>>>> Simon.
>>>
>>> unless of course there comes an opensource port?
>>>
>>
>> That will not happen. That simply will not happen.
>>
>> Not only has the language been massively extended since the DEC days,
>> the language itself is only one part of a Synergex toolkit, which
>> includes, among other things, a GUI/character cell forms environment
>> integrated into Synergex Dibol user source code that would also need
>> to be duplicated.
>>
>> IOW, this is no longer DEC ANSI DIBOL we are talking about.
>>
>> Try to imagine the effort involved with implementing DEC Basic (or
>> similar)
>> on Linux and then imagine several times that amount of work. That's the
>> amount of effort (at an absolute minimum) we are talking about here.
>>
>> And this is based on my last knowledge of the language from a decade or
>> so ago before I changed jobs. Goodness knows how much else has been added
>> since then.
>>
>> Simon.
>>
>> PS: BTW Bob, you may wish to consider an upgrade to a TTY Model 43.
>> They have a much nicer keyboard than the ASR 33 and also support
>> lowercase.
>>
>
> Actually I was thinking of ADA
>

I would expect that most Ada users today cannot work with a non-
validated compiler. I also doubt a compiler without full support
would be usable. Neither of them come with opensource projects.

bill

On 8/21/2023 9:57 PM, bill wrote:
> On 8/21/2023 3:45 PM, Chris Townley wrote:
>> On 21/08/2023 18:29, Simon Clubley wrote:
>>> On 2023-08-21, Chris Townley <news@cct-net.co.uk> wrote:
>>>> On 21/08/2023 13:23, Simon Clubley wrote:
>>>>> In that case, you are looking at moving your Dibol code over to
>>>>> another
>>>>> platform such as Linux. This is a problem that (for example) Ada users
>>>>> have had to deal with as there will not be an Ada compiler for
>>>>> x86-64 VMS.
>>>>
>>>> unless of course there comes an opensource port?
....
>>> IOW, this is no longer DEC ANSI DIBOL we are talking about.
....
>>
>> Actually I was thinking of ADA
>
> I would expect that most Ada users today cannot work with a non-
> validated compiler.  I also doubt a compiler without full support
> would be usable.  Neither of them come with opensource projects.

Lots of open source has a commercial backing that can provide
support for those willing to pay.

Redhat Linux - IBM, MySQL - Oracle, PostgreSQL - EDB etc..

If there is a commercial backing then certification is a
possibility as well.

Like AdaCore GNAT.

Open source can be but does not not have to be a team of unpaid
volunteers.

Arne

On 2023-08-21, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> He seems to have been talking about Ada. :-)
>

Hey, in Simon's defence, the comment from Chris is still ambiguous,
even in hindsight. :-)

Bill is also probably right when he talks about a validated compiler
and don't forget that validated is not the same thing as supported.

> In theory the size of the project does not rule out an
> open source implementation. Almost all the worlds
> biggest development tool chains are fully or partly
> open source.
>
> The size and the fact that it is for VMS makes it
> unrealistic though.
>
> But there are a few potential alternative paths
> forward for Dibol on VMS.
>
> If VSI implemented .NET on VMS, then Dibol would become
> available, because it supports .NET as platform.
>
> If Synergex decided to support JVM as platform, then
> Dibol would become available on VMS, because VSI
> supports Java.
>

I don't see any of those options happening in the short or medium term
however, so Bob is probably going to have to consider other options such
as moving his Dibol codebase to Linux, unfortunately.

Simon.

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

On 8/22/2023 8:10 AM, Simon Clubley wrote:
> On 2023-08-21, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> He seems to have been talking about Ada. :-)
>>
>
> Hey, in Simon's defence, the comment from Chris is still ambiguous,
> even in hindsight. :-)
>
> Bill is also probably right when he talks about a validated compiler
> and don't forget that validated is not the same thing as supported.

I decided to verify that. Sadly, Ada compilers are no longer validated.

>
>> In theory the size of the project does not rule out an
>> open source implementation. Almost all the worlds
>> biggest development tool chains are fully or partly
>> open source.
>>
>> The size and the fact that it is for VMS makes it
>> unrealistic though.
>>
>> But there are a few potential alternative paths
>> forward for Dibol on VMS.
>>
>> If VSI implemented .NET on VMS, then Dibol would become
>> available, because it supports .NET as platform.
>>
>> If Synergex decided to support JVM as platform, then
>> Dibol would become available on VMS, because VSI
>> supports Java.
>>
>
> I don't see any of those options happening in the short or medium term
> however, so Bob is probably going to have to consider other options such
> as moving his Dibol codebase to Linux, unfortunately.

Which, I am sure, is the same that will happen with the Ada users (if it
hasn't already!)

bill

On 2023-08-21 14:10, Simon Clubley wrote:
> On 2023-08-18, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> Just not anywhere as nice with RMS and "external to the database" record
>> definitions.
>>
>
> RMS was clearly designed by people who thought punched cards were cool...

Yeah. Just like BDB. Or any other key-value datastore. Definitely smells
like puched cards...

Johnny

On 2023-08-22, bill <bill.gunshannon@gmail.com> wrote:
> On 8/22/2023 8:10 AM, Simon Clubley wrote:
>> On 2023-08-21, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>> He seems to have been talking about Ada. :-)
>>>
>>
>> Hey, in Simon's defence, the comment from Chris is still ambiguous,
>> even in hindsight. :-)
>>
>> Bill is also probably right when he talks about a validated compiler
>> and don't forget that validated is not the same thing as supported.
>
> I decided to verify that. Sadly, Ada compilers are no longer validated.
>

For the safety critical stuff, they are probably doing the certification
on the final generated code.

>
>>
>>> In theory the size of the project does not rule out an
>>> open source implementation. Almost all the worlds
>>> biggest development tool chains are fully or partly
>>> open source.
>>>
>>> The size and the fact that it is for VMS makes it
>>> unrealistic though.
>>>
>>> But there are a few potential alternative paths
>>> forward for Dibol on VMS.
>>>
>>> If VSI implemented .NET on VMS, then Dibol would become
>>> available, because it supports .NET as platform.
>>>
>>> If Synergex decided to support JVM as platform, then
>>> Dibol would become available on VMS, because VSI
>>> supports Java.
>>>
>>
>> I don't see any of those options happening in the short or medium term
>> however, so Bob is probably going to have to consider other options such
>> as moving his Dibol codebase to Linux, unfortunately.
>
> Which, I am sure, is the same that will happen with the Ada users (if it
> hasn't already!)
>

Yes, except maybe those frozen on a specific environment for certification
purposes (which probably were not going to move to x86-64 VMS anyway).

I also suspect a number of other people have reluctantly finally decided
to move away from VMS for various other reasons as well (lack of products,
duration of porting effort, etc).

Simon.

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

On 8/22/2023 8:10 AM, Simon Clubley wrote:
> On 2023-08-21, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> But there are a few potential alternative paths
>> forward for Dibol on VMS.
>>
>> If VSI implemented .NET on VMS, then Dibol would become
>> available, because it supports .NET as platform.
>>
>> If Synergex decided to support JVM as platform, then
>> Dibol would become available on VMS, because VSI
>> supports Java.
>
> I don't see any of those options happening in the short or medium term
> however,

True.

> so Bob is probably going to have to consider other options such
> as moving his Dibol codebase to Linux, unfortunately.

If Synergex will not support VMS x86-64.

So far I believe we only have Bob's whining about the
topic not an official statement from Synergex.

Arne

On 8/22/2023 10:17 AM, Johnny Billquist wrote:
> On 2023-08-21 14:10, Simon Clubley wrote:
>> On 2023-08-18, Dave Froble <davef@tsoft-inc.com> wrote:
>>> Just not anywhere as nice with RMS and "external to the database" record
>>> definitions.
>>
>> RMS was clearly designed by people who thought punched cards were cool...
>
> Yeah. Just like BDB. Or any other key-value datastore. Definitely smells
> like puched cards...

The concept is sort of timeless.

ISAM/VSAM on IBM mainframe must be about as old as me.

Lots of OS got similar features. Including VMS RMS.
*nix got DBM in 1979 and BDB in 1994.

It is a standard or at least de facto standard feature
in Cobol.

In this century the concept has become known
as NoSQL key value store and several new has
been created like:
LevelDB (Google) 2011
LMDB 2011
RocksDB (Facebook) 2012

Where the age of RMS indexed-sequential files
show is the 32 KB record size limit.

Arne