Re: Question about UDB on iSeries -- MIDRANGE-L

Dave,   I'm interested in your views on the subject.

particularly the comment:
"from my point of view, it seems that most iSeries shops that fool
with DB2/400 do so from the traditional S/38, AS/400 legacy point of
view spoken about earlier and that is not a wise
use of a resource."

I think I know what you mean by this (using DDS and traditional HHL
data access methods?)

Throwing out the legacy factor (clean slate, do it the way you want to
do it) In your experience, what types of things do other RDBMs do
better, easier or faster that DB2/400 can't do?

And the inverse, what, if anything, does having the database so deeply
imbedded in the OS buy you that leaves other RDBMs lacking?

Thanks,

Rick

On Wed, 01 Dec 2004 13:12:49 -0700, Dave Odom <dave.odom@xxxxxxxxxxxx> wrote:
> John,
> 
> You wrote:
> 
> >>> Please keep in mind that I know **ZERO** about the iSeries and UDB.
> We are considering a conversion from z/OS on zSeries to i5OS on
> iSeries..."  <<<
> 
> Well, I thought I'd through in my two cents worth since I've been
> involved in the following areas of work using the real DB2 RDBMs built
> for VM, VSE, and MVS, and the version called DB2/2 on the OS/2 operating
> system, and the pseudo-DB2 on the iSeries as well as another highly used
> RDBMs, called Oracle:  System Programming, DBA, DA, consultant to
> developers of applications using those RBDMS and Director of a
> development shop creating multi-terabyte data warehouses using both
> DB2/MVS and Oracle.  I even go back to the days of the S/38 and  S/34.
> 
> I don't say this to impress but I just didn't see any responses from
> folks that have worked with DB2 in the mainframe environment nor other
> mid-range industry-accepted RDBMs used on a wide scale, like Oracle.  It
> seems like most of the responses are from folks that are prejudiced to
> the iSeries and perhaps have limited knowledge of the real DB2.  Don't
> get me wrong, I think the iSeries is a find operating system and is
> pretty rock solid, BUT the reality is, it and DB2 are not usually used
> in the same environments and for the same types of applications and
> reasons as the mainframe.  There are reasons why mainframe shops and
> mid-range shops using RDMBs like DB2 and Oracle went with those engines
> and platforms and not with the iSeries.  If you understand that, you can
> understand why there are not many non-OEM tools for the iSeries vs. the
> mainframe and other mid-range boxes like those that run Oracle.
> 
> In addition, most iSeries shops I know of, since they have been
> influenced by Rochester and tend to move only in that environment and
> have done so for decades, don't have an unbiased view of how different
> the DB2/400 implementation is from the rest of IBM and why that is not
> necessarily good.   And, from my point of view, it seems that most
> iSeries shops that fool with DB2/400 do so from the traditional S/38,
> AS/400 legacy point of view spoken about earlier and that is not a wise
> use of a resource.  IBM is also part of the problem because of the way
> they implemented DB2 on the AS/400 because of the operating system
> architecture.  One of the questions that should be answered is, "but
> with all that, can DB2/400 be used wisely and in keeping with the tenets
> usually found in the rest of the RDBMs world and why is that important
> to my business?"  That question should also peak the interest of the
> lagecy AS/400/iSeries technical folks as well especially if they see
> their world shrinking relative to the expansion of other worlds that use
> RDBMs.  Let me know if you'd like to explore this further.
> 
> Take care,
> 
> Dave
> 
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
>