I have previously refuted most of your ridiculous statements in
earlier appends on this subject so I won't reiterate. Additional
corrections follow:
On 17/07/2008, at 11:07 AM, Dave Odom wrote:
"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.
Ah, no. SQL/DS may have been touted as the first commercially
available SQL "implementation" but as far as RDBMS it was beaten by CPF.
System R was the first implementation of SQL but that never made it
out of the lab.
I suspect, if you can find them, the original presentations will say
something like:
"SQL/DS was IBM's first commercial implementation of a database
management system for the mainframe". In other words, very carefully
worded to ignore the work done at Rochester. The rest of IBM has
always had a jaundiced view of Rochester and especially the System/
38. I think they were frightened and we are living with that legacy
today. It's no wonder the the current incarnation of Rochester's
ideas have such a hard time reaching acceptance.
Just because a heap of people believe something doesn't make it true--
at least not in this Universe. Witness the plethora of otherwise
apparently sensible people subscribing to so-called "intelligent
design".
You say other DB2, Oracle, and (name your chosen RDBMS here) state
that DB2 for (our system) is not relational, that it allows "back-
door" access to the data, etc. etc. etc. but that really just shows
the ignorance of those other systems people. They don't understand
how the database on our system works, they don't want to learn, so
they disregard it. Doesn't make it wrong, non-relational, nor even
non-DB2. Just different--but only if you choose to use it
differently. If you choose to use it like DB2 on other system you can.
Well, you are built on flat files even though you like to call them
"objects".
Rubbish. While it is possible to consider program-described files as
"flat" they are really single column tables. Externally-described
files are tables in exactly the same sense that SQL uses "tables".
The Database Manager in the OS understands the structure of the rows
in the tables AND how those tables relate to each other.
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.
Given the poor quality of most of your statements here I suspect it's
"something you don't know about" but you have always been able to
restore an individual object (i.e. table) on OS/400.
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.
You can do that on OS/400 too (except for the tablespace thing 'cause
we don't have that--not a "short-coming" either but rather simply not
needed).
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
As an Amazon Associate we earn from qualifying purchases.