Re: DRDA Connection Support (was news400 goes negative on IBM?)

On 5/25/05, Wilt, Charles <CWilt@xxxxxxxxxxxx> wrote:
> > -----Original Message-----
> > From: midrange-l-bounces@xxxxxxxxxxxx
> > [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Vernon Hamberg
> > Sent: Tuesday, May 24, 2005 10:45 PM
> > To: Midrange Systems Technical Discussion
> > Subject: Re: DRDA Connection Support (was news400 goes
> > negative on IBM?)
> >
> >
> > There is something in, say, SQL Server that responds to
> > requests from ODBC.
> > This is probably some kind of host server thingy, just like
> > the database
> > host server stuff on the 400. I don't think any database has to have
> > something that understands DRDA, the ARD on the 400 needs to
> > understand how
> > to talk with sockets to whatever is listening in SQL Server
> > or MySQL or
> > whatever. Just as an ODBC driver translates the statements in
> > your VB or
> > C++ app to the syntax required for the remote database, so
> > would a DRDA
> > ARD. Then a socket connection is used in both cases to talk
> > probably to the
> > same component of the remote database.
> >
> > At least that's what I think is going on - it certainly is in
> > the case of
> > ODBC. And the remote database is not running anything related
> > to ODBC, it
> > is running its own thing. But I can certainly be far off in
> > this matter.
> 
> The problem is that the protocol used to talk to SQL Server, Oracle ect. by 
> the ODBC driver is not a published standard.

SQL Server is accessible in .NET by using the SqlConnection and
SqlCommand classes. A vendor's ODBC or ARD or DRDA driver would not
lose any functionality going thru that interface ( my guess at least )

> 
> Sure there is at least one open source project that is reverse engineering 
> the MS protocol, but that certainly doesn't make it open.
> 
> So it is difficult if not impossible for IBM to properly support a ARD that 
> talks directly to SQL server or Oracle.
> 
> On the other hand, since IBM follows a published standard, it is easy for 
> Microsoft and Oracle to talk directly to DB2.
> 
> mySQL would be a different matter.  I'd imagine that IBM could support that 
> if there was enough demand.

not enough demand for PHP also?

What is interesting about this topic is how IBM's decision to keep ILE
and RPG frozen in time in 1990  ripples thru its entire product line. 
In .NET a programmer accesses the SQL Server database using the
SqlConnection and SqlCommand classes.  To use the DB2 database, you
use the Db2Connection and Db2Command classes. MySql uses another
variation on those class names.  iSeries Db2/400 uses the
iDb2Connection and iDb2Command classes.  Theoretically if you want
your application to use a config file to control which database is
used, a higher level class could be designed that would route the
database i/o to whichever database is being used.

In RPG and ILE all the database function calls go thru the IBM
supplied interfaces.  Since there is no support for classes in RPG,
there are no SqlConnection and SqlCommand style classes that are used
to access the database.   Since IBM routes everything thru its pipe on
the side where the RPG program is, it has to provide the DRDA openness
on the other side of the pipe.

The end result of the different approaches is that if a programmer
wants to access a remote database from a .NET program all you have to
do is plug in the .NET classes code provided by the database vendor. (
or write it yourself ).   To do the same in RPG requires a large,
complex, DRDA spec that in the end is not supported.

-Steve