Re: Modernization and multi-member files

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.