RE: Modernization and multi-member files

Terrence,

In my opinion, this is due to several factors. These are general
observations and not meant to be all-inclsive.
1. "Legacy" and by legacy I mean mature i5/OS green screen applications
designed in the dawn of time. The assumption is applications manage
access to the data, and the integrity checking was performed at the
application level. The cost of refactoring a working system to "make the
database clean" could be prohibitive.
2. Related to 1, in that when native RI and transactions came to the
system, they were not implemented by the vendor. In many cases, vendors
use CASE tools to generate the application and data relationships, and
continued to keep RI and "transactions" in the code, not the database.
3. The tendency of i5/OS users to not need a DBA leads to programmers
creating databases without worrying about normalization or "correct"
design.

All these issues are equally attributable to all the major RDBMS - DB2,
Oracle, SQL Server, etc. The RDBMS itself does not mandate the use of
transactions, RI, or other things that make a database robust and
integral. In that case the RDBMS is used in a non-relational manner.

My point and opinion is we are fundamentally back to discipline, design,
and implementation of the database. Probably moreso than other
platforms, our have many vendors "stuck in the past" in terms of letting
the database manage itself - which transactions, constraints, foreign
keys, etc. all enable. The "other platforms" went through the expense of
purchasing a database, so they hire the skill to design and manage it.
Our database is built in and offers many automatic management tools that
largely eliminate the need for a DBA. I would go as far to say the
database management on the I is much more "organic" than on other
platforms.

Inhouse systems are not immune; my experience is working with vendor
packages on the I, and that's what I've seen.

The three main arguments Dave Odom has are:
1. Since the other major RDBMS only use SQL for data access, the I is
seen as strange as allowing "native", or as another poster said,
"assembler" access to the data. This is generally not an issue because
the I conforms to Codd's 12th rule that states all data access go
through the same underlying mechanisms; i.e. the non-subversion rule.
Just because an application does not use SQL doesn't mean it doesn't
take advantage of RDB capabilities.
2. In general, databases on the I either are not architected to normal
forms and/or do not fully use the capabilities of RDBMS; i.e.
transactions, RI, foreign keys. In this I agree; see my earlier comments
on vendor code. Probably moreso than other platforms the I relies on
vendor software. Many vendors and inhouse apps were not refactored to
move integrity out of the application and into the database. This leads
to "smart application, dumb database" when it should be the other way
round.
3. The actual DB implementation does not match other DB platforms. For
example, the I implements partitioning as multimember files, the same as
many users have done for native access on the platform. SQL Server
stores partitions in different files. To me this is another non-issue.
If I use approved database access mechanisms (SQL and row level access
on the I) to get to the data (Codd's non-subversion rule again) it
doesn't matter how the data is actually stored. This is mentioned in
Codd's rule #8.

I think Dave has a lot of knowledge to help us with designing good
relational databases that take advantage of all the modern RDB
techniques; it just hidden behind an attitude that the I is the ugly
duckling in the database family. That developers do not take advantage
of the database's capabilities is not the database's fault.

JMHO,
Loyd

Loyd Goodbar
Business Systems
BorgWarner Shared Services
662-473-5713
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Terrence Enger
Sent: Thursday, July 17, 2008 9:32 AM
To: Midrange Systems Technical Discussion
Subject: Re: Modernization and multi-member files

Greetings,

I am almost scared to contribute again to a thread which has generated
so much heat. No doubt I shall be sorry. Still, here goes ...

Much of the intervening discussion seems to me to be talking about
issues which are, viewed from 50,000 feet, implementation details.
Nowhere in the discussion have I seen any mention of what I think is the
one important item which makes DB2/400 the odd-man-out in the DB2
family:
DB2/400 exposes uncommitted changes to all users of the database.

Comments? (I am going off now to look for my asbestos underwear.)