× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I couldn't agree more. 

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of D.W.
Sent: Tuesday, March 08, 2005 7:15 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Logical File or OPNQRYF or anyother way ? -
LegacyiSeriesFlatFiles

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.


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



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.