Re: SQL with connections to multiple databases

You can do JDBC on the same box. I have at least one app that does it. I'm pretty sure it uses JDBCR4. I don't recall if it uses the jt400.jar or the native jar.



________________________________
From: D*B <dieter.bender@xxxxxxxxxxxx>
Sent: Thursday, November 30, 2017 3:15 AM
To: RPG programming on the IBM i / System i
Subject: RE: SQL with connections to multiple databases

<JRS>
What I have found is the customer's Program B is doing an ODBC connection to
the DB2. It is not to a different database as was originally thought. The
customer said it was a remote database connection and I didn't question it.
I suppose it is also possible that it is a JDBC connection not an ODBC.

I know I can write a program on Windows or Unix that connects to DB2 via
ODBC but is there an ODBC driver that runs on the iSeries to allow an
iSeries program to connect to the DB2 that it is running on?
</JRS>

There is an ODBC driver for Linux, running on AS400, maybe this could be
used from C or ILE too, but using this or JDBC (via "embedded Java" in RPG)
should not make too much diffrence.

<JRS>
There is also a QSQSRVR job in the middle of this mess
</JRS>

So it would look like, using ODBC or JDBC. Are you sure about this, or is it
an assumption?

<JRS>
the library containing File1 is not in its library list.
</JRS>

The QSQSRVR is a completely independent job, communicating asynchronous with
the Job making the connect. Both have it's own environment. Programm B (as
you named it) sends a request to QSQSRVR job, waits for a repsonse (might be
caused by a timeout too)and goes on. When Programm b returns controll to
Programm a, it goes on in the same Job that was running at the time before A
called B. The Environment could be corrupted (by a change to library list
for instance, or a software defect, or storage corruption), but not
influenced by QSQSRVR. The connect state could be important, if it has been
a *RUW connection, you can't switch the connection, or make a successfull
connect reset, if the transaction is active. You would have to end the
transaction by a rollback or commit, before the connect reset would be
successfull. The connect reset would end the remote connect, if it has been
*ruw.

<JRS>
I'm guessing at this point...
</JRS>

You (and we) could play this game untill next year. Guessing doesn't help so
much. Information is needed. Implement some logging into your software, that
could be turned on or off, by setting an external debug property. The
logging could be done via QMHSNDPM sending entries to the joblog, a logfile
or whatever you want. Maybe a dump before an after call of programm B might
be helpfull too.

D*B