Re: ODBC FROM iSeries - huh?

 From: John Pluta

> So what this means is that, in addition to having a CLI-capable SQL
engine,
> you must also support a standard communication API, right?  How do I know
> which comms APIs a given SQL engine supports?  Or is that yet another
piece
> that I have to download and install?

This is an implementation detail normally hidden by the ODBC driver. Only a
middleware weanie like you would care about what protocols the DBMS uses.
:-)

But it's not really a COMs API in the sense of IP or SNA. It's a higher
level protocol that describes the *connection* between an application
program and an RDBMS in a distributed environment. So it looks more like
this:

-------------------------------------------------
DBMS processing protocol
   eg: SQL CLI
-------------------------------------------------
    Connection protocol between application & RDBMS
        eg: DRDA, SQL*Net
-------------------------------------------------
         Network transport protocol
             eg: SNA, IP
-------------------------------------------------


An xDBC driver encapsulates all of those implementation details.


> And in the case of, say, an ODBC request from Windows to Oracle running on
a
> Linux machine: How do I tell the ODBC wrapper on Windows the location of
the
> database on the Linux machine?

For each database, you would configure a new "Data Source" within the ODBC
Manager. The OS/400 equivalent to the ODBC Manager is WRKRDBDIRE.

> How do I tell the ODBC wrapper what comms
> protocol is being used?  Or is there a default comms protocol that ODBC
> uses?

You don't. When adding a new data source, you simply select the appropriate
driver and tell it where to find the database. The driver knows how to talk
to it.

>
> Wow, every time I peel a layer off this onion, I cry harder <grin>...
>

Quit your whining. This is why you make the big bucks. ;-)


> How does JDBC simplify this mess?  Because the JDBC type 3 driver sends
the
> request from machine to machine in a platform-independent way, thus
allowing
> the CLI request from the source machine to be directly executed on the
> target machine?

It doesn't exactly simplify it; it just happens to be available. The JDBC
driver is serving its intended purpose by hiding all of the implementation
details (aka The Mess) from the user. If Oracle chose to write a native ODBC
driver for the AS/400, then it would be just as simple to use as JDBC. The
thing is, nobody writes ODBC drivers for OS/400. Of course, nobody writes
JDBC drivers for OS/400 either; they write them for the JVM. And since our
box has a JVM.... well, you know the rest.

Regards,

John Taylor