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.

This thread ...

Replies:

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.