|
See my response below...
Dave Odom wrote: 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.
Dave -
Definitions may differ, but _my_ definition of a "Flat" file is one that has no external field definitions. A "Flat" file can be created easily by using CRTPF with a record length specified instead of a DDS source member.
In a given AS/400 - iSeries - i5 system, depending on the file structures and their relationships, I would be more inclined to call a given DB2/400 file a "non-relational" file rather than a "Flat" file...
And, as others have mentioned, it is possible to build a non-relational database in any SQL database...
IMO, A "Flat" file doesn't have external field definitions other than one large field that contains all of the data.
When using "Flat" files in programs, you generally use program-described files with F & I specs in RPG or FD's in copy books for COBOL to describe the fields in the file.
As most of us know IBM midrangers know (or _should_ know), the System/38 was born of what was originally known as the "Future System" project within IBM's mainframe division.
The "Future System" project began _before_ Dr. Codd first proposed his relational database rules in 1970, and when Rochester got hold of it the System/38 developers put more functionality (usability-wise) into the "no-name" System/38 database than existed in any commercial IBM mainframe database at the time (circa 1978).
I'd like to see a one of the IBM database guys weigh in here to address the 12 design points of Codd's model and how DB2/400 measures up, particularly in light of this quote from an IBM DB2 document.
From http://www-128.ibm.com/developerworks/db2/library/techarticle/0301jones/0301jones.html
<Snip>
A brief history of DB2
A series of research projects have been a steady source of technology for the DB2 family since the beginning:
The System R project resulted in the first IBM implementation of the relational model. A project called ARIES delivered row-level locking technology used throughout the database industry today.
Cost-based query optimization has been an area of intense effort and innovation ever since the System R days. The R Star project extended the relational model to distributed system environments.
The Starburst project focused on making the relational model extensible to handle new forms of information and new kinds of optimization strategies.
The Garlic project brought an emphasis on data federation, allowing data in diverse systems, not just DB2 systems, to be managed together.
Most recently, a technical preview based on DB2 has demonstrated the integration of information from Web services and the use of XQuery as an additional and powerful query language for managing XML content.
The first implementation of relational technologies from the initial System R project was the database integrated into the System/38 server in 1980.
In 1982, the SQL/DSTM product was delivered on the mainframe operating systems VM and VSE, also based on System R.
DB2, formally called DATABASE 2, was born in 1983 on MVSTM.
The database manager in OS/2® Extended Edition in 1987 was the first relational database on distributed systems.
SQL/400® for the new AS/400® server emerged in 1988.
New DB2 editions were delivered on AIX® (1993), HP-UX and Solaris (1994), Windows® (1995), and Linux (1999).
</Snip>
In addition, read Wayne O. Evans account of the System/38 project here: http://www.woevans.com/CPFDesign.pdf
Regards, Steve Landess Austin, Texas (512) 423-0935
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.