Re: Accessing other files was Re: news400 goes negative on IBM? -- MIDRANGE-L

Carel, I think I can answer this one.

ODBC & DRDA are equivalent functionally - they both enable working with data in different database systems from remote machines. The manufacturer of the database is responsible, usually, for providing a driver to allow interfacing with that database. Almost everyone has written ODBC drivers or OLE/DB providers, for Windows and Linux systems. Almost no one has written DRDA providers, known as ARDs on the iSeries (application request drivers).

There are layers in each kind of connectivity process, and they are similar, AFAIK

ODBC: Your app talks to the ODBC management layer which uses the ODBC driver for a certain RDBMS to convert the request to the syntax of the RDBMS and connects to something in the RDBMS that is like the DB host server on the iSeries

DRDA Your RPG embedded SQL app talks to the relational DB layer which uses the ARD specified in the RDBDIRE to convert the request to the syntax of the RDBMS and connects to something in the RDBMS that is like the DB host server on the iSeries

When you set up your RDBDIRE to talk to your PC, there is nothing there to receive the DRDA requests. I am willing to bet that MS has an ARD for SQL Server - they had that SNA Server stuff, etc., so they know the iSeries. But they've never marketed anything - this is pure speculation on my part. Sybase has not made an ARD, there certainly is nothing for mySQL. So the problem is , there is no middleware piece (an ARD) to let the iSeries talk to non-DB2 databases with interactive SQL or embedded SQL.

So IBM has their Information Integrator that will talk to any RDBMS if the ODBC/OLE/DB provider lives on the box where Inf Int is installed. And it does receive DRDA, thus enabling the use of SQL on the iSeries to talk to non-DB2 databases. Or you get something like our RPG2SQL that gives you CLI-like functions that are sent to our RPG2SQL Integrator on some PC, which will then talk to any database for which you have the right driver.

CLI on the 400, by the way, is like the raw, base ODBC function calls syntactically. You have to tell it to connect to something, get some handles back (in Windows, anyway), tell the remote system what statement you will run, ask to get the recordset, ask for each in return, all with individual function calls.

At 02:57 PM 5/21/2005, you wrote:

Then I would like to add this question:
1) With ODBC I can create a Data Source (DS) that connects to my AS/400. The ODBC DS is the client, the AS/400 is the server.

2) On the AS/400 I can add a remote DB entry (WRKRDBDIRE) to our local database on a PC network (OS: Novell) , give its IP address, using the default DRDA programme (listening to port 446). The AS/400 is the client, the PC-network is the server.
A connection with ODBC works,. the conection from the AS/400 not.
So, what piece of software/services on the AS/400 are running to process the ODBC request? Or rather: why is link 1 possible?
The next question would be, of course, can this process not be reversed?
Just very curious.
Regards,
Carel Teijgeler.
*********** REPLY SEPARATOR  ***********
On 20-5-05 at 17:04 rob@xxxxxxxxx wrote:
>I don't necessarily need RPG native access to other databases. Imbedded >SQL will get the job done. But you cannot CONNECT TO a SQL server >database, as suggested. Unless you purchase some other tool. Now IBM has >a product that will allow you to do this. Several third parties have >products that connect to sql server and others. But instead of just >making a simple CONNECT TO work they have you call a bunch of apis to get >data off of the other systems. Probably why IBM charges about 3 times what the other people charge.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.