RE: DB2

> Leif:
>
>Joe, give it up. You can't win arguments with true 
>believers that have swallowed the hype-hook completely 
>(including the sinker) and don't want to know the truth.
>
>As we know there are other rules that are broken. But, 
>it is futile to convince the true believers. I should have 
>kept my mouth shut. 

Gee Leif, you left off the smiley face :) -- it's a good thing we've come to
know you so well, otherwise we'd misinterpret your good-natured sarcasm for
open contempt.

I'd like to know the truth, Leif.  It's just tough to get to it when you lob
a statement such as "It was not relational at the time and still isn't" and
then say, "There is no need for a drawn-out discussion on this."  It really
seems like you're tired of arguing with us AS/400 bigots, but you love
telling us how it really is.

It's been my understanding that the database as we know it smeared from
sorted flat files on the System 3 to ISAM with internal fixed columns on the
System 38.  Then came a primitive, proprietary query "language" with
OPNQRYF.  Since then there have been half-hearted attempts and major
initiatives toward a layer of SQL compliance.  Unfortunately, some of the
major initiatives were in marketing.  The DB/2 name, I personally think,
reeked of the same kind of half-*ssed brand convergence that IBM would later
try with the eServer line.

A few weeks ago I was setting up some stuff on our old Lawson AS/400
database and our new Lawson Oracle database and was surprised to find that I
could set up a view based on a UNION in Oracle, but not on the AS/400.  I'm
sure you can do this in DB/2 on a mainframe or AIX server.  I suspect there
are more blatant examples, but this is the type of stuff I'm looking for.
I've always wondered how far behind IBM has been even on basic SQL
compliance.

Your statement of "On top of a native database one can build an RDB" seems
to be at the heart of a lot of the discussion.  You and Joe are saying that
the native database does not meet Codd's criteria, while most of the
opposing points of view are saying that you could make an RDB by applying
constraints and techniques to the base functionality.  The arguments are
supporting your point.

I asked my initial question because I always hear very thin arguments about
DB2/400 such as "it's a flat file system" or "it's built on ISAM".  After
you sift out all of the considerable platform bias a drawn-out discussion on
this forum can help to flesh out such arguments.  At the end of the day, I'm
more interested in what's still missing from the AS/400 database.  What
functional components are missing, or what are the integrity and performance
issues left exposed on the AS/400 when compared to a relational database?
Some of the arguments are based on what you can do in DDS, not what you
can't do in AS/400 SQL.  If you cut out the DDS interface, would folks be
aware of what's native and what's not, and would there be enough there to
look anything like a real RDB?

-Jim