On 22/11/2007, at 10:42 AM, Dave Odom wrote:
I"m sure you're a nice person
I wouldn't be quite so sure. Those who think I'm nice can be counted
on the fingers of one hand. The others ... well ...
Besides, which of the 14 (Shorter Oxford) definitions of nice do you
mean? Not all of them are complimentary and many are contradictory.
Personally, I like nice girls (definition 2) and I think definition 6
applies to me.
so no offense
Offence is in the eye (or ear) of the beholder. Life's too short to
worry about what someone else might find offensive. If someone has a
problem with something I say or do then that's their problem.
but your statements and attitude are typical of those that refuse
to move into a real RDBMS world, keep the i5 from being seen as
part of that world and a BIG reason why the i5 and its "DB2"/400 it
is not taken seriously nor even often considered by those
recommending systems to buy to those that write the checks.
Because of that perception of the i5, its "database" and its
supporter's attitudes about their "database machine" and in what
language to do serious application development, it will go the way
of OS/2 sooner rather than later. So,... the marketplace says
your statements are nonsense and too much head in the sand about
reality.
Just more nonsense. You saying DB2 UDB for System i is not a "real"
database is as silly as Steve Richter's cost comparisons with
pSeries. The current iSeries/System i implementation of DB2 is THE
most compliant (as in ANSI standard) implementation of SQL available.
You seem to think that in order for iSeries/System i to be taken
seriously we must throw away all existing applications and rewrite
them using nothing but SQL stored procedures. No embedded SQL in RPG
or COBOL or C. No I/O operation codes in RPG, COBOL, or C. In fact,
no RPG, COBOL, or C applications at all. IBM should simply drop
support for so-called "native I/O" and the compilers. If so then
that's just rubbish. The definition of a database does not REQUIRE
that SQL is the only DDL and DML. Nor does it REQUIRE that SQL be
available. SQL is just the currently preferred, so-called standard,
way of performing those functions.
I never said that YOU should use non-SQL access methods, nor did I
say that SQL access methods should not be used, nor did I say that
non-SQL access methods are better than SQL. I pointed out that HAVING
non-SQL access methods available is an advantage and does NOT make
the database non-relational. HAVING access statistics stored with the
data container does not make the database non-relational. It is
relational. The machine understands the relationships between tables
(or physical files), views (or logical files), referential integrity,
key constraints, etc. How the database is accessed has NO bearing on
whether the underlying implementation is relational.
Your problem seems to be with so-called legacy applications for which
the data has not been normalised and therefore you consider the
system non-relational. Your problem seems to be that because the
system allows such flat files to exist in the database it is not
relational. Is that a correct summation of your views? If not then
please state exactly what it is about DB2 UDB for iSeries that makes
it non-relational and how that compares to a database you DO consider
relational.
If so then it is a flawed view. I can create flat files using SQL on
any database you care to name. Accessing such a file with SQL is
problematic but not impossible given judicious use of substring and
cast operators. So, because I can create a flat file database on
Oracle do you consider Oracle non-relational or only the crappy flat
file database I created?
How can a system with a built-in database be derided as non-
relational by comparing it to other systems where the so-called
database is an add-on that uses stream files as its data repository?
Stating that DB2 UDB for iSeries is non-relational just because a
developer CAN create a flat database is rubbish.
As for comparing it to OS/2, well...
One of the major hurdles OS/2 had to recover from was support for
Win3.1 applications. Supporting a Win3.1 run-time was a good idea
but it had the side effect of creating a lack of compelling
applications. Why? Because most vendors were too lazy to take
advantage of the OS/2 native environment and settled for writing a
Win3.1 application (for the WinDOS market) and then said they
supported OS/2 because that same application ran under OS/2 (albeit
in a Win3.1 run-time). Perhaps the astute among you can see parallels
between this and PASE.
Further, IBM needed to actively MARKET OS/2 but they couldn't do that
without upsetting Micros~1. IBM had a PC business that was dependent
on being able to sell PCs with WinWhatever installed. I know Micros~1
threatened to increase the licence fee charged to IBM for WinDOS
unless they shutup about OS/2. More dirty tricks from the MS
marketing department (not that IBM is entirely clean in the dirty
tricks department either).
Anyone see a parallel conflict of interest in the PC division trying
to sell WinDOS and OS/2 when compared with a services organisation
trying to sell a hardware + OS package that doesn't require a lot of
services?
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 / \
--------------------------------------------------------------------
midrange.com
