|
Rob, That's what I was getting at. you did a better job of explaining what I thought he meant. My other questions still stand though. Rick On Wed, 1 Dec 2004 15:52:17 -0500, rob@xxxxxxxxx <rob@xxxxxxxxx> wrote: > Perhaps he's talking about the iSeries community, by-and-large, ignoring > such things as: > - journalling > - referential constraints > - check constraints > - identity columns > - triggers > - user defined functions > > Rob Berendt > -- > Group Dekko Services, LLC > Dept 01.073 > PO Box 2000 > Dock 108 > 6928N 400E > Kendallville, IN 46755 > http://www.dekko.com > > rick baird <rick.baird@xxxxxxxxx> > Sent by: midrange-l-bounces@xxxxxxxxxxxx > 12/01/2004 03:40 PM > Please respond to > Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> > > To > Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> > cc > > Subject > Re: Question about UDB on iSeries > > > > > 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. > > > > > -- > > > 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. > > > -- > > > 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. > >
As an Amazon Associate we earn from qualifying purchases.
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.