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



Dave,

That sounds like a lot of theory.  But can you name one actual difference 
that a developer might notice?

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Dave Odom" <Dave.Odom@xxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
03/07/2005 06:27 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
<midrange-l@xxxxxxxxxxxx>
cc

Subject
Logical File or OPNQRYF or anyother way ? - Legacy iSeries      Flat Files






Vern,

As to "legacy AS/400 flat-file architecture"...

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.

Something else you said:

"There is essentially no difference between the database on the i5 and
that on the 38 - except for some things like triggers and referential
integrity that were added more recently, at the time this "no-name"
relational database got the same name as its IBM brethren. But the lack
of those items did not make the database into flat-files."

I agree with you, there is little difference in the data base form from
the S/38 days to the iSeries days(don't know about the i5 as yet but I
suspect it is the same old database.  If you say so, I'll concede). 
But, alas, from the S/38 to now, the S/38 and its follow-ons are not
truly relational and most of the files found thereon are generated as
flat files although some are using what they have of a DB2-type engine. 
Oh, my, I have just committed blasphemy, at least per Rochester and
those that follow their dogma. 

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. 

I found out the hard way when I learned what a real relational system
was like on the other IBM and non-IBM occurrences of relational.   For
one, it does not meet the significant tenets of Dr. Ted Codd, the guy
that invented relational for IBM years ago.  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. 

It is true there is a DB2 flavor on the iSeries.  This done so as to be
in lock step with the rest of the IBM platforms.  But its does not
appear to be a true DB2 like MVS, VM, VSE or UDB.  It's a start, but
there is a way to go before the relational world will agree with
Rochester's assertions.  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. 

I think IBM Rochester sees this to some extent which is why they are
pushing customers to move toward using DB2 on the iSeries, converting
from flat-file or other DDS structures to relational structures created
with DDL.    IBM has even created small seminars and other activities to
help the legacy AS/400 crowd make the move.   It is true that a
relational architecture is not the end-all-be-all for everyone but that
architecture is WIDELY popular with MUCH of the IT shops out there. 
True relational also has many advantages by allowing for better
application development, security, data integrity, etc. 
 
Don't get me wrong, I think the iSeries has great POTENTIAL for the
future, especially with the capability to finally have LPARS, be able to
run Linux and AIX and thereby make it attractive to that world out there
that likes UNIX-like environments.  I'm not saying that UNIX is the
end-all-be-all either... it's just a fact that it is seen that way by
many businesses.   The iSeries allowing Linux and AIX can be a two-edged
sword, however, as that new architecture could, on the one hand breath
new life into the iSeries and make it attractive, from the standpoint of
multiple architectures and capabilities as well as economically.  On the
other hand it could provide an "easing" transition to the pSeries, other
non-IBM UNIX flavors or, perish the thought, PC's for large mission
critical applications and databases. 

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.   And I say all
this as a friend and supporter of the iSeries and it's future.  The more
it can compete with the UNIX and Intel boxes the better.   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. 

Take care,

Dave



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

Replies:

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.