From Newsgroup: comp.os.vms

Database client libraries for VMS are often a problem, because
database vendors do not see VMS as an important platform.

The only ones not having the problem are those using JVM languages
(Java, Groovy, Kotlin, Scala etc.). Because Java developers for
decades has preferred Type 4 JDBC drivers (pure Java) over Type 2
JDBC drivers (Java wrapper around native client), then they can
usually just copy a Type 4 JDBC driver jar over from Windows/Linux
and they are good to go.

Everybody know that you can do:

Java code--(JNI)-->C/C++ code

But it is actually also possible to do:

C/C++ code--(JNI)-->Java code

So in theory a C/C++ application could use JNI to load a JVM and use
a Type 4 JDBC driver.

There is only one problem. JNI is a low level, pretty old and rather
cumbersome API to use. It would not be trivial to use JDBC via JNI.

But recently I fell over an interesting open source project java4cpp (https://github.com/wshackle/java4cpp)) that automatically generates
C++ wrappers from Java classes (via reflection).

So I tried to generate C++ wrappers for JDBC. And it worked. And it
also worked on VMS (VMS x86-64 - I have not tried with the older
C++ compilers on Alpha/Itanium).

This code runs:

#include <iostream>
#include <string>

using namespace std;

#include "jdbc.h"

using namespace javaforcpp;
using namespace javaforcpp::java::sql;

#include "util.cpp"

int main()
{
try
{
jstring constr = newString("jdbc:mysql://arnepc5/Test");
jstring usr = newString("arne");
jstring pwd = newString("hemmeligt");
Connection con = DriverManager::getConnection(constr, usr, pwd);
jfree(constr);
jfree(usr);
jfree(pwd);
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery("SELECT f1,f2 FROM t1");
while(rs.next())
{
long int f1 = rs.getInt(1);
jstring f2 = rs.getString(2);
cout << f1 << " " << jstring2string(f2) << endl;
}
rs.close();
stmt.close();
con.close();
}
catch(jthrowable& ex)
{
PrintJThrowable("Exception in Java:\n", ex);
}
return 0;
}

(it should look very familiar to anyoine having used Java
and JDBC)

It is still using JNI under the hood. And there are a few things
that reveal it - there are references to jint, jstring,
jthrowable etc..

But overall the code is a thousand times nicer than normal JNI
code. No magic but java4cpp generated about 30000 lines of wrapper
C++ code. It helps.

If anyone want to try it:
https://www.vajhoej.dk/arne/vmsstuff/jdbc/

I have tested with:
* H2
* MySQL
* PostgreSQL
* Oracle DB
* IBM DB2
* MS SQLServer

That covers a lot of the most common RDBMS'es.

It works pretty well. Happy path and simple SQLException are all good.

But mess up with the JNI stuff and you will see some really bad
program crashes. You have been warned.

Arne
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Mon, 2026-04-13 at 11:07 -0400, Arne Vajh|+j wrote:

#include <iostream>
#include <string>

using namespace std;

#include "jdbc.h"

using namespace javaforcpp;
using namespace javaforcpp::java::sql;

#include "util.cpp"

int main()
{
-a-a-a-a try
-a-a-a-a {
-a-a-a-a-a-a-a-a jstring constr = newString("jdbc:mysql://arnepc5/Test"); -a-a-a-a-a-a-a-a jstring usr = newString("arne");
-a-a-a-a-a-a-a-a jstring pwd = newString("hemmeligt");
-a-a-a-a-a-a-a-a Connection con = DriverManager::getConnection(constr, usr, pwd);
-a-a-a-a-a-a-a-a jfree(constr);
-a-a-a-a-a-a-a-a jfree(usr);
-a-a-a-a-a-a-a-a jfree(pwd);
-a-a-a-a-a-a-a-a Statement stmt = con.createStatement();
-a-a-a-a-a-a-a-a ResultSet rs = stmt.executeQuery("SELECT f1,f2 FROM t1"); -a-a-a-a-a-a-a-a while(rs.next())
-a-a-a-a-a-a-a-a {
-a-a-a-a-a-a-a-a-a-a-a-a long int f1 = rs.getInt(1);
-a-a-a-a-a-a-a-a-a-a-a-a jstring f2 = rs.getString(2); -a-a-a-a-a-a-a-a-a-a-a-a cout << f1 << " " << jstring2string(f2) << endl; -a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a rs.close();
-a-a-a-a-a-a-a-a stmt.close();
-a-a-a-a-a-a-a-a con.close();
-a-a-a-a }
-a-a-a-a catch(jthrowable& ex)
-a-a-a-a {
-a-a-a-a-a-a-a-a PrintJThrowable("Exception in Java:\n", ex);
-a-a-a-a }
-a-a-a-a return 0;
}

Only jthrowable is caught; C++ exceptions from newString or other code
will bypass the handler.

Oops!
--
Tactical Nuclear Kittens
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/13/2026 12:54 PM, Single Stage to Orbit wrote:

On Mon, 2026-04-13 at 11:07 -0400, Arne Vajh|+j wrote:

-a-a-a-a-a-a-a-a jstring constr = newString("jdbc:mysql://arnepc5/Test"); >> -a-a-a-a-a-a-a-a jstring usr = newString("arne");
-a-a-a-a-a-a-a-a jstring pwd = newString("hemmeligt");
-a-a-a-a-a-a-a-a Connection con = DriverManager::getConnection(constr, usr, pwd);

-a-a-a-a catch(jthrowable& ex)
-a-a-a-a {
-a-a-a-a-a-a-a-a PrintJThrowable("Exception in Java:\n", ex);
-a-a-a-a }

Only jthrowable is caught; C++ exceptions from newString or other code
will bypass the handler.

Oops!

newString is a very thin wrapper around some JNI functions, so
it should also throw a jthrowable if it throws.

The catch does not really handle anything - it only shows
how to get the error message from a SQLException printed
in this context.

For serious code then you will likely want proper handling
of both jthrowable and various C++ exceptions.

I could have added a:

catch(...)

but I didn't.

Arne

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-04-13, Arne Vajhoj <arne@vajhoej.dk> wrote:

But overall the code is a thousand times nicer than normal JNI
code. No magic but java4cpp generated about 30000 lines of wrapper
C++ code. It helps.

30_000 lines ???!!!111!!! :-)

That's _almost_ the size of a modern-day "Hello World". :-)

If anyone want to try it:
https://www.vajhoej.dk/arne/vmsstuff/jdbc/

I have tested with:
* H2
* MySQL
* PostgreSQL
* Oracle DB
* IBM DB2
* MS SQLServer

That covers a lot of the most common RDBMS'es.

It works pretty well. Happy path and simple SQLException are all good.

But mess up with the JNI stuff and you will see some really bad
program crashes. You have been warned.

Only if you are lucky. If you are unlucky, a faulty JNI program will not crash.

Fortunately, I rapidly learnt to keep it simple when writing JNI-based interfaces, so I am far less in need of luck than I otherwise would be. :-)

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

From Newsgroup: comp.os.vms

On 4/13/2026 1:16 PM, Simon Clubley wrote:

On 2026-04-13, Arne Vajh|+j <arne@vajhoej.dk> wrote:

I have tested with:
* H2
* MySQL
* PostgreSQL
* Oracle DB
* IBM DB2
* MS SQLServer

That covers a lot of the most common RDBMS'es.

It works pretty well. Happy path and simple SQLException are all good.

But mess up with the JNI stuff and you will see some really bad
program crashes. You have been warned.

Only if you are lucky. If you are unlucky, a faulty JNI program will not crash.

Guess I must be "lucky" then, because I got a large number
of program crashes and process dumps and a few cases where
the process (!) was toast, before I got things sorted out.

:-)

Fortunately, I rapidly learnt to keep it simple when writing JNI-based interfaces, so I am far less in need of luck than I otherwise would be. :-)

JNI is a PITA to work with.

This is a different approach. Instead of having the developer write
all the glue code then it gets generated. Avoids human errors.

And for the more common case of native->Java, then JNI is
obsolete by now. Anyone being on Java 21+/25+ should use
Foreign Function instead of JNI. Much more high level
(and the glue code is on the Java side not the native side).

Unfortunately on VMS then Java 17 is still in beta and
I suspect that it may take a couple of years before
we get Java 25.

Arne

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/13/2026 1:43 PM, Arne Vajh|+j wrote:

And for the more common case of native->Java, then JNI is
obsolete by now. Anyone being on Java 21+/25+ should use
Foreign Function instead of JNI. Much more high level
(and the glue code is on the Java side not the native side).

Correction:

22+/25+

first version with feature final (out of preview) /
first LTS (read: relevant) version

Arne

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/13/2026 11:07 AM, Arne Vajh|+j wrote:

But recently I fell over an interesting open source project java4cpp (https://github.com/wshackle/java4cpp)) that automatically generates
C++ wrappers from Java classes (via reflection).

So I tried to generate C++ wrappers for JDBC. And it worked. And it
also worked on VMS (VMS x86-64 - I have not tried with the older
C++ compilers on Alpha/Itanium).

And C++ classes can be wrapped as C functions.

And C functions can be wrapped for Pascal.

I tried writing a few of those wrappers.

So now both these work:

#include <stdio.h>

#include "cjdbc.h"

int main()
{
con_t con =
DriverManager_getConnection3("jdbc:mysql://arnepc5/Test", "arne", "hemmeligt");
stmt_t stmt = Connection_createStatement(con);
rs_t rs = Statement_executeQuery(stmt, "SELECT f1,f2 FROM t1");
while(ResultSet_next(rs))
{
int f1 = ResultSet_getInt(rs, 1);
char f2[256];
int f2len;
ResultSet_getString(rs, 2, f2, sizeof(f2), &f2len);
printf("%d %s\n", f1, f2);
}
ResultSet_close(rs);
Statement_close(stmt);
Connection_close(con);
return 0;
}

and:

[inherit('pjdbcdir:common', 'pjdbcdir:pjdbc')]
program testp(input,output);

var
con : con_t;
stmt : stmt_t;
rs : rs_t;
f1 : integer;
f2 : pstr;

begin
con := DriverManagerGetConnection3('jdbc:mysql://arnepc5/Test',
'arne', 'hemmeligt');
stmt := ConnectionCreateStatement(con);
rs := StatementExecuteQuery(stmt, 'SELECT f1,f2 FROM t1');
while ResultSetNext(rs) do begin
f1 := ResultSetGetInt(rs, 1);
f2 := ResultSetGetString(rs, 2);
writeln(f1:1, ' ', f2);
end;
ResultSetClose(rs);
StatementClose(stmt);
ConnectionClose(con);
end.

As usual I think the Pascal code is somewhat "nice".

Arne

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/13/2026 8:24 PM, Arne Vajh|+j wrote:

On 4/13/2026 11:07 AM, Arne Vajh|+j wrote:

But recently I fell over an interesting open source project java4cpp
(https://github.com/wshackle/java4cpp)) that automatically generates
C++ wrappers from Java classes (via reflection).

So I tried to generate C++ wrappers for JDBC. And it worked. And it
also worked on VMS (VMS x86-64 - I have not tried with the older
C++ compilers on Alpha/Itanium).

And C++ classes can be wrapped as C functions.

And C functions can be wrapped for Pascal.

I tried writing a few of those wrappers.

I have added the C and Pascal wrappers to:

https://www.vajhoej.dk/arne/vmsstuff/jdbc/

C++ / C / Pascal access to H2 / MySQL / PostgreSQL /
Oracle DB / IBM DB2 / MS SQLserver / anything else
with a type 4 JDBC driver on VMS x86-64.

That is not bad.

An obvious concern would of course be the support
status of all this.

But that is not bad either:

Java, C++, C, Pascal : supported by VSI
JDBC drivers : supported by the database vendors
C++ wrapper : 56 lines of my code
C wrapper : 209 lines of my code
Pascal wrapper : 211 lines of my code

I can easily make 50 bugs in 500 lines
of code.

:-)

But fixing my bugs in 500 lines of very simple
code should not be a big problem.

Arne

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/13/26 10:07 AM, Arne Vajh|+j wrote:

Database client libraries for VMS are often a problem, because
database vendors do not see VMS as an important platform.

The only ones not having the problem are those using JVM languages

That's a little overstated. VSI has ported SQL Relay:

https://sqlrelay.sourceforge.net/index.html

which supports quite a few of the major DBMS players. In some cases,
the individual drivers used by SQL Relay can also be used directly.
I've been doing the latter with FreeTDS to SQL Server for about 25 years.

But recently I fell over an interesting open source project java4cpp (https://github.com/wshackle/java4cpp)) that automatically generates
C++ wrappers from Java classes (via reflection).

So I tried to generate C++ wrappers for JDBC. And it worked. And it
also worked on VMS (VMS x86-64 - I have not tried with the older
C++ compilers on Alpha/Itanium).

It's a clever workaround and it looks like you had fun working up the
proof of concept, so kudos. I'm not convinced it's a great general
solution.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/14/2026 8:18 PM, Arne Vajh|+j wrote:

On 4/14/2026 5:34 PM, Craig A. Berry wrote:

On 4/13/26 10:07 AM, Arne Vajh|+j wrote:

But recently I fell over an interesting open source project java4cpp
(https://github.com/wshackle/java4cpp)) that automatically generates
C++ wrappers from Java classes (via reflection).

So I tried to generate C++ wrappers for JDBC. And it worked. And it
also worked on VMS (VMS x86-64 - I have not tried with the older
C++ compilers on Alpha/Itanium).

It's a clever workaround and it looks like you had fun working up the
proof of concept,

Having fun is what drives this kind of effort.

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a I'm not convinced it's a great general
solution.

I don't think it is bad from a technical perspective:
* it works
* it is not introducing an extra tier
* it is a very nice API that millions of developers already know

But do I think there will be any interest in using it? No!
I expect practically zero interest.

A somewhat similar idea is JayDebBeApi:
https://pypi.org/project/JayDeBeApi/
a Python library for using JDBC drivers.

Python app
[DB 2.0 API]
JayDeBeApi: Python wrapper
["JDBC like" API]
JPype: Python + C + Java code providing Python-Java bridge via JNI
[JDBC API]
Java
JDBC driver

vs:

Pascal app
["JDBC like" API]
Pascal wrapper
["JDBC like" API]
C wrapper
["JDBC like" API]
C++ wrapper
[JDBC API]
Java
JDBC driver

Arne

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/14/2026 8:18 PM, Arne Vajh|+j wrote:

On 4/14/2026 5:34 PM, Craig A. Berry wrote:

On 4/13/26 10:07 AM, Arne Vajh|+j wrote:

Database client libraries for VMS are often a problem, because
database vendors do not see VMS as an important platform.

The only ones not having the problem are those using JVM languages

That's a little overstated. VSI has ported SQL Relay:

https://sqlrelay.sourceforge.net/index.html

which supports quite a few of the major DBMS players.

I know about SQLRelay.

https://www.vajhoej.dk/arne/articles/vmstd2.html

:-)

And SQLRelay is certainly a relevant solution to the problem. It
supports almost all major RDBMS.

But it is a different model.

It is not:

app->DB client lib----->DB

but:

app->SQLRelay client lib----->SQLRelay server->DB client lib----->DB

And the JDBC API is a bit nicer than the SQLRelay API if you ask
me. For various reasons including:
* same parameter placeholder for all databases
* database meta data

In all fairness then SQLRelay does have one big
advantage: it comes with an embedded SQL precompiler
for C and Cobol.

That is important for VMS, because a big part of
existing VMS database applications use embedded SQL
(because they were created at a time where embedded
SQL was "the way").

In practice that may count for a lot more than
some of the nice JDBC features like database
meta data and escape syntax.

Arne

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/15/2026 7:56 PM, Arne Vajh|+j wrote:

In all fairness then SQLRelay does have one big
advantage: it comes with an embedded SQL precompiler
for C and Cobol.

Any hint as to where one would find that? I looked at their
web pages and could find no mention of a Pre-Compiler or COBOL.

That is important for VMS, because a big part of
existing VMS database applications use embedded SQL
(because they were created at a time where embedded
SQL was "the way").

Also, no mention of VMS in the supported platforms.

In practice that may count for a lot more than
some of the nice JDBC features like database
meta data and escape syntax.

Arne

bill

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/16/2026 5:02 PM, bill wrote:

On 4/15/2026 7:56 PM, Arne Vajh|+j wrote:

In all fairness then SQLRelay does have one big
advantage: it comes with an embedded SQL precompiler
for C and Cobol.

Any hint as to where one would find that?-a I looked at their
web pages and could find no mention of a Pre-Compiler or COBOL.

That is important for VMS, because a big part of
existing VMS database applications use embedded SQL
(because they were created at a time where embedded
SQL was "the way").

Also, no mention of VMS in the supported platforms.

It is supported on VMS by VSI (to the extent they support
the open source software they port).

https://products.vmssoftware.com/libsqlrelay

The page is actually outdated. It says V1.9-3G, but
the actual SP has V2.0-0E for Itanium and x86-64.

After install you do:

$ presqlr :== $sqlr$root:[bin]presqlr.exe

and:

$ presqlr /lang=c /iname=pre.pc /oname=pre.c

$ presqlr /lang=cob /iname=pre.pco /oname=pre.cob

Note that like any other embedded SQL precompiler (except SQLJ),
then it is for a specific target - in this case SQLRelay.

Arne







--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/16/2026 5:36 PM, Arne Vajh|+j wrote:

On 4/16/2026 5:02 PM, bill wrote:

On 4/15/2026 7:56 PM, Arne Vajh|+j wrote:

In all fairness then SQLRelay does have one big
advantage: it comes with an embedded SQL precompiler
for C and Cobol.

Any hint as to where one would find that?-a I looked at their
web pages and could find no mention of a Pre-Compiler or COBOL.

That is important for VMS, because a big part of
existing VMS database applications use embedded SQL
(because they were created at a time where embedded
SQL was "the way").

Also, no mention of VMS in the supported platforms.

It is supported on VMS by VSI (to the extent they support
the open source software they port).

https://products.vmssoftware.com/libsqlrelay

The page is actually outdated. It says V1.9-3G, but
the actual SP has V2.0-0E for Itanium and x86-64.

After install you do:

$ presqlr :== $sqlr$root:[bin]presqlr.exe

and:

$ presqlr /lang=c /iname=pre.pc /oname=pre.c

$ presqlr /lang=cob /iname=pre.pco /oname=pre.cob

Note that like any other embedded SQL precompiler (except SQLJ),
then it is for a specific target - in this case SQLRelay.

Note that VSI libpq kit:

https://products.vmssoftware.com/libpq

also comes with a C precompiler allowing working with PostgreSQL.

$ mcr libpq$root:[bin]ecpg whatever.sqc ! produces whatever.c

Unless you are very interested in SQLRelay then that may be
more interesting for you.

Arne


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/16/2026 5:36 PM, Arne Vajh|+j wrote:

On 4/16/2026 5:02 PM, bill wrote:

On 4/15/2026 7:56 PM, Arne Vajh|+j wrote:

In all fairness then SQLRelay does have one big
advantage: it comes with an embedded SQL precompiler
for C and Cobol.

Any hint as to where one would find that?-a I looked at their
web pages and could find no mention of a Pre-Compiler or COBOL.

That is important for VMS, because a big part of
existing VMS database applications use embedded SQL
(because they were created at a time where embedded
SQL was "the way").

Also, no mention of VMS in the supported platforms.

It is supported on VMS by VSI (to the extent they support
the open source software they port).

https://products.vmssoftware.com/libsqlrelay

The page is actually outdated. It says V1.9-3G, but
the actual SP has V2.0-0E for Itanium and x86-64.

After install you do:

$ presqlr :== $sqlr$root:[bin]presqlr.exe

and:

$ presqlr /lang=c /iname=pre.pc /oname=pre.c

$ presqlr /lang=cob /iname=pre.pco /oname=pre.cob

Note that like any other embedded SQL precompiler (except SQLJ),
then it is for a specific target - in this case SQLRelay.

And just to try and explain what is in what.

The SQLRelay open source project provide:
* server with integrations to all sorts of databases
* client with:
- C API library
- C++ API library
- Java, Python, PHP, Ruby, Perl and Tcl drivers

VSI provide:
* client only with
- C API library
- C++ API library
- VMS API library (descriptors etc. for Pascal, Fortran, Basic etc.)
- embedded SQL pre compiler for Cobol and C

Arne

--- Synchronet 3.21f-Linux NewsLink 1.2