there's a difference Jerry...the LUG doesn't offer that much....not to
mention that I'm not that into speaking to crowds. i was referring to
face-to-face conversations with the experts, not doing a presentation 8^)
Thanks,
Tommy Holden
From:
Jerry Adams <Jerry@xxxxxxxxxxxxxxx>
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
07/17/2008 12:33 PM
Subject:
RE: Modernization and multi-member files
And yet I can't convince you to come "down the street" to speak at the
LUG. Did I forget to mention that the speaker eats for free?
Jerry C. Adams
IBM System i Programmer/Analyst
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx
Sent: Thursday, July 17, 2008 11:23 AM
To: Midrange Systems Technical Discussion
Subject: Re: Modernization and multi-member files
you pay the attendance fees, air fare and expenses....i'll come and talk
to the "experts" about DB2/400...anyday
Thanks,
Tommy Holden
From:
"Dave Odom" <Dave.Odom@xxxxxxxxxxxx>
To:
<midrange-l@xxxxxxxxxxxx>
Date:
07/16/2008 08:06 PM
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.
--
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
