× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Inline

At 10:31 AM 4/10/02 -0500, you wrote:
> > From: John Taylor
> >
> > The CLI is not a communications protocol; it's just a database API.
>
>I was looking at the CLI, and I saw a 10-character server name, which seemed
>to me to be no more than enough to point to some table with the appropriate
>communications information.  Evidently this is the RDBDIRE table.  One of
>the entry types for the RDBDIRE allows you to specify an ARDPGM to handle
>the requests.  I suspect this would ne the first step down the slippery
>slope to roll-your-own client/server communications.
>
>
> > You don't really need a generic driver. You see, ODBC and CLI are
> > virtually
> > equivalent in terms of syntax, and semantics. The SQL CLI is a standard
> > created by the X/Open Standards Group. ODBC is MS's implementation of that
> > standard. Of course, they've "embraced and extended" it, but they remain
> > very similar.
> >
> > The big trick is how to get the two machines communicating.
>
>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?
>
>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?  How do I tell the ODBC wrapper what comms
>protocol is being used?  Or is there a default comms protocol that ODBC
>uses?
>
>Wow, every time I peel a layer off this onion, I cry harder <grin>...

I think this'd be sockets in the TCP/IP realm. Quite standard.


> > Personally, I don't see why anyone would bother. The conventional argument
> > is that they wish to read/update a remote database directly
> > through RPG, but
> > I wonder if they aren't thinking in terms of doing a simple
> > READ/CHAIN et al
> > against Oracle. Because that's not the way it works.
>
>No doubt - CLI is way different than native I/O.

CLI is just a way to handle SQL between possibly disparate machines.


> > Call me crazy, but I'd much rather just use JDBC.
>
>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?

Bingo. As I mentioned in another post, conversion to each database's SQL
syntax has to be done somewhere. CLI/ODBC do it on the client, JDBC on the
server, I think, anyway.

>Joe
>
>_______________________________________________
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
>To post a message email: MIDRANGE-L@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
>or email: MIDRANGE-L-request@midrange.com
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.