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

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












As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.