Mimer SQL is currently *the* database server available for VMS x86-64.

(we are still waiting for Oracle Rdb and MySQL/MariaDB)

Obviously they do document their client API's:

https://developer.mimer.com/features/database-apis/

But in case someone are considering Mimer then here are my comments
to the API's.

Embedded SQL
support C, Fortran and Cobol
like any other embedded SQL implementation
works perfectly

Module
support C, Pascal, Fortran and Cobol
module definition practically compatible with Rdb module definition
works perfectly
note that the implementation is that the module definition is translated
by MSQL to C with embedded SQL which is then translated by ESQL to C
which is then compiler by C compiler (so C compiler is required no
matter the application language!)

Mimer API (C API)
nice API much easier to use than libmysql, but my guess is that most C applications will use embedded SQL or module - they are just easier to use

JDBC (Java, Groovy, Kotlin, Scala, Jython etc.)
totally standard
can be used directly or with an ORM like JPA on top

ADO.NET (C#, VB.NET etc.)
totally standard
obviously not available on VMS

ODBC
totally standard
relevant in the Windows world
works with C/C++, Delphi, VB*, .NET etc.

mimerpy (Python)
installable via PIP
works both on VMS and non-VMS
standard DB API 2.0
works perfectly

PDO (PHP)
questionable support status (not available on VMS, only available for
PHP 8.1 and 8.2 on Windows, require a build from source on Linux)
but if it is available then it is totally standard

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

My apologies for the duplicates.

It hung when I tried to send, so I did not think it had gone
through.

I had.

Sorry.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-06-20, Arne Vajh�j <arne@vajhoej.dk> wrote:

Mimer SQL is currently *the* database server available for VMS x86-64.

(we are still waiting for Oracle Rdb and MySQL/MariaDB)

Given that the updated Rdb release date was originally ~18 months ago,
that is not good. Can anyone give an updated reason for the delay ?

ADO.NET (C#, VB.NET etc.)
totally standard
obviously not available on VMS

Interesting observation. I wonder why ? C# would be more useful than (say)
Rust for VMS.

Simon.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/23/2025 08:42, Simon Clubley wrote:

Given that the updated Rdb release date was originally ~18 months ago,
that is not good. Can anyone give an updated reason for the delay ?

Ask Oracle.

--
-- Rob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 23/06/2025 14:26, Robert A. Brooks wrote:

On 6/23/2025 08:42, Simon Clubley wrote:

Given that the updated Rdb release date was originally ~18 months ago,
that is not good. Can anyone give an updated reason for the delay ?

Ask Oracle.

It is a long way to Delphi ;)

--
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/23/2025 8:42 AM, Simon Clubley wrote:

On 2025-06-20, Arne Vajhøj <arne@vajhoej.dk> wrote:

Mimer SQL is currently *the* database server available for VMS x86-64.

(we are still waiting for Oracle Rdb and MySQL/MariaDB)

Given that the updated Rdb release date was originally ~18 months ago,
that is not good. Can anyone give an updated reason for the delay ?

The Rdb team gave some indications about the technical aspects of the
project in a presentation some months ago.

But in the end it is probably a resource allocation problem. If
Larry Ellison had called the relevant SVP 3 years ago and said
"I want Rdb on VMS x86-64 in 12 months - you hire 100 software
engineers, if that is not enough you hire a 100 more, if that
is not enough then 100 more, but get it done", then we would
have had Rdb by now. He did not.

(let us ignore the practicality that the Rdb team could
probably not use 300 software engineers)

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/23/2025 8:42 AM, Simon Clubley wrote:

On 2025-06-20, Arne Vajhøj <arne@vajhoej.dk> wrote:

ADO.NET (C#, VB.NET etc.)
totally standard
obviously not available on VMS

Interesting observation. I wonder why ? C# would be more useful than (say) Rust for VMS.

It would be nice indeed.

.NET is a popular choice for the business apps that
are VMS's bread and butter

As an illustration then Synergex seems to be pushing DBL for .NET!

.NET for VMS would give:
* C#, VB.NET and F# out of the box
* third party languages (like DBL!)
* ASP.NET MVC for web services and web apps

But it is also a huge thingy. It would require a lot
of VSI resources to port, test and support.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/23/2025 8:15 PM, Lawrence D'Oliveiro wrote:

On Mon, 23 Jun 2025 13:51:27 -0400, Arne Vajhøj wrote:

If Larry Ellison had called the relevant SVP 3 years ago and said "I
want Rdb on VMS x86-64 in 12 months - you hire 100 software
engineers, if that is not enough you hire a 100 more, if that is not
enough then 100 more, but get it done", then we would have had Rdb
by now.

Brooks’ (First?) Law: “Adding manpower to a late software project makes it
later”.

Adding manpower to the project now may be too late to have a
positive impact. It depends on how well the outstanding tasks
can be done in parallel an how difficult the onboarding process
would be.

But having added manpower early in the project would almost certainly
have had a positive impact.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/23/2025 8:33 PM, Lawrence D'Oliveiro wrote:

On Mon, 23 Jun 2025 20:27:21 -0400, Arne Vajhøj wrote:

But having added manpower early in the project would almost certainly
have had a positive impact.

Software development is not like digging a ditch.

It is not - it is several orders of magnitude more complex.

But the reason there are project teams of different sizes
(10, 25, 50, 100, 250, 500, 1000 ...) is not that management
is incompetent and no size deliver faster than 10 - it is
because with proper planning it is actually possible to
spread out work.

It is not easy, but good project managers, good architects
and good tech leads can do it.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 23 Jun 2025 20:27:21 -0400, Arne Vajhøj wrote:

But having added manpower early in the project would almost certainly
have had a positive impact.

Software development is not like digging a ditch.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 23 Jun 2025 13:51:27 -0400, Arne Vajhøj wrote:

If Larry Ellison had called the relevant SVP 3 years ago and said "I
want Rdb on VMS x86-64 in 12 months - you hire 100 software
engineers, if that is not enough you hire a 100 more, if that is not
enough then 100 more, but get it done", then we would have had Rdb
by now.

Brooks’ (First?) Law: “Adding manpower to a late software project makes it later”.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 23 Jun 2025 20:57:17 -0400, Arne Vajhøj wrote:

On 6/23/2025 8:33 PM, Lawrence D'Oliveiro wrote:

On Mon, 23 Jun 2025 20:27:21 -0400, Arne Vajhøj wrote:

But having added manpower early in the project would almost certainly
have had a positive impact.

Software development is not like digging a ditch.

It is not - it is several orders of magnitude more complex.

And in particular, while 9 men may dig a ditch 9 times quicker than one
man, 300 software developers might not be able to finish a software
project 30 times faster than 10 software developers.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/23/2025 9:42 PM, Lawrence D'Oliveiro wrote:

On Mon, 23 Jun 2025 20:57:17 -0400, Arne Vajhøj wrote:

On 6/23/2025 8:33 PM, Lawrence D'Oliveiro wrote:

On Mon, 23 Jun 2025 20:27:21 -0400, Arne Vajhøj wrote:

But having added manpower early in the project would almost certainly
have had a positive impact.

Software development is not like digging a ditch.

It is not - it is several orders of magnitude more complex.

And in particular, while 9 men may dig a ditch 9 times quicker than one
man, 300 software developers might not be able to finish a software
project 30 times faster than 10 software developers.

Not 30 times faster, but much faster.

As long as it is planned upfront.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/24/2025 10:37 AM, bill wrote:

On 6/23/2025 8:57 PM, Arne Vajhøj wrote:

On 6/23/2025 8:33 PM, Lawrence D'Oliveiro wrote:

On Mon, 23 Jun 2025 20:27:21 -0400, Arne Vajhøj wrote:

But having added manpower early in the project would almost certainly
have had a positive impact.

Software development is not like digging a ditch.

It is not - it is several orders of magnitude more complex.

But the reason there are project teams of different sizes
(10, 25, 50, 100, 250, 500, 1000 ...) is not that management
is incompetent and no size deliver faster than 10 - it is
because with proper planning it is actually possible to
spread out work.

It is not easy, but good project managers, good architects
and good tech leads can do it.

If 10 men can complete a project in 10 days how long will it take
20 men?

Obviously 20 days and there is very little likelihood either will
actually be successful.

Putting 10 or 20 people on a supposedly 5 man month project is
highly unusual and not likely to work well.

Believe it or  not, sometimes the right number of men for a project
is one.

Team size one is what gives the highest productivity.

But many tasks are too big for one person.

systemd with 1.7 MLOC was mentioned recently.

If Redhat had put one engineer on it then productivity
would have been great (no project meetings, no endless
design discussions, no handover of information etc.),
but it would take hundreds of years to complete.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-06-24, bill <bill.gunshannon@gmail.com> wrote:

If 10 men can complete a project in 10 days how long will it take
20 men?

Obviously 20 days and there is very little likelihood either will
actually be successful.

More like 25 days. You have to allow for the extra non-linear coordination overhead.

Simon.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-06-23, Arne Vajh�j <arne@vajhoej.dk> wrote:

On 6/23/2025 8:42 AM, Simon Clubley wrote:

On 2025-06-20, Arne Vajh�j <arne@vajhoej.dk> wrote:

ADO.NET (C#, VB.NET etc.)
totally standard
obviously not available on VMS

Interesting observation. I wonder why ? C# would be more useful than (say) >> Rust for VMS.

It would be nice indeed.

.NET is a popular choice for the business apps that
are VMS's bread and butter

As an illustration then Synergex seems to be pushing DBL for .NET!

.NET for VMS would give:
* C#, VB.NET and F# out of the box
* third party languages (like DBL!)
* ASP.NET MVC for web services and web apps

But it is also a huge thingy. It would require a lot
of VSI resources to port, test and support.

Yes it is, but it would have helped solve some of the problems VSI has, especially with Synergex, (unless Synergex have now decided to do
a native x86-64 VMS port).

I would suspect that DBL users still make up a significant portion of
the VMS userbase (unless they have _finally_ been forced to move off
VMS because of an uncertain DBL on x86-64 VMS future).

Simon.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/24/2025 1:37 PM, Simon Clubley wrote:

On 2025-06-24, bill <bill.gunshannon@gmail.com> wrote:

If 10 men can complete a project in 10 days how long will it take
20 men?

Obviously 20 days and there is very little likelihood either will
actually be successful.

More like 25 days. You have to allow for the extra non-linear coordination overhead.

He already assumed that doubling of team size would decrease
productivity with 75%.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/24/2025 1:35 PM, Simon Clubley wrote:

On 2025-06-23, Arne Vajhøj <arne@vajhoej.dk> wrote:

On 6/23/2025 8:42 AM, Simon Clubley wrote:

On 2025-06-20, Arne Vajhøj <arne@vajhoej.dk> wrote:

ADO.NET (C#, VB.NET etc.)
totally standard
obviously not available on VMS

Interesting observation. I wonder why ? C# would be more useful than (say) >>> Rust for VMS.

It would be nice indeed.

.NET is a popular choice for the business apps that
are VMS's bread and butter

As an illustration then Synergex seems to be pushing DBL for .NET!

.NET for VMS would give:
* C#, VB.NET and F# out of the box
* third party languages (like DBL!)
* ASP.NET MVC for web services and web apps

But it is also a huge thingy. It would require a lot
of VSI resources to port, test and support.

Yes it is, but it would have helped solve some of the problems VSI has, especially with Synergex, (unless Synergex have now decided to do
a native x86-64 VMS port).

I would suspect that DBL users still make up a significant portion of
the VMS userbase (unless they have _finally_ been forced to move off
VMS because of an uncertain DBL on x86-64 VMS future).

I have no idea how large a percentage of VMS sites that use DBL or
what percentage of DBL sites run it on VMS.

But unless they release "Traditional DBL" (which seems to be what
they call native DBL) for VMS x86-64 or someone bring .NET yo
VMS x86-64 then both will eventually become zero - it make take
10 or 20 years, but VMS 8.4 on Alpha and Itanium is not viable
super long term.

It is certainly a nice market for VMS. In the total annually cost of
a custom Dibol/DBL application then VMS license and support contract
should be easy to fit in. Typical no crazy scaling requirements.
A large part of Dibol/DBL developers actually know VMS.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)