Re: Modernization and multi-member files

It seems to me that this debate (i DB2 vs. all other RDBMS) is really
about peer pressure. If you believe what IDUG and folks think, you
have one belief system. If you believe what the majority *on this
list* believe, you have a different belief system. Other RDBMS' 'lock'
one into one access method; i DB2 allows that and others. That's the
major difference. Peer pressure...it's why I started smoking. Powerful
stuff. :) Took me 30 years to quit.

On Thu, Jul 17, 2008 at 9:20 AM, Wilt, Charles <WiltC@xxxxxxxxxx> wrote:

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Jeff Crosby
Sent: Thursday, July 17, 2008 7:55 AM
To: Midrange Systems Technical Discussion
Subject: 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.

Nope, you've got it. Basically on any other platform ( and in particular Windows), the "database" is
just bytes stored in a stream file just like any other object on the system.

With the right OS permissions, you can open the file and read/write to it with any program you want.
Of course the format is pretty complex, but if you're smart enough it can be done.

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.

Now Oracle in particular supports some alternate configurations where disk partitions are used RAW,
ie. unformatted by the OS, and the RDBMS application handles the file I/O directly to disk without
going through the OS.

In this case, you couldn't just open the DB file since the OS isn't aware of it unless you used a
custom program that accessed the disk directly without going through the OS. Think old style DOS disk
editors used for recovery purposes.

Actually, IBM i does have a similar interface that I'm pretty sure doesn't go through the DB. Service
tools includes a hex editor that allows you to edit most (all?) objects on the system directly. And
before Dave jumps in, this isn't the same as the hole describe above since the service tools have
their own set of user IDs and authorities. A standard OS user with authority to the file would not be
able to use service tools.

Even QSECOFR may not know the service tool QSECOFR password off hand, though he'd probably have
authority to ask for the sealed envelope containing it.


Charles




This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.
--
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.