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 Steve Richter
> > Sent: Wednesday, May 25, 2005 11:35 AM
> > To: Midrange Systems Technical Discussion
> > Subject: Re: DRDA Connection Support (was news400 goes
> > negative on IBM?)
> >
> >
> >
> > 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 )
> 
> You're missing the point.
> 
> The point is, because MS and Oracle chose to use a proprietary protocol to 
> talk to their respective RDBMSs you are forced to rely on the RDBMS vendor 
> providing a ODBC/OLEDB/JDCBC driver for your platform of choice.
> 
> You can't use a single "generic" ODBC driver to access an _any_ ODBC database.

what I am trying to understand is is it possible to write some sort of
an ODBC driver, whatever you call it, interface between the network
and the SQL Server database.  Where this ODBC interface code would run
on the SQL server system and listen to the ODBC port ( if there is one
).  Any ODBC request sent from the network, from an RPG program that
is addressed to the SQL server database would run thru this interface.
Instead of the ODBC interface connecting directly to SQL Server in the
generic way, as you say it should, .NET code would instead be run
which would translate the ODBC request to a standard .NET
SqlConnection and SqlCommand format.  Then the ODBC interface receives
the response data from SQL server and in turn sends it back in ODBC
form to the requesting RPG program.

This thread has been interesting and I gather that this sort of
interface is doable. Neither IBM or Microsoft have to write it, all
the standards and specs needed are available.  Maybe the only users in
the market for such a solution are as400 users and the demand is not
there.

> 
> On the other hand, you can use a generic DRDA driver to access _any_ DRDA 
> database.  Note that there are or at least were some non-IBM DRDA-compliant 
> DBMS out there.  File Tek, Inc. Platinum Tech, GV DB/DC Sys, and XDB Sys, 
> Inc. are some names I have seen referenced.  Platinum Tech was purchased by 
> CA.  I'm not sure if CA still sells the Platinum Tech DBMS.
> 
> >
> > not enough demand for PHP also?
> 
> IIRC, PHP has already been ported to the iSeries by some brave souls.  Not to 
> mention that I seem to recall that seeing an announcement that IBM would soon 
> be officially supporting PHP on the iSeries.
> 


> >
> > 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
> >
> 
> Give me a break, RPG doesn't have any factor on this discussion.
> 
> You're comparing the "openness" of compliers to the "openness" of the DBMS.  
> Big deal that MS's .NET compiler can use non-Microsoft DB drivers.  If the 
> other DBMS used an open protocol like DRDA, you wouldn't need more than one 
> driver.  You don't in fact need Db2Connection and iDB2 connection.  The DB2 
> .NET driver should work with DB2 on the iSeries, at least ODBC certainly 
> does.  You might lose some implementation specific stuff, but in general it 
> doesn't matter.  Why?  because IBM's DB2 drivers talk DRDA instead of a 
> proprietary protocol.
> 
> How long did it take for MS to finally offer an ODBC driver for Linux?  God 
> forbid that anyone would want to access data in a SQL server from a 
> non-windows platform.  Heck, they probably never would have except for the 
> hackers out there who started reverse engineering a driver for Linux.
> 
> Not to mention that all the "openness" of .NET only applies if you're 
> developing on/for Windows.  But that's another argument.
> 

also that Microsoft is going in an entirely different direction with
its detached dataset approach.  Where the server is asked for data in
dataset sized chunks instead of more traditional record at a time i/o
and server side cursors.   MS is of the opinion that the dataset
approach is more scaleable and farmable then the ODBC way of doing
things.

With detachable and self describing data sets the issue of interfaces
and the need for a standard data transport methodology is minimalized.
  If the database server returns a dataset in XML format, there is 
little need for the big DRDA and ODBC production of routing the
database requests and responses thru all the interfaces and network
ports that we have now.

-Steve