Huh? I don't think that "Flat file" implies a particular location or storage medium. It also doesn't
imply contiguous sectors (or no modern operating system uses flat files). Neither are physical files
stored in flat files. The distinction is in how the operating system views the objects. IBM i is
object based, and every object type has various attributes. The others don't have an object model (at
the OS level) and a file is a file is file. It's up to the application to determine how to process
it. For IBM i, a physical file object is a relational database table. It isn't a flat file any more
than a table without any defined relations in one of the "real" RDBMS's is flat. I guess the hard
thing for Dave O. is that once you sign in to the i, you are inside the RDBMS. You can't really see
it from the outside like you can on the other platforms, except maybe with SST or DST.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dan Kimmel
Sent: Thursday, July 17, 2008 3:52 PM
To: Midrange Systems Technical Discussion
Subject: RE: Modernization and multi-member files
DB2400 tables are not stored in "flat files" they are stored in virtual
memory. Virtual memory is swapped to disk. A flat file implies
contiguous sectors on a disk. I dare you to show me a disk map from a
400 with contiguous sectors containing anything resembling a database
table.
When you view a table with DSPPFM there's a lot of work done under the
covers to build a contiguous column and row representation of the file.
What makes you think a CHAIN or a READPE are not using the same access
paths as an SQL Cursor?
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dave Odom
Sent: Wednesday, July 16, 2008 8:07 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Modernization and multi-member files
Mark,
Great detailed technical write up. Some things:
"Although some DB2 "purists" do not like to admit it, the IBM System/38
relational database that was built into CPF was shipped at least two
years before DB2 became available for mainframes (in June of 1983).
(IBM's SQL/DS was announced in 1981 and was not delivered until 1982.)
The IBM System/38 is widely accepted as the world's first commercially
available relational database product. (The IBM System/38 was announced
in 1978 and delivered in 1980.) These facts are well documented in the
literature."
"What you say is true, about who claimed to be first and who claimed to
be a relational database, BUT, it was NOT true the S/38 was accepted in
the market place, even inside IBM, as a true RDBMs and the first
commercial implementation. In IBM presentations, created by IBM and
given by me in the late '80s/early '90s, yes by the mainframe side,
SQL/DS was said to be the first commercially available RDBMS. Yes, I
spouted the dogma as well. So, often what you believe to be the gospel
is whatever you've been taught unless you see all the environments and
can think for yourself.
Yet you hold up "DB2 on the mainframe" as if it was the "definitive"
version DB2 -- yet on the mainframe, you must code JCL to create a
"stored procedure" and when the stored procedure gets invoked, it
submits a batch job -- how quaint is that?"
As far as most of the world is concerned, DB2 on the mainframe is just
that, the world standard for world-class RDBMS.
I wouldn't use wiki anything for a proof as its opinion based by its
users.
"which are carved out of (guess what?) FLAT FILES!" The same as
Physical "flat files" in
DB2/400; can't get away from the basic file structure for any platform
but the implementation and what can access... now there's the important
point.
(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.) Oh??? Seems to me, in the i,if you have security access to the
file you can get in and look at the data from all kinds of back doors;
some without SQL. Whereas, certainly on the mainframe, IF you have
security access to the base file at all, go ahead and look at the file;
it looks like junk. You can't read it, not EVEN WITH AN ISAM UTILITY.
Why? Because your not going through the engine and using SQL. Not so
on the i.
"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.)"
Well, you are built on flat files even though you like to call them
"objects". BUT, I will acknowledge that, to some extent, single level
storage is very nice and beneficial. However, not when it comes to
repairing a portion of a database; you got to go through the whole
database restore process unless something has changed I don't know
about. Not so in DB2 mainframe, you can restore parts as kit is NOT
single level storage. This also promotes you being able to backup or
restore some tables and tablespaces without bringing down the whole
database. Now, if I remember correctly you can do something like this
in DB2/400 if your database is segmented by ASP. If you do that, then
you've done the same sort of thing mainframe DB2 has done. But, that
sounds OK to me; makes them very similar in that one respect.
"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."
Makes good business sense at the time and would now if most of your
market share are small companies. But, if the i5 want's to play in the
big league (where I think it can play to a large extent), it needs to
grow up and offer another more sophisticated alternative like mainframe
DB2. Ahhhhh, now we may be getting at the real reason why the i5
doesn't implement DB2 like the real DB2s and why the i5 is not
considered by large shops...) IBM doesn't want Rochester and Santa
Teresa/Toronto to really compete. Just a thought.
"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."
Yes, but still seen as a relational-like DBMS, not relational where SQL
is the standard. And, promotes use of mixed data access types for
programs and not a standard programming database access methodology to
which all programmers must adhere. Standards and consistency are
important on the mainframe side; perhaps not in i shops.
"Some vendors and customers created database tables (files) in CPF or
OS/400 that are not truly "normalized" -- but anyone can create some
un-normalized tables in DB2 on the mainframe, or in DB2 on any other
platform, or in MS SQL Server, or Sybase, or Oracle, or any database
system you care to name. It's your choice.."
While technically possible, my arguments are based on how things are
actually done with the two DB2s. In most mainframe DB2 shops I've been
in that is RARELY done. Why, because you usually have a good DBA,
procedures, methodologies and discipline that prevent such a mess going
into production, UNLESS, it is a data warehouse implementation and then
there is another set of rules and procedures for good design. This is
very important in the mainframe world and many ORACLE shops doing
development because its too costly to the company to do otherwise.
Perhaps not so in i shops.
"I also know of many vendor applications packages on other platforms
that go to great lengths to "simulate" ISAM access by using stored
procedures and triggers, etc. -- if they had the kind of direct native
I/O access that we have on the System i, they would not need to resort
to those "tricks."
Yeah, but I'm discussing the real DB2 RDBMS and to some extent ORACLE.
"It is simply not the case that we are all just a bunch of OS/400 or
i5/OS "bigots"" Didn't say all.
" -- our version of DB2 is far more advanced than any other." Go say
that at IDUG or a major mainframe DB2 or ORACLE convention and see what
happens. Even present a paper on DB2/400 to try and convince them to
move to the i because you're "superior". I invite anyone to do that.
I'll pay to see that. If you get many that buy an i that was not
already intending to do so, I'll buy you several dinners and openly get
on here and say I was always wrong and you all were always right.
Take care,
Dave
Dave
--
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.
midrange.com
