|
> 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
As an Amazon Associate we earn from qualifying purchases.
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.