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



Mark S. Waterbury wrote:
All of the other DB2s you mentioned (for AIX, for OS/2, for Windows, etc.) are all based on a common code base that is written in C, where the DB2 database exists or resides within one or more "table spaces" which are carved out of (guess what?) FLAT FILES! (That's the part that is the security concern -- if you could directly access those FLAT FILES, you would be bypassing all of the built-in security and integrity etc. of the database. But that's NOTHING LIKE how DB2/400 works -- at all.)

You mention "single level storage" in some of your posts. All DB2/400 tables and views (physical and logical files) are implemented as various MI objects (data spaces, data space indexes, cursors, etc.) that reside in the single level storage -- so the pages of these objects can reside anywhere on any DASD volume within the containing ASP. There is no need to worry about or allocate 'table space" or worry about what DASD volumes the table space must reside on -- OS/400 or i5/OS takes care of all of that automatically, as part of single-level storage. (NOTE: This is a FAR CRY from a database built on top of "flat files.)

I think the ol' light bulb just went on in Mr. Obvious head here. (<-- for all you Bob and Tom fans.)

I was always aware that the RDB on platforms other than the i were something extra, an addon above and beyond the OS. Are you saying these other RDBs are nothing more than flat files with software that "allows" those flat files to be used as an RDB? And that one could access those flat files completely outside of the RDB? I must be missing something, because this sounds like smoke and mirrors. And companies actually run their business on stuff like that?

If true, no wonder Dave is so adamant that SQL be the only access method for the RDB. It's because you can completely bypass the RDB, yet still access the data. The RDB and the data are 2 different things. I begin to see why other systems need fulltime DBAs for data integrity. The RDB has no way to insure integrity on it's own. I *have* to be misunderstanding something, for that would be anathema.

System/38 CPF was the first system to implement the idea that all "files" are really database tables (and views), and those are just another object type that resides in the single level storage. This is the essence of the MI architecture and what we know as CPF, OS/400, and i5/OS.

The folks in Rochester realized when they created CPF and its built-in database, that most of their existing customers were coming from a System/3, System/32 or System/34 background, and they were used to "flat files" and using languages like COBOL or RPG. So, they did something very clever -- they provided a way to access the "database" via "native" I/O statements (READ, SETLL, READE, etc.) which made the transition much easier. This in no way undermines the integrity of the database, because, at the MI level, ALL access, whether through SQL, or through "native" I/O statements, must go through the exact same database access routines in the operating system, and those are using the built-in MI objects (data spaces, data space indexes, journals, journal receivers, and cursors, etc.) with special MI instructions that work with those object types.
So the i RDB has only a single access to the data itself, via MI routines. SQL and HLL RLA both access the RDB via these MI routines. You can't screw it up by going around the RDB to get at the data like you can on other systems. Am I understanding this right?

I love these Rochester people more every day.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.