RE: Logical File or OPNQRYF or anyother way ? - Legacy iSeriesFlatFiles -- MIDRANGE-L

I'm going to ask a stupid question here but what is it with all the
bickering and complaints about the iSEries? It seems to me (just a
nobody newbie who is delving into the iSeries) that too much time is
being wasted on stupid arguments here.

If you don't like the iSeries, move on, get something else, if you do
say so and move on.

Damn, I am starting to feel like I'm on some of the idiotic C lists
where everyone is arguing over who has the best compiler.  

I came here to learn but the only thing I seem to learn from this list
is how much everyone wants to argue.

Douglas


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Monday, March 07, 2005 6:24 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Logical File or OPNQRYF or anyother way ? - Legacy
iSeriesFlatFiles


> From: Dave Odom
> 
> Any file that is not created with any "depth", nor relational, nor 
> hierarchical in structure is a flat file, regardless of the numbers or
> sizes of fields; i.e. IMS, DB2, Oracle and the like.   Most files on
the
> iSeries, MVS, VM, VSE, PCs, etc. are flat.

These words have no intrinsic meaning, and your use of the term flat
file is incorrect.  Please define exactly what characteristic gives a
file "depth", and how that is not supported in DB2.


> Oh, my, I have just committed blasphemy, at least per Rochester and 
> those that follow their dogma.

No, you're just making up and/or mis-defining terms.


> I know, I know, IBM Rochester has told you for decades the S/38,
> AS/400, iSeries, etc., is a relational database.   I believed that as
> well back in 1984 after being indoctrinated by the S/38 folks in IBM 
> classes.  But sadly, it was and is not true.

Name a database that is relational.  Identify which of the Codd rules it
follows that DB2/400 does not.


> Secondly, the rest of the
> relational community does not consider the iSeries to be a relational 
> database machine nor have a true and complete relational database 
> architecture for storing data.

By definition, an RDBMS doesn't CARE how the data is stored.
"Relational" cares about how the data is accessed, not stored.  An RDBMS
can store the data in comma-delimited text files as long as it has the
proper relational access (and in fact, tinySQL does just that).


> And the faster Rochester gets in step with the
> relational world, the better off it will be for the iSeries world and 
> its followers so it can compete with the real DB2s, Oracle and other 
> relational worlds.

Where don't we compete?  As far as I know, DB2/400 is completely ANSI
compliant.  Please explain where it falls short.  Anything that is NOT
an ANSI standard is a vendor-specific extension, and as I've pointed
out, even the simplest of extensions vary wildly from one vendor to
another.

For example, the syntax for getting the first 5 rows from a given SELECT
statement is different for every major vendor.


> But the bottom line is, the iSeries community and IBM Rochester has to

> stop being so proprietary, needs to follow the essential tenets of Dr.

> Codd's Rules and act more and more truly relational.

As I just pointed out, anybody who points to Codd's rules as the
standard of whether a database is an RDBMS doesn't understand that NO
database completely adheres to the rules.  3, 5, 6 and 12 tend to
exclude every database one way or another.


> But as it is
> not seen as truly relational by those looking to buy and therefore
loses
> out to Oracle and SQLServer, I think everyone in the iSeries community

> better forget the dogma of the past and realize what the OS and its 
> legacy file structure is not; not relational but usually flat.

Once again, this is a mis-definition of the words relational and flat.
DB2/400 follows just about as many of Codd's rules as any other major
database and is just about as ANSI-compliant.  It may lack in
extensions, but that's always been an issue: do you stick with the
standards, or create extensions which then must be grandfathered into
your code when the real standards come out?  I'm willing to bet you that
not all syntaxes of getting the first rows of a SELECT will be
supported, which means some vendors will have to either remove
functionality or support non-standard syntax.

Joe

-- 
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.