|
I am currently managing a corporate IS department that uses the iSeries for its primary business application. However, my background is much more rooted in Sybase, SQL Server and in particular Oracle. My experience with DB2/400 is that it now competes feature for feature with the other databases, but this may be a a recent development. I believe that IBM has been playing catch up with the SQL functions of DB2/400 compared to the competition, including its own UDB product, but is just about there now with v5r2 and beyond. I have been pretty successful at introducing new techniques to my department by assuming since Oracle has it, there is probably a similar feature in DB2/400. We discovered SQL triggers, SQL views and the SQL tools in Operations Navigator that way. I have yet to be disappointed to find that there was not a feature I was looking for. I will admit to some misgivings about the proprietary nature of the hardware and OS compared to the Oracle world I am used to, but I have no complaints about the robustness of the software, including the database. Jim Reinardy -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta Sent: Wednesday, December 01, 2004 4:35 PM To: 'Midrange Systems Technical Discussion' Subject: RE: Question about UDB on iSeries > From: Dave Odom > > UT 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. I'm interested in this statement! Do mainframes not do CICS-type applications anymore? Because for the life of me I can't discern the difference between CICS-based order entry in COBOL and green-screen order entry in RPG IV (or NEP-MRT order entry in RPG II, for that matter). If your contention is that mainframes are used more for data warehousing on multi-terabyte databases, then I guess you're probably right there. The iSeries is only just beginning to target that environment, although from what I understand EVIs and the like make the iSeries a pretty nice platform for those things. > 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. What are the reasons? > 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. Actually, we didn't even know we were running DB2 until we were told so by IBM. Until then we were just running OS/400 (or CPF). We just knew we had the fastest database on the planet for the type of navigational access that best describes business logic. > 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?" Can you provide these tenets? Or better yet point out where they are published. Can I see them online somewhere? Download them? Joe -- 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.