|
Charles, You wrote: "First you say "that the iSeries OS is not a true RDBMS." Then you say "if you want the normal concepts, features and functions of standard SQL and DB2 to work as they do in the other true RDBMSs, then do as they do; re-architect your databases and applications in DB2/400 like the rest" If the iSeries wasn't a true RDBMS, then you couldn't implement a RDB and its corresponding applications on the iSeries. I grant you, many legacy DBs on the iSeries don't follow RDB standards. But that doesn't stop the iSeries from being a true RDBMS. I've said it before, it's just as easy to implement a non-RDB and applications on Oracle and SQL server is it is on the iSeries." Yep, I say what I said because the iSeries is an RDBMS look-alike, like MS Access, but closer to the real thing that MS Access. The OS/400 has been extended to provide RDBMS-like capabilities. IBM had to make it look like the other implementations of DB2 by extending the basic S/38-OS/400 architecture to have DB2-like features and allow you to access data both ways. That's NOT allowed in a true RDBMS on the market. For instance, DB2 on MVS uses the native VSAM file concepts to store its data BUT its not truly VSAM because you can't access DB2 data using VSAM utilities unlike what you can do on the iSeries. In the real DB2 and Oracle worlds, either your creating and accessing TABLES, VIEWS, etc. using SQL or your not. You can't access DB2 and Oracle tables using a READ or a CHAIN, etc. If you want to use READS, you create files under whatever the native file structures is and in that case you're not using an RDBMS. And, to your point about creating a non-RDB on Oracle, don't see how you come to that conclusion since creating a RDB in a real RDBMS is, by definition, an RDB even though it may be VERY POORLY architected like some sort of flat-file or multi-member database. You are right, however, MOST iSeries legacy flat-file and multi-member data file DBs don't follow RDB architectural standards, even though they could given the RDBMS look-alike functions implemented in DB2 on the iSeries. For those that wish to make their applications look and act like the rest of the DB2s and Oracles, you have to embrace the real relational world in the way you think, act, speak, architect, etc. It will be hard. I was for all the folks that had legacy apps under MVS, VM, VSE, UNIX, etc. In the real RDBMS world you won't EVER here them referred to their native file structures like PF and LF, multiple member files or what have you. One of the basic advantages of a real RDBMS is you don't EVER worry, nor talk about the native file structure. Folks that moved to the real RDBMs made the leap(wow, its been about 15 years), although with lots of teeth gnashing and speaking about the "good old days" of legacy, non-relational application development. So too must the iSeries world. They have to stop trying VERY HARD to keep their data and application architecture looking like it was before but using SQL where it suits them and speaking in RDBMS terms on occasion. I'll say it again,.. the quicker the iSeries world truly moves to thinking, speaking, architecting and acting like they are working in a real RDBMS, the quicker IBM can actually architect the OS and DB2/400 to where it IS a true DB2. Also, it will be quicker and easier for the rest of the IT world to consider the iSeries something to be considered when they are making a buying choice between Oracle under Windoz or some flavor of Unix or DB2 UDB under AIX, VM, VSE or MVS. The more the iSeries world stays in their esoteric (perceived as proprietary) world, the more they doom their platform AND their careers to extinction. And I don't want that to happen. Take care, Dave
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.