On 10/12/22 18:39, Dave Froble wrote:
> On 10/12/2022 1:48 PM, Simon Clubley wrote:
>> On 2022-10-12, Dave Froble <davef@tsoft-inc.com> wrote:
>>>
>>> I have to wonder if the general entitlement mentality that seems to
>>> be so
>>> widespread isn't happening with such issues as raised by the OP.
>>> Back in the
>>> day, if one needed something, one found or produced it.  When a
>>> software vendor
>>> noticed a business opportunity they sought to pursue that
>>> opportunity.  Seems
>>> now some want everything handed to them.  Seems some software vendors
>>> want
>>> customers to use what they offer, not to produce what the customer
>>> asks for.
>>>
>>
>> Nothing to do with entitlement in this case, but with the expectations
>> of customer management (amongst others).
>>
>> In a world of standard solutions, and with lots of people available to
>> operate/program those solutions, anything to do with VMS needs to be
>> as friction-free as possible (including moving to another architecture),
>> or, in the eyes of those customer managers, VMS becomes something that
>> needs to be replaced with a standard solution that the management can
>> easily find new employees for as required.
>
>
> I do not worship at the alter of "standard solutions" ...
>
> Yes, for some things, they work well.  However, for most of my work in
> IT solutions, I've been involved in projects where the demands of the
> job defined the solution(s).  All too often, that required specific
> solutions.

I agree with you completely. Unfortunately, the industry does not
agree with either of us.

bill

On 10/12/22 17:36, Arne Vajhøj wrote:
> On 10/12/2022 1:17 PM, Simon Clubley wrote:
>> On 2022-10-12, Dave Froble <davef@tsoft-inc.com> wrote:
>>> It would seem to me that the current owners of the mentioned software
>>> would be
>>> responsible for porting their software, not VSI.
>>
>> That's a very, very, short-sighted view David.
>>
>> Operating systems exist to run applications. Without those applications,
>> the operating system means nothing.
>
> True.
>
>> DEC understood this, which is why you used to have the old Software
>> handbooks.
>
> If the missing piece of the puzzle is just that then VSI could
> easily create the web based equivalent.

He is not talking about the existence of the Handbooks. He is talking
about the lack of existence of their content today.

>
>> It is very strongly in VSI's interest to help vendors port their
>> applications
>> to x86-64 VMS.
>>
>> Unfortunately, VSI's limited resources means they can't help as many
>> people as it would be beneficial to help.
>
> They can't. And they probably shouldn't. And other vendors don't.
>
>

bill

On 10/12/22 19:12, Arne Vajhøj wrote:
> On 10/12/2022 6:59 PM, Bill Gunshannon wrote:
>> On 10/12/22 17:43, Arne Vajhøj wrote:
>>> Also note that moving to the current century implies
>>> moving from embedded SQL even if a precompiler is available.
>>>
>>> Embedded SQL is a 80's & 90's technology.
>>>
>>> Not what would be chosen if starting from scratch today.
>>
>> Don't know why not.  Most of the COBOL/Oracle sites I am aware of
>> are all EXEC SQL embedded programming.
>
> How many of those code bases was *started* this century?
>

Some. But then, how many of the current VMS sites were *started* this
century? Sometimes to answer to legacy modernization is not a total
re-write in the style du jour.

bill

On 10/12/2022 8:04 PM, Bill Gunshannon wrote:
> On 10/12/22 17:40, Arne Vajhøj wrote:
>> On 10/12/2022 10:27 AM, Bill Gunshannon wrote:
>>> On 10/12/22 09:05, Simon Clubley wrote:
>>>> There's been no negative comments about Rdb recently, so I assume that
>>>> is still on course for release on x86-64 VMS. Of course, if Rdb wasn't
>>>> released for x86-64 VMS then that would be a very serious blow to VSI's
>>>> plans.
>>>
>>> A database is the least serious of these problems. VSI could easily
>>> (well, maybe not easily) decide that Postgres was going to be the VMS
>>> database just like RDB was, at one time, a DEC product. It is easily
>>> a suitable replacement for either Oracle or RDB. Just suffers from NIH
>>> syndrome.
>>
>> Databases are usually one of the most expensive pieces to
>> change.
>>
>> Unless the client applications has been written specifically to
>> not be tied a specific database, then there are client application
>> changes.
>>
>> There is the data conversion.
>>
>> There is the OPS & DBA procedures and training.
>>
>> And everything need to be tested.
>>
>
> And the alternative is to sit around and wait until someone pulls
> the rug out from under your operation. How much of this do VMS
> people need to see before they start planning ahead?

Well, there you go again ...

The sky is falling, the sky is falling ...

Perhaps using VSI's x86 VMS is planning ahead?

--
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 10/12/2022 8:30 PM, Bill Gunshannon wrote:
> On 10/12/22 19:12, Arne Vajhøj wrote:
>> On 10/12/2022 6:59 PM, Bill Gunshannon wrote:
>>> On 10/12/22 17:43, Arne Vajhøj wrote:
>>>> Also note that moving to the current century implies
>>>> moving from embedded SQL even if a precompiler is available.
>>>>
>>>> Embedded SQL is a 80's & 90's technology.
>>>>
>>>> Not what would be chosen if starting from scratch today.
>>>
>>> Don't know why not.  Most of the COBOL/Oracle sites I am aware of
>>> are all EXEC SQL embedded programming.
>>
>> How many of those code bases was *started* this century?
>
> Some.  But then, how many of the current VMS sites were *started* this
> century?

Very few.

But that doesn't really mean anything for what is used
this century.

Arne

On 10/12/2022 8:25 PM, Bill Gunshannon wrote:
> On 10/12/22 18:39, Dave Froble wrote:
>> On 10/12/2022 1:48 PM, Simon Clubley wrote:
>>> On 2022-10-12, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>
>>>> I have to wonder if the general entitlement mentality that seems to be so
>>>> widespread isn't happening with such issues as raised by the OP. Back in the
>>>> day, if one needed something, one found or produced it. When a software vendor
>>>> noticed a business opportunity they sought to pursue that opportunity. Seems
>>>> now some want everything handed to them. Seems some software vendors want
>>>> customers to use what they offer, not to produce what the customer asks for.
>>>>
>>>
>>> Nothing to do with entitlement in this case, but with the expectations
>>> of customer management (amongst others).
>>>
>>> In a world of standard solutions, and with lots of people available to
>>> operate/program those solutions, anything to do with VMS needs to be
>>> as friction-free as possible (including moving to another architecture),
>>> or, in the eyes of those customer managers, VMS becomes something that
>>> needs to be replaced with a standard solution that the management can
>>> easily find new employees for as required.
>>
>>
>> I do not worship at the alter of "standard solutions" ...
>>
>> Yes, for some things, they work well. However, for most of my work in IT
>> solutions, I've been involved in projects where the demands of the job defined
>> the solution(s). All too often, that required specific solutions.
>
> I agree with you completely. Unfortunately, the industry does not
> agree with either of us.

I guess that depends upon just what "the industry" is ...

There are places for "standard solutions". If that is the definition of "the
industry", then fine. But there still then exist "not the industry". Always
have been, always will be.

--
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 2022-10-12, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>
> What, no Ada?
>

Ada doesn't exist for x86-64 VMS and looks like it will never exist.

Simon.

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

On 10/13/22 09:00, Simon Clubley wrote:
> On 2022-10-12, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>
>> What, no Ada?
>>
>
> Ada doesn't exist for x86-64 VMS and looks like it will never exist.
>

Guess I should have used the tongue-in-cheek emoji.
I knew this. And it just shows that these third parties don't see
any responsibility on their part to support the move to x86-64 VMS.

bill

On Thu, 2022-10-13 at 13:00 +0000, Simon Clubley wrote:
> > What, no Ada?
> >
>
> Ada doesn't exist for x86-64 VMS and looks like it will never exist.

GNU can step up with their GNAT compiler. In theory it should be
possible to port it to VMS.
--
Tactical Nuclear Kittens

In article <c0b4511f58e47d887ad3557763b875b029904423.camel@munted.eu>,
alex.buell@munted.eu (Single Stage to Orbit) wrote:

> On Thu, 2022-10-13 at 13:00 +0000, Simon Clubley wrote:
> > Ada doesn't exist for x86-64 VMS and looks like it will never
> > exist.
> GNU can step up with their GNAT compiler. In theory it should be
> possible to port it to VMS.

That might be quite complicated. Previous discussions have indicated that
the VMS support has been taken out of GCC and GNU binutils.

This might well be easier, once LLVM runs natively on x86-64 VMS:

https://github.com/AdaCore/gnat-llvm

John

On 2022-10-13, Single Stage to Orbit <alex.buell@munted.eu> wrote:
> On Thu, 2022-10-13 at 13:00 +0000, Simon Clubley wrote:
>> > What, no Ada?
>> >
>>
>> Ada doesn't exist for x86-64 VMS and looks like it will never exist.
>
> GNU can step up with their GNAT compiler. In theory it should be
> possible to port it to VMS.

AdaCore used to supply the compiler for Alpha and Itanium VMS as part
of an agreement between AdaCore and DEC.

That VMS support was dropped several years ago by AdaCore.

Given the nature of the Ada market, any such port would probably need
to be done, and fully supported, by a commercial company.

Simon.

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

Den 2022-10-13 kl. 02:14, skrev Bill Gunshannon:
> On 10/12/22 19:22, Arne Vajhøj wrote:
>> On 10/12/2022 6:58 PM, Bill Gunshannon wrote:
>>> On 10/12/22 17:33, Arne Vajhøj wrote:
>>>> On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
>>>>> Using a compatibility layer and trying to make PostGres look like
>>>>> RDB (or Oracle) would be a major mistake. Better to bite the bullet
>>>>> and move into the current century.
>>>>
>>>> It is a tradeoff.
>>>>
>>>> There are benefits from doing things the standard way instead of
>>>> doing it the compatibility way.
>>>>
>>>> But there are also huge cost of changing the client applications.
>>>
>>> Maybe and maybe not as much as you think.  Granted, most of my
>>> experience doing it has been with COBOL but I have been able to
>>> take programs using databases from other systems and moved them
>>> quite easily.  I would  love to have someone send me a COBOL
>>> program that uses RDB just for a look-see.
>>
>> Cobol embedded SQL is probably one of the more portable. But it is
>> not supported by PostgreSQL project itself.
>
> No, but this is the Open Source world.  A need arose and someone
> rushed in to fill it.  And it works quite well.
>
>>
>> An extremely simple Cobol embedded SQL to Rdb example:
>>    https://www.vajhoej.dk/arne/articles/vmsdb.html#rdb_cob_emb
>
> I saw nothing in there that would not compile using ESQL and GnuCOBOL
> with PostGres.  Even the module stuff (which I am not familiar with)

Think of it as a compiler for a language called "SQL".
The default file type for these files (on VMS) is .SQLMOD

It's more or less "just" as a compiler for any other language.
And it creates a object files that are no different from any
other object file, may it come from C, Pascal or whatever.

That object file can then be linked into any other application
following the VMS calling standard. That other language does not
need to have any native support for Rdb, it just has to follow the
VMS calling standard.

It is just a function call with some parameters that returns some
defined result. The caller does not need to know that it was Rdb
that returned the result.

Den 2022-10-13 kl. 01:22, skrev Arne Vajhøj:
> On 10/12/2022 6:58 PM, Bill Gunshannon wrote:
>> On 10/12/22 17:33, Arne Vajhøj wrote:
>>> On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
>>>> Using a compatibility layer and trying to make PostGres look like
>>>> RDB (or Oracle) would be a major mistake. Better to bite the bullet
>>>> and move into the current century.
>>>
>>> It is a tradeoff.
>>>
>>> There are benefits from doing things the standard way instead of
>>> doing it the compatibility way.
>>>
>>> But there are also huge cost of changing the client applications.
>>
>> Maybe and maybe not as much as you think.  Granted, most of my
>> experience doing it has been with COBOL but I have been able to
>> take programs using databases from other systems and moved them
>> quite easily.  I would  love to have someone send me a COBOL
>> program that uses RDB just for a look-see.
>
> Cobol embedded SQL is probably one of the more portable. But it is
> not supported by PostgreSQL project itself.
>
> An extremely simple Cobol embedded SQL to Rdb example:
>   https://www.vajhoej.dk/arne/articles/vmsdb.html#rdb_cob_emb
>

We usually write applications in two layers.
To top layer is the main application with the UI and businees logic.
That is usually a plain COB file.

That in turns calls an SCO ("Cobol with embedded SQL") that has
specific functions for the database operations.

We usually has one SCO module that collects the SQL operations
for a specific group of database tables. That can then be called
from any aplication that needs to do operations on these tables.

Or, for simple cases, we just write a SCO application including
all database operations...

On 10/13/22 17:40, Jan-Erik Söderholm wrote:
> Den 2022-10-13 kl. 02:14, skrev Bill Gunshannon:
>> On 10/12/22 19:22, Arne Vajhøj wrote:
>>> On 10/12/2022 6:58 PM, Bill Gunshannon wrote:
>>>> On 10/12/22 17:33, Arne Vajhøj wrote:
>>>>> On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
>>>>>> Using a compatibility layer and trying to make PostGres look like
>>>>>> RDB (or Oracle) would be a major mistake. Better to bite the bullet
>>>>>> and move into the current century.
>>>>>
>>>>> It is a tradeoff.
>>>>>
>>>>> There are benefits from doing things the standard way instead of
>>>>> doing it the compatibility way.
>>>>>
>>>>> But there are also huge cost of changing the client applications.
>>>>
>>>> Maybe and maybe not as much as you think.  Granted, most of my
>>>> experience doing it has been with COBOL but I have been able to
>>>> take programs using databases from other systems and moved them
>>>> quite easily.  I would  love to have someone send me a COBOL
>>>> program that uses RDB just for a look-see.
>>>
>>> Cobol embedded SQL is probably one of the more portable. But it is
>>> not supported by PostgreSQL project itself.
>>
>> No, but this is the Open Source world.  A need arose and someone
>> rushed in to fill it.  And it works quite well.
>>
>>>
>>> An extremely simple Cobol embedded SQL to Rdb example:
>>>    https://www.vajhoej.dk/arne/articles/vmsdb.html#rdb_cob_emb
>>
>> I saw nothing in there that would not compile using ESQL and GnuCOBOL
>> with PostGres.  Even the module stuff (which I am not familiar with)
>
> Think of it as a compiler for a language called "SQL".
> The default file type for these files (on VMS) is .SQLMOD
>
> It's more or less "just" as a compiler for any other language.
> And it creates a object files that are no different from any
> other object file, may it come from C, Pascal or whatever.
>
> That object file can then be linked into any other application
> following the VMS calling standard. That other language does not
> need to have any native support for Rdb, it just has to follow the
> VMS calling standard.
>
> It is just a function call with some parameters that returns some
> defined result. The caller does not need to know that it was Rdb
> that returned the result.
>
>

Well, that's pretty cool. I have never seen COBOL used that way
although there really is no reason not to. Just like the libraries
linked to from the EXEC SQL parts of the code are actually C or C++
snippets. You can directly link to the PostGres Libraries but, for
obvious reasons, using the Embedded SQL method is easier on the
programmer.

bill

On 10/13/2022 9:00 AM, Simon Clubley wrote:
> On 2022-10-12, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> What, no Ada?
>
> Ada doesn't exist for x86-64 VMS and looks like it will never exist.

Well - we were talking about SQLRelay for VMS Alpha and VMS I64 - or
that was what started this subthread.

Arne

On 10/13/2022 5:40 PM, Jan-Erik Söderholm wrote:
> Den 2022-10-13 kl. 02:14, skrev Bill Gunshannon:
>> On 10/12/22 19:22, Arne Vajhøj wrote:
>>> On 10/12/2022 6:58 PM, Bill Gunshannon wrote:
>>>>  I would  love to have someone send me a COBOL
>>>> program that uses RDB just for a look-see.

>>> An extremely simple Cobol embedded SQL to Rdb example:
>>>    https://www.vajhoej.dk/arne/articles/vmsdb.html#rdb_cob_emb
>>
>> I saw nothing in there that would not compile using ESQL and GnuCOBOL
>> with PostGres.  Even the module stuff (which I am not familiar with)
>
> Think of it as a compiler for a language called "SQL".
> The default file type for these files (on VMS) is .SQLMOD
>
> It's more or less "just" as a compiler for any other language.
> And it creates a object files that are no different from any
> other object file, may it come from C, Pascal or whatever.
>
> That object file can then be linked into any other application
> following the VMS calling standard. That other language does not
> need to have any native support for Rdb, it just has to follow the
> VMS calling standard.
>
> It is just a function call with some parameters that returns some
> defined result. The caller does not need to know that it was Rdb
> that returned the result.

Embedded SQL and SQL Modules are different.

The first is pretty standard - the second is as far as I know Rdb specific.

ESQL is embedded SQL.

Arne

On 10/13/2022 6:25 PM, Bill Gunshannon wrote:
> On 10/13/22 17:40, Jan-Erik Söderholm wrote:
>> Think of it as a compiler for a language called "SQL".
>> The default file type for these files (on VMS) is .SQLMOD
>>
>> It's more or less "just" as a compiler for any other language.
>> And it creates a object files that are no different from any
>> other object file, may it come from C, Pascal or whatever.
>>
>> That object file can then be linked into any other application
>> following the VMS calling standard. That other language does not
>> need to have any native support for Rdb, it just has to follow the
>> VMS calling standard.
>>
>> It is just a function call with some parameters that returns some
>> defined result. The caller does not need to know that it was Rdb
>> that returned the result.
>
> Well, that's pretty cool.  I have never seen COBOL used that way
> although there really is no reason not to.  Just like the libraries
> linked to from the EXEC SQL parts of the code are actually C or C++
> snippets.  You can directly link to the PostGres Libraries but, for
> obvious reasons, using the Embedded SQL method is easier on the
> programmer.

Embedded SQL is pretty efficient - few lines achieve much - way
more efficient than library calls in compiled languages (probably
less efficient than library calls in scripts languages and ORM).

But the industry is moving away from embedded SQL and precompilers.

Oracle DB - only supports C and Cobol - it has dropped Fortran

MySQL/MariaDB - no pre-compilers

PostgreSQL - only C (from project itself - an open source Cobol exist)

SQLServer - dropped all support

DB2 - still support Cobol, PL/I and C (maybe also Fortran - not sure)

Sybase (or whatever SAP calls it today) - I believe they have dropped
all support

SQLite - no pre-compilers

NoSQL databases (MongoDB etc.) - obviously no embedded SQL :-)

Arne

On 10/13/2022 1:28 PM, Simon Clubley wrote:
> On 2022-10-13, Single Stage to Orbit <alex.buell@munted.eu> wrote:
>> On Thu, 2022-10-13 at 13:00 +0000, Simon Clubley wrote:
>>>> What, no Ada?
>>>>
>>>
>>> Ada doesn't exist for x86-64 VMS and looks like it will never exist.
>>
>> GNU can step up with their GNAT compiler. In theory it should be
>> possible to port it to VMS.
>
> AdaCore used to supply the compiler for Alpha and Itanium VMS as part
> of an agreement between AdaCore and DEC.
>
> That VMS support was dropped several years ago by AdaCore.
>
> Given the nature of the Ada market, any such port would probably need
> to be done, and fully supported, by a commercial company.
>
> Simon.
>

Beggers can be choosy, huh?

It would be interesting to have some idea of the size of the ADA market. Easier
to tell if any such work would be worth doing.

What might be helpful is a form of lease of the compiler, not one time fee or
free. Might provide some incentive for people to implement it on x86 VMS.

That concept just might cause lots of other software to become available.

--
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 10/13/22 19:14, Arne Vajhøj wrote:
> On 10/13/2022 6:25 PM, Bill Gunshannon wrote:
>> On 10/13/22 17:40, Jan-Erik Söderholm wrote:
>>> Think of it as a compiler for a language called "SQL".
>>> The default file type for these files (on VMS) is .SQLMOD
>>>
>>> It's more or less "just" as a compiler for any other language.
>>> And it creates a object files that are no different from any
>>> other object file, may it come from C, Pascal or whatever.
>>>
>>> That object file can then be linked into any other application
>>> following the VMS calling standard. That other language does not
>>> need to have any native support for Rdb, it just has to follow the
>>> VMS calling standard.
>>>
>>> It is just a function call with some parameters that returns some
>>> defined result. The caller does not need to know that it was Rdb
>>> that returned the result.
>>
>> Well, that's pretty cool.  I have never seen COBOL used that way
>> although there really is no reason not to.  Just like the libraries
>> linked to from the EXEC SQL parts of the code are actually C or C++
>> snippets.  You can directly link to the PostGres Libraries but, for
>> obvious reasons, using the Embedded SQL method is easier on the
>> programmer.
>
> Embedded SQL is pretty efficient - few lines achieve much - way
> more efficient than library calls in compiled languages (probably
> less efficient than library calls in scripts languages and ORM).
>
> But the industry is moving away from embedded SQL and precompilers.
>
> Oracle DB - only supports C and Cobol - it has dropped Fortran

That means Fortran is out, not embedded SQL.

>
> MySQL/MariaDB - no pre-compilers

No one has expressed a need or desire for it yet. (I have done
some playing with making ESQL work but nothing production level.)
More a MySQL shortcoming than embedded SQL.

>
> PostgreSQL - only C (from project itself - an open source Cobol exist)

And that's the way Open Source works. If there was a need other
languages would be supported.

>
> SQLServer - dropped all support

Typical MicroSoft.

>
> DB2 - still support Cobol, PL/I and C (maybe also Fortran - not sure)

Pretty sure they do. Basicly, they support everything their customer
ask for.

>
> Sybase (or whatever SAP calls it today) - I believe they have dropped
> all support

I didn't even think that Sybase was still around.

>
> SQLite - no pre-compilers

See MySQL above. Same rules apply. Including me working on a
precompiler but nothing production ready. Just research into
the level of difficulty.

>
> NoSQL databases (MongoDB etc.) - obviously no embedded SQL  :-)

Obviously. :-)

All of this shows a lack of interest in languages that most people
think are dying. Also in database systems not being used for the
kind of work that Oracle, RDP, DB2 and Postgres are. I see nothing
here that even hints at embedded SQL going away.

bill

>
> Arne
>
>
>
>
>

On 10/13/2022 7:54 PM, Dave Froble wrote:
> On 10/13/2022 1:28 PM, Simon Clubley wrote:
>> On 2022-10-13, Single Stage to Orbit <alex.buell@munted.eu> wrote:
>>> On Thu, 2022-10-13 at 13:00 +0000, Simon Clubley wrote:
>>>> Ada doesn't exist for x86-64 VMS and looks like it will never exist.
>>>
>>> GNU can step up with their GNAT compiler. In theory it should be
>>> possible to port it to VMS.
>>
>> AdaCore used to supply the compiler for Alpha and Itanium VMS as part
>> of an agreement between AdaCore and DEC.
>>
>> That VMS support was dropped several years ago by AdaCore.
>>
>> Given the nature of the Ada market, any such port would probably need
>> to be done, and fully supported, by a commercial company.
>
> Beggers can be choosy, huh?
>
> It would be interesting to have some idea of the size of the ADA
> market.  Easier to tell if any such work would be worth doing.

It is well known that:
- overall usage of Ada has declined a lot the last 25 years
- most Ada usage is in embedded space
- VMS usage has also declined a lot the last 25 years

It seems very unlikely that the market for an Ada compiler
for VMS x86-64 will be huge.

Some may think that the software world would have been a better
place if Ada had the importance of C, but that does not change
how the world is today.

Specifically how much annual revenue the Ada compilers generate
is difficult to say. AdaCore must be the biggest vendor and it
seems like they do not publicize their financials (there are
guesses on the internet, but I have little confidence in those).
It is not a huge company - closer to VSI than to HPE.

Arne

On 14/10/2022 7:14 am, Arne Vajhøj wrote:
> On 10/13/2022 6:25 PM, Bill Gunshannon wrote:
>> On 10/13/22 17:40, Jan-Erik Söderholm wrote:
>>> Think of it as a compiler for a language called "SQL". The
>>> default file type for these files (on VMS) is .SQLMOD
>>>
>>> It's more or less "just" as a compiler for any other language.
>>> And it creates a object files that are no different from any
>>> other object file, may it come from C, Pascal or whatever.
>>>
>>> That object file can then be linked into any other application
>>> following the VMS calling standard. That other language does not
>>> need to have any native support for Rdb, it just has to follow
>>> the VMS calling standard.
>>>
>>> It is just a function call with some parameters that returns
>>> some defined result. The caller does not need to know that it was
>>> Rdb that returned the result.
>>
>> Well, that's pretty cool. I have never seen COBOL used that way
>> although there really is no reason not to. Just like the
>> libraries linked to from the EXEC SQL parts of the code are
>> actually C or C++ snippets. You can directly link to the PostGres
>> Libraries but, for obvious reasons, using the Embedded SQL method
>> is easier on the programmer.
>
> Embedded SQL is pretty efficient - few lines achieve much - way more
> efficient than library calls in compiled languages (probably less
> efficient than library calls in scripts languages and ORM).
>
> But the industry is moving away from embedded SQL and precompilers.
>
> Oracle DB - only supports C and Cobol - it has dropped Fortran
>
> MySQL/MariaDB - no pre-compilers
>
> PostgreSQL - only C (from project itself - an open source Cobol
> exist)
>
> SQLServer - dropped all support
>
> DB2 - still support Cobol, PL/I and C (maybe also Fortran - not
> sure)
>
> Sybase (or whatever SAP calls it today) - I believe they have dropped
> all support
>
> SQLite - no pre-compilers
>
> NoSQL databases (MongoDB etc.) - obviously no embedded SQL :-)
>
> Arne
>
>
>
>
>

IIRC Oracle/Rdb is the only RDBMS that executes in the context of the
calling process through DSRI. Sounds pretty efficient. Dynamic qyuery
optimization notwithstanding.

On 14/10/2022 5:40 am, Jan-Erik Söderholm wrote:
> Den 2022-10-13 kl. 02:14, skrev Bill Gunshannon:
>> On 10/12/22 19:22, Arne Vajhøj wrote:
>>> On 10/12/2022 6:58 PM, Bill Gunshannon wrote:
>>>> On 10/12/22 17:33, Arne Vajhøj wrote:
>>>>> On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
>>>>>> Using a compatibility layer and trying to make PostGres
>>>>>> look like RDB (or Oracle) would be a major mistake. Better
>>>>>> to bite the bullet and move into the current century.
>>>>>
>>>>> It is a tradeoff.
>>>>>
>>>>> There are benefits from doing things the standard way instead
>>>>> of doing it the compatibility way.
>>>>>
>>>>> But there are also huge cost of changing the client
>>>>> applications.
>>>>
>>>> Maybe and maybe not as much as you think. Granted, most of my
>>>> experience doing it has been with COBOL but I have been able
>>>> to take programs using databases from other systems and moved
>>>> them quite easily. I would love to have someone send me a
>>>> COBOL program that uses RDB just for a look-see.
>>>
>>> Cobol embedded SQL is probably one of the more portable. But it
>>> is not supported by PostgreSQL project itself.
>>
>> No, but this is the Open Source world. A need arose and someone
>> rushed in to fill it. And it works quite well.
>>
>>>
>>> An extremely simple Cobol embedded SQL to Rdb example:
>>> https://www.vajhoej.dk/arne/articles/vmsdb.html#rdb_cob_emb
>>
>> I saw nothing in there that would not compile using ESQL and
>> GnuCOBOL with PostGres. Even the module stuff (which I am not
>> familiar with)
>
> Think of it as a compiler for a language called "SQL". The default
> file type for these files (on VMS) is .SQLMOD
>
> It's more or less "just" as a compiler for any other language. And it
> creates a object files that are no different from any other object
> file, may it come from C, Pascal or whatever.
>
> That object file can then be linked into any other application
> following the VMS calling standard. That other language does not need
> to have any native support for Rdb, it just has to follow the VMS
> calling standard.
>
> It is just a function call with some parameters that returns some
> defined result. The caller does not need to know that it was Rdb that
> returned the result.
>

A slight nit. SQLMOD makes you specify the calling language. If you
specify COBOL then your module procedures refuse to look for dynamic
descriptors which can be RTL'd in COBOL
>

Den 2022-10-14 kl. 04:07, skrev Richard Maher:
> On 14/10/2022 5:40 am, Jan-Erik Söderholm wrote:
>> Den 2022-10-13 kl. 02:14, skrev Bill Gunshannon:
>>> On 10/12/22 19:22, Arne Vajhøj wrote:
>>>> On 10/12/2022 6:58 PM, Bill Gunshannon wrote:
>>>>> On 10/12/22 17:33, Arne Vajhøj wrote:
>>>>>> On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
>>>>>>> Using a compatibility layer and trying to make PostGres
>>>>>>> look like RDB (or Oracle) would be a major mistake. Better
>>>>>>> to bite the bullet and move into the current century.
>>>>>>
>>>>>> It is a tradeoff.
>>>>>>
>>>>>> There are benefits from doing things the standard way instead
>>>>>> of doing it the compatibility way.
>>>>>>
>>>>>> But there are also huge cost of changing the client
>>>>>> applications.
>>>>>
>>>>> Maybe and maybe not as much as you think.  Granted, most of my
>>>>> experience doing it has been with COBOL but I have been able
>>>>> to take programs using databases from other systems and moved
>>>>> them quite easily.  I would  love to have someone send me a
>>>>> COBOL program that uses RDB just for a look-see.
>>>>
>>>> Cobol embedded SQL is probably one of the more portable. But it
>>>> is not supported by PostgreSQL project itself.
>>>
>>> No, but this is the Open Source world.  A need arose and someone rushed
>>> in to fill it.  And it works quite well.
>>>
>>>>
>>>> An extremely simple Cobol embedded SQL to Rdb example:
>>>> https://www.vajhoej.dk/arne/articles/vmsdb.html#rdb_cob_emb
>>>
>>> I saw nothing in there that would not compile using ESQL and
>>> GnuCOBOL with PostGres.  Even the module stuff (which I am not
>>> familiar with)
>>
>> Think of it as a compiler for a language called "SQL". The default
>> file type for these files (on VMS) is .SQLMOD
>>
>> It's more or less "just" as a compiler for any other language. And it
>> creates a object files that are no different from any other object
>> file, may it come from C, Pascal or whatever.
>>
>> That object file can then be linked into any other application following
>> the VMS calling standard. That other language does not need
>> to have any native support for Rdb, it just has to follow the VMS
>> calling standard.
>>
>> It is just a function call with some parameters that returns some defined
>> result. The caller does not need to know that it was Rdb that
>> returned the result.
>>
>
> A slight nit. SQLMOD makes you specify the calling language. If you specify
> COBOL then your module procedures refuse to look for dynamic descriptors
> which can be RTL'd in COBOL
>>
>

That is right. If you have built your SQLMOD object files using the "wrong"
"language calling standard", you will need a few additional things to
get the calls working.

But that is the same as calling between different languages directly.

On 10/13/2022 10:05 PM, Richard Maher wrote:
>  IIRC Oracle/Rdb is the only RDBMS that executes in the context of the
> calling process through DSRI. Sounds pretty efficient. Dynamic qyuery
> optimization notwithstanding.

There are lots of databases executing in process context:
SQLite, Firebird, H2, HSQLDB, good old (or bad old depending on view)
Access.

Rdb uniqueness is:
- it supports both executing in process context (embedded SQL,
SQL modules, JDBC native driver) and executing in separate
server (JDBC thin driver, SQL Services API, ODBC)
- even when executing in process context there are still some
central administrative processes running
- it is geared towards large usage while traditional embedded
databases are really geared towards small usage or test

Arne

On 2022-10-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 10/13/2022 10:05 PM, Richard Maher wrote:
>>  IIRC Oracle/Rdb is the only RDBMS that executes in the context of the
>> calling process through DSRI. Sounds pretty efficient. Dynamic qyuery
>> optimization notwithstanding.
>
> There are lots of databases executing in process context:
> SQLite, Firebird, H2, HSQLDB, good old (or bad old depending on view)
> Access.
>
> Rdb uniqueness is:
> - it supports both executing in process context (embedded SQL,
> SQL modules, JDBC native driver) and executing in separate
> server (JDBC thin driver, SQL Services API, ODBC)
> - even when executing in process context there are still some
> central administrative processes running
> - it is geared towards large usage while traditional embedded
> databases are really geared towards small usage or test
>

And IIRC, isn't Rdb _fully_ and closely integrated into the VMS cluster
model with full VMS-style disaster recovery on node/site failures ?

Simon.

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