 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups Database Servers DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybaseDesktop Databases FileMakerFoxProMS AccessParadoxGeneral General DB TopicsDatabase TheoryRelated Topics Java Development.NET DevelopmentVB DevelopmentMore Topics ... |
Database Forum / DB2 Topics / February 2008db2 to oracle migration
are most IT shops migrating from db2 to oracle? > are most IT shops migrating from db2 to oracle? No, why would they?  SignatureJeroen > > are most IT shops migrating from db2 to oracle? > > No, why would they? > > -- > Jeroen No...i thought people always moved from a bad a product to a good one. So on that basis, why would anyone on their right mind would move from DB2 to Oracle ?!?! Cheers ! Roger >>> are most IT shops migrating from db2 to oracle? >> No, why would they? [quoted text clipped - 9 lines] > > Roger Forget the products for a moment because we all know that the product that most people think the best is the one they know the best. Lets deal with an economic reality. The number of potential 20 year olds moving into the workforce with DB2 classes under their belt is zero. How about 30 year olds? You get the point. If I am running an organization I have far more important considerations than whether product A is faster or cheaper than product B. I have considerations about the size of the pool from which I can choose my future employees. DB2 might be the best product since silicon was discovered but if I can't find people to run my data center in 10 years then I don't want it. When the current generation of DB2 experts retire ... the quality of product will be of little import. SignatureDaniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond) > The number of potential 20 year olds moving into the workforce with > DB2 classes under their belt is zero. How about 30 year olds? You > get the point. While it may be true that there are more folks who have Oracle skills, there are also a lot with DB2 skills. So yes, skills and staffing is surely a consideration - but by no means a criteria to exclude DB2 as you claim it because there is no reason for exclusion on these grounds. SignatureKnut Stolze DB2 z/OS Utilities Development IBM Germany >> The number of potential 20 year olds moving into the workforce with >> DB2 classes under their belt is zero. How about 30 year olds? You [quoted text clipped - 4 lines] > consideration - but by no means a criteria to exclude DB2 as you claim it > because there is no reason for exclusion on these grounds. It's not the quantity I referred to ... it is their age. SignatureDaniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond) > When the current generation of DB2 experts retire ... the quality of > product will be of little import. Daniel ... with all respect, you make it sound like DB2 is a dinosaur and it is a foregone conclusion that it is extinct ... or will be within 10 years. Let me assure you and everyone that reads this newsgroup that I visit with customers all the time and nothing could be further from the truth. Not only are there some major corporations that are heavily invested in DB2 LUW, they continue to invest heavily in new applications. In some cases, DB2 LUW is their standard and other relational databases exist in the shop. In other cases, DB2 LUW is their standard to the exclusion of other competitors. On top of that, new customers continue to purchase DB2 and the product continues to be enhanced. In none of these situations is there ever a concern that there is only a limited pool of DB2 skills in the "current generation". In fact, I have seen DB2 skills continue to be picked up by DBAs and Sysadmins that are both young and old. I have also seen cases where DB2 skills already exist in very young people in their 20s/30s. There are examples up the kazoo in business where there are multiple competitors or competitive products that continue as viable products in that line of business indefinitely ... and one of the two leaders doesn't die. Relational databases are just one example. I don't think I have to list others ... I think you can figure that out. Larry E. >> When the current generation of DB2 experts retire ... the quality of >> product will be of little import. > > Daniel ... with all respect, you make it sound like DB2 is a dinosaur > and it is a foregone conclusion that it is extinct ... Not at all. We are the dinosaurs. We are the gray-hair/no-hair crowd. The demographic is well documented. DB2 won't die off ... but we will. SignatureDaniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond) > Not at all. We are the dinosaurs. We are the gray-hair/no-hair crowd. > The demographic is well documented. DB2 won't die off ... but we will. There "might be" a small modicum of truth if you were talking about DB2 for z/OS, but it is patently false for DB2 for Linux, UNIX, Windows. But there are an amazing number of DB2 for z/OS DBA's being trained in India these days. >> Not at all. We are the dinosaurs. We are the gray-hair/no-hair crowd. >> The demographic is well documented. DB2 won't die off ... but we will. [quoted text clipped - 4 lines] > But there are an amazing number of DB2 for z/OS DBA's being trained in > India these days. Who would want to use z/OS unless you want to pay 10 times as much for 1 tenth of performance > Who would want to use z/OS unless you want to pay 10 times as much for 1 > tenth of performance If you have a mission critical application that you want to bet your company on. That is why many banks and financial institutions run it. Besides, it is not anywhere near 10 times the cost, if total cost of ownership is calculated. When I look at the system configurations on www.tcp.org they are not exactly pocket change. >> Who would want to use z/OS unless you want to pay 10 times as much for 1 >> tenth of performance > > If you have a mission critical application that you want to bet your > company on. That is why many banks and financial institutions run it. I hope you are not telling me z/OS is the only platform that is suitable for mission critical apps. What are the largest stock exchange companies running these days? Mostly non-mainframe. > Besides, it is not anywhere near 10 times the cost, if total cost of > ownership is calculated. When I look at the system configurations on > www.tcp.org they are not exactly pocket change. Ok, let's talk about TCO. How much does a z 890 or 990 cost these days? How much are z/OS and other software license? What is the power consumption of a mainframe and how much space it takes up. It still doesn't have a tpc benchmark. > I hope you are not telling me z/OS is the only platform that is suitable > for mission critical apps. What are the largest stock exchange companies > running these days? Mostly non-mainframe. I didn't say a mission critical application cannot run on UNIX/Linux. But there are a lot of companies who have chosen to run their applications on the mainframe. Those applications you speak of that run on UNIX/Linux usually have some sort of redundant/parallel processing in case of hardware or system failure. These feature are not cheap. > Ok, let's talk about TCO. How much does a z 890 or 990 cost these days? > How much are z/OS and other software license? What is the power > consumption of a mainframe and how much space it takes up. It still > doesn't have a tpc benchmark. It is a lot cheaper than it used to be. For example the machines are now air cooled instead of water cooled (a lot of PC game enthusiasts I know have water cooled PC's these days, which is rather an iron switch form the old days of big iron). Personally, having worked on DB2 mainframe in the early years, I work almost exclusively with DB2 for Linux, UNIX, and Windows (mostly Linux). But I am not going to say that people who still use the mainframe are stupid. >> I hope you are not telling me z/OS is the only platform that is suitable >> for mission critical apps. What are the largest stock exchange companies [quoted text clipped - 3 lines] > there are a lot of companies who have chosen to run their applications on > the mainframe. Then I am not sure why you brought up mission critical apps, if it is a non-issue on either platform. Yep, there are "a lot" of companies running z/OS. They mainly fall into 2 catagories: ones that cannot affort to migrate the applications and ones with decision makers still dwelling in the past. > Those applications you speak of that run on UNIX/Linux usually have some > sort of redundant/parallel processing in case of hardware or system > failure. These feature are not cheap. Again, I am not sure why this would be a factor. Is redundancy not applicable for mainframe? Parallel processing has nothing to do with system failure. >> Ok, let's talk about TCO. How much does a z 890 or 990 cost these days? >> How much are z/OS and other software license? What is the power [quoted text clipped - 5 lines] > have water cooled PC's these days, which is rather an iron switch form the > old days of big iron). Yes, it is cheaper now, so are other platforms. Relatively speakin, mainframes are still much more costly. We are talking about business machines not game PCs. > Personally, having worked on DB2 mainframe in the early years, I work > almost exclusively with DB2 for Linux, UNIX, and Windows (mostly Linux). > But I am not going to say that people who still use the mainframe are > stupid. It is just a matter of choice. There are people love to buy expensive antique cars. The only difference is that the value of a classic car may go up. > Then I am not sure why you brought up mission critical apps, if it is a > non-issue on either platform. Yep, there are "a lot" of companies running > z/OS. They mainly fall into 2 catagories: ones that cannot affort to > migrate the applications and ones with decision makers still dwelling in > the past. It is more reliable to run an applicaiton on DB2 for z/OS than on LUW unless you set up some sort of failover and redundancy. The z/OS operating system and hardware are still more reliable than LUW. >> Then I am not sure why you brought up mission critical apps, if it is a >> non-issue on either platform. Yep, there are "a lot" of companies running [quoted text clipped - 5 lines] > unless you set up some sort of failover and redundancy. The z/OS operating > system and hardware are still more reliable than LUW. There is really no data to support that. Any system can fail, mostly due to human factor. I have seen UNIX runnning for many years without issues. I have also seen z/OS locked up and crawling frequently. Other times I had different experience. The fact is that LUW is sufficiently reliable, even loaded with variety of applications from different vendors. > There is really no data to support that. Any system can fail, mostly due > to human factor. I have seen UNIX runnning for many years without issues. > I have also seen z/OS locked up and crawling frequently. Other times I had > different experience. The fact is that LUW is sufficiently reliable, even > loaded with variety of applications from different vendors. DB2 for LUW is very reliable. I don't think that a Linux/UNIX OS or hardware platform is as reliable as z/OS. >> There is really no data to support that. Any system can fail, mostly due >> to human factor. I have seen UNIX runnning for many years without issues. [quoted text clipped - 4 lines] > DB2 for LUW is very reliable. I don't think that a Linux/UNIX OS or > hardware platform is as reliable as z/OS. As I said, where is the data to suport that assumption. System reliability depends on many variables. If z/OS is more reliable, why are most mission critical apps running on UNIX? > As I said, where is the data to suport that assumption. System reliability > depends on many variables. If z/OS is more reliable, why are most mission > critical apps running on UNIX? Why are you so obsessed about this? If you own a company, you can choose to use LUW. Others have chosen to use z/OS. Get over it. Personally, I prefer to use LUW, but I think that both DB2 and Oracle have a little ways to go to be able to guarantee continuous availability. They both have software that attempts to do that, but the high availability software itself (especially the failover software) still has some issues that need to be worked out. >> As I said, where is the data to suport that assumption. System >> reliability depends on many variables. If z/OS is more reliable, why are >> most mission critical apps running on UNIX? > > Why are you so obsessed about this? If you own a company, you can choose > to use LUW. Others have chosen to use z/OS. Get over it. I do not object to whatever choice any one makes, but I do like to get the facts straight. Most people like to make informed decisions. > I do not object to whatever choice any one makes, but I do like to get the > facts straight. Most people like to make informed decisions. I think that when people decide to make a decision like that, it is disingenuous for any of us to presuppose people don't know that facts. Also, there are a lot of other factors (facts) that we may not be aware of. >> I do not object to whatever choice any one makes, but I do like to get >> the facts straight. Most people like to make informed decisions. [quoted text clipped - 3 lines] > Also, there are a lot of other factors (facts) that we may not be aware > of. That would make every one of us disingenuous by posting facts here. > That would make every one of us disingenuous by posting facts here. You may know some facts, but you don't know all of them. Each company has its own reasons for doing things. >> That would make every one of us disingenuous by posting facts here. > > You may know some facts, but you don't know all of them. Each company has > its own reasons for doing things. I don't disagree with that. >>>There is really no data to support that. Any system can fail, mostly due >>>to human factor. I have seen UNIX runnning for many years without issues. [quoted text clipped - 8 lines] > depends on many variables. If z/OS is more reliable, why are most mission > critical apps running on UNIX? And where, may I ask, are you getting the figures to substantiate that from? Larry E. >>>>There is really no data to support that. Any system can fail, mostly due >>>>to human factor. I have seen UNIX runnning for many years without [quoted text clipped - 11 lines] > And where, may I ask, are you getting the figures to substantiate that > from? Is that not true? I thought it is a well-known fact. Do I need to prove Windows runs on most desktops? >>>Who would want to use z/OS unless you want to pay 10 times as much for 1 >>>tenth of performance [quoted text clipped - 14 lines] > mainframe and how much space it takes up. It still doesn't have a tpc > benchmark. Bob ... I do not have those figures handy. But with all respect, you are selling the mainframe short if you don't think that mainframe customers have reasonable TCOs for the RAS requirements they have. Would I want to purchase a mainframe and all that it requires to serve one small application? Probably not. But most shops that run mainframe need the RAS that you can only get from a MF ... and have many many apps that run on them. When you have many apps that run on a platform that require that kind of RAS, it justifies the investment and you gain a reasonable TCO. Just like you wouldn't buy a 747 jet engine to power a Cessina, but you might buy one to power a 747. Plus, MF's have become much cheaper over the years. Larry E. >>>>Who would want to use z/OS unless you want to pay 10 times as much for 1 >>>>tenth of performance [quoted text clipped - 25 lines] > might buy one to power a 747. Plus, MF's have become much cheaper over the > years. To think that only mainframes can provide RAS is so yesterday, or shall I say yester-decades. There are far more LUWs running the most demanding applications out there than mainframes. There is no need for any figures to support that fact. What makes you think mainframes can run more apps? The number of apps that can run on UNIX is 10 times more then on z/OS. What isn't getting cheaper over the years? >>>>>Who would want to use z/OS unless you want to pay 10 times as much for 1 >>>>>tenth of performance [quoted text clipped - 35 lines] > can run on UNIX is 10 times more then on z/OS. What isn't getting cheaper > over the years? Never said that mainframes can run more apps. Please go back and read my post, which I stand by. Larry E. >>>>>>Who would want to use z/OS unless you want to pay 10 times as much for >>>>>>1 tenth of performance [quoted text clipped - 39 lines] > > Larry E. Do you even have a point by stating this? "Would I want to purchase a mainframe and all that it requires to serve one small application? Probably not. But most shops that run mainframe need the RAS that you can only get from a MF ... and have many many apps that run on them." >>>>>>>Who would want to use z/OS unless you want to pay 10 times as much for >>>>>>>1 tenth of performance [quoted text clipped - 48 lines] > that you can only get from a MF ... and have many many apps that run on > them." Well, apparently, you need to read my original post yet again, because you have still not shown me where it says "mainframes can run more apps". Please ... go troll somewhere else. Larry E. >>>>>>>>Who would want to use z/OS unless you want to pay 10 times as much >>>>>>>>for 1 tenth of performance [quoted text clipped - 52 lines] > > Please ... go troll somewhere else. So what was your point? Please clarify in a manner that will be relevant to the topic. >>>>>>>>>Who would want to use z/OS unless you want to pay 10 times as much >>>>>>>>>for 1 tenth of performance [quoted text clipped - 56 lines] > So what was your point? Please clarify in a manner that will be relevant to > the topic. OK. I'll make one more attempt, but I ask you to reply in a thoughtful and respectful way. I was saying that some people look to deploy a single application while some look to deploy large groups of many applications. It makes a lot more sense from a TCO perspective to deploy a set or groups of many applications that require the RAS of a mainframe environment into a mainframe environment ... rather than to consider a mainframe to deploy one application (depending upon how large it is, of course). Larry E. >>>>Do you even have a point by stating this? >>>> [quoted text clipped - 21 lines] > mainframe environment ... rather than to consider a mainframe to deploy > one application (depending upon how large it is, of course). That's not specific to mainframe. That's the case in general as most people already know. What is the relevancy to the subject? >>>>>Do you even have a point by stating this? >>>>> [quoted text clipped - 25 lines] > That's not specific to mainframe. That's the case in general as most people > already know. What is the relevancy to the subject? It's specific to the mainframe ... and true to a much lesser degree for other platforms. I'm done with this topic, Bob. Larry E. >>>>>>Do you even have a point by stating this? >>>>>> [quoted text clipped - 29 lines] > It's specific to the mainframe ... and true to a much lesser degree for > other platforms. I'm done with this topic, Bob. Other than being off the topic. This is just utterly untrue. How does runing one application make any more sense on other platforms? > When the current generation of DB2 experts retire ... the quality of > product will be of little import. Last I checked (on GULP.de) the average age of DB2 consultants was only marginally higher than that of Oracle consultants. The database skills you get out of colleges and universities are weak either way. Cheers Serge SignatureSerge Rielau DB2 Solutions Development IBM Toronto Lab > > When the current generation of DB2 experts retire ... the quality of > > product will be of little import. [quoted text clipped - 10 lines] > DB2 Solutions Development > IBM Toronto Lab I have been working with z/OS DB2 since 1989. I have done Oracle but not nearly as much. Oracle and DB2 are better products because they have to compete against each other. We benefit. BTW: I have never encountered Oracle on z/OS. DB2 for z/OS is a separate code base and is optimized for the z/OS environment. Penn > BTW: I have never encountered Oracle on z/OS. DB2 for z/OS is a > separate code base and is optimized for the z/OS environment. I thought DB2 for z/OS is 99% the same as LUW as IBM used to claim. Is it not true? > I thought DB2 for z/OS is 99% the same as LUW as IBM used to claim. Is it > not true? It is 99% the same at the DML level (select, insert, update, delete). That allows portability of applications from one platform to another. They not the same code base and is substantially different in most every other respects. IBM never claimed otherwise. If you thought so, then you were not listening carefully. But compatibility of databases at the DML level is nothing to sneeze at, as anyone who has tried to migrate an application from one database to another knows. Oracle folks like to make a big deal about the facts that DB2 for Linux, UNIX, and Windows is a different product than DB2 for z/OS, but very few shops run Oracle on z/OS for any kind of important application. If Oracle is installed on z/OS, it usually because they got a free license. I once got a list from an Oracle sales rep of 5 Fortune 100 companies that had Oracle installed on OS/390, and I checked every one of the 5 references provided to me. None of them panned out. They had it installed, but not using it for anything meaningful. >> I thought DB2 for z/OS is 99% the same as LUW as IBM used to claim. Is it >> not true? > > It is 99% the same at the DML level (select, insert, update, delete). That > allows portability of applications from one platform to another. No, there was no mention about DML, only DB2. > They not the same code base and is substantially different in most every > other respects. IBM never claimed otherwise. If you thought so, then you > were not listening carefully. Perhaps, you need to go to one of the DB2 training classes and see what the instructors say. If I did not listen carefully, many others must not have either. > But compatibility of databases at the DML level is nothing to sneeze at, > as anyone who has tried to migrate an application from one database to [quoted text clipped - 8 lines] > provided to me. None of them panned out. They had it installed, but not > using it for anything meaningful. I don't recommend running Oracle on z/OS either or anything for that matter. > No, there was no mention about DML, only DB2. > > Perhaps, you need to go to one of the DB2 training classes and see what > the instructors say. If I did not listen carefully, many others must not > have either. I don't need to go to an IBM training class since I am very experienced in both DB2 for z/OS and DB2 for Linux, UNIX, Windows. I am an IBM Certified DBA in both products. At one point in my career, I taught DB2 classes for IBM (I no longer work for IBM). If the instructor said what you claim, then he/she was mistaken. There are not many people who really know both products well. Just because a person works for IBM, Oracle, or anyone else does not mean they are infallible. It is even possible that an instructor for an IBM class in DB2 is not even an IBM employee. Many times I hear people say that "IBM says this", or "IBM says that." What they really mean is that a particular IBM employee said something. IBM is a organization of many people, some more knowledgeable than others (just like any other company). IBM employees do not consult a policy manual before they give their opinion any more than people at your company do. In addition, within IBM, there are people in product development, marketing, sales, consulting, outsourcing, teaching, etc who all deal with DB2 in some manner, and they in are different organizations within IBM, who may or may not talk to each other. >> No, there was no mention about DML, only DB2. >> [quoted text clipped - 24 lines] > DB2 in some manner, and they in are different organizations within IBM, > who may or may not talk to each other. Actually I could care less about what the DB2 instructors (from IBM) said. We all knew well DB2 for z/OS is not that much the same as LUW. They should probably call it DBZ instead. > Actually I could care less about what the DB2 instructors (from IBM) said. > We all knew well DB2 for z/OS is not that much the same as LUW. They > should probably call it DBZ instead. The term DB2 was used for the mainframe product name in 1983 before DB2 LUW (or its predecessors) existed. The first version of DB2 LUW was originally called OS/2 Database Manager and came bundled with OS/2 EE (along with Communication Manager) in about 1989. I don't have any problem with IBM calling the various versions DB2 for .... They are 99% compatible at the application level, which is an important consideration . Understanding that they may be different code base and different at the administration level, but compatible at the DML level, does not take a rocket scientist to understand and comprehend. >> Actually I could care less about what the DB2 instructors (from IBM) >> said. We all knew well DB2 for z/OS is not that much the same as LUW. [quoted text clipped - 10 lines] > base and different at the administration level, but compatible at the DML > level, does not take a rocket scientist to understand and comprehend. Now we are going from "99% the same" to "99% compatible DML". Wouldn't it be funny if SQL is different on LUW and z/OS? > Actually I could care less about what the DB2 instructors (from IBM) said. > We all knew well DB2 for z/OS is not that much the same as LUW. They should > probably call it DBZ instead. Not really. They are very similar. Much more similar than Oracle is to DB2. 100% compatibility on DML and 90%+ on DDL. SQL APIs almost exactly the same, if not the same. Features and functions very similar, but this is where they can differ (but may not) as for how they are implemented ... depending upon what you are trying to accomplish. Larry E. >> Actually I could care less about what the DB2 instructors (from IBM) >> said. We all knew well DB2 for z/OS is not that much the same as LUW. [quoted text clipped - 4 lines] > is where they can differ (but may not) as for how they are implemented ... > depending upon what you are trying to accomplish. Was there really a question that Oracle is not as similar to DB2? We are talking about all aspects of DB2. After all we don't just buy it to use DML. >>>Actually I could care less about what the DB2 instructors (from IBM) >>>said. We all knew well DB2 for z/OS is not that much the same as LUW. [quoted text clipped - 8 lines] > Was there really a question that Oracle is not as similar to DB2? We are > talking about all aspects of DB2. After all we don't just buy it to use DML. You buy it to run applications, and the point is that the applications are portable ... and so are the skills ... as I said, much more so than Oracle. Larry E. >>>>Actually I could care less about what the DB2 instructors (from IBM) >>>>said. We all knew well DB2 for z/OS is not that much the same as LUW. [quoted text clipped - 12 lines] > portable ... and so are the skills ... as I said, much more so than > Oracle. That seems to be contradicting with previous comments made by your fellows. Go back and read them. >>>>>Actually I could care less about what the DB2 instructors (from IBM) >>>>>said. We all knew well DB2 for z/OS is not that much the same as LUW. [quoted text clipped - 16 lines] > That seems to be contradicting with previous comments made by your fellows. > Go back and read them. No it's not, and I'm not going to feed your trollism anymore. Larry E. >>>>>>Actually I could care less about what the DB2 instructors (from IBM) >>>>>>said. We all knew well DB2 for z/OS is not that much the same as LUW. [quoted text clipped - 17 lines] >> fellows. Go back and read them. > No it's not, and I'm not going to feed your trollism anymore. Don't worry, you are not the only mainframer who is in the state of denial. > Don't worry, you are not the only mainframer who is in the state of > denial. FWIW, Larry is not a "mainframer". He works with both DB2 for LUW and DB2 for z/OS. > Oracle folks like to make a big deal about the facts that DB2 for Linux, > UNIX, and Windows is a different product than DB2 for z/OS, but very few > shops run Oracle on z/OS for any kind of important application. Except the little folks like The Boeing Company: But that really isn't the issue. The issue is that this is something a first-year computer science student could identify as an issue and fix. That it persists makes a statement about everything from attention to detail to customer service. You may well shrug your shoulders at this because of some misplaced concept of product loyalty. But you should be honest enough to admit that were the shoe on the other foot you'd be pointing to this as an example of what is wrong with the competitive product. SignatureDaniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond) >> Oracle folks like to make a big deal about the facts that DB2 for >> Linux, UNIX, and Windows is a different product than DB2 for z/OS, but [quoted text clipped - 11 lines] > that were the shoe on the other foot you'd be pointing to this as an > example of what is wrong with the competitive product. In all my years in this newsgroup I have never seen any substantiation of the claim actually being made. We hear this nearly exclusively in the context of some Oracle vs. DB2 debate. It seems like Oracle biased folks love to hype the importance of the rumor more so than IBM folks, just so they can discredit it... But hey there are other things that are repeated endlessly in this forum: 4 major RDBMS servers with _distinct_ codebases: IDS, DB2 for i5/OS, DB2 for zOS, DB2 for LUW 1 code base for DB2 for LUW across all LUW platforms. Fixes shipped on all platforms always and and at the same time (take that Oracle lovers, why is that so hard on the famous one code base Oracle that takes eons to ship on all their platforms????) 1 client code base across: IDS, DB2 for zOS and DB2 for LUW (I don't know about i5OS) There, frame it, put it up on the 101. Bring it to your DB2 classes and have the instructor call me who says different, whatever. Cheers Serge SignatureSerge Rielau DB2 Solutions Development IBM Toronto Lab > In all my years in this newsgroup I have never seen any substantiation of > the claim actually being made. We hear this nearly exclusively in the [quoted text clipped - 6 lines] > 4 major RDBMS servers with _distinct_ codebases: > IDS, DB2 for i5/OS, DB2 for zOS, DB2 for LUW Is this still unsubstantiated? > 1 code base for DB2 for LUW across all LUW platforms. > Fixes shipped on all platforms always and and at the same time (take that > Oracle lovers, why is that so hard on the famous one code base Oracle that > takes eons to ship on all their platforms????) Hmmm, then I wonder why Oracle is still ahead of DB2/DBI/DBZ/IDS. IBM must take longer than eons. > 1 client code base across: IDS, DB2 for zOS and DB2 for LUW (I don't know > about i5OS) So DB2 Connect for zOS has the same code base as DB2 Connect for LUW? > There, frame it, put it up on the 101. Bring it to your DB2 classes and > have the instructor call me who says different, whatever. It would be hard to frame a mess that confuses even the instructors. >> In all my years in this newsgroup I have never seen any substantiation of >> the claim actually being made. We hear this nearly exclusively in the [quoted text clipped - 8 lines] > > Is this still unsubstantiated? Bob, In this group we have a different netiquette than other groups may have. First of all we tend to read each others posts and try to understand what was meant rather than twist meaning just to get a flame going. Larry E. has pointed this out. I do it as well. I gladly have a discussion, but only if it is constructive. Presumably none of us are teenagers... :-) What I stated was that the claim Of "IBM states that DB2 is the same code across DB2 for LUW and DB2 for zOS" is unsubstantiated. E.g. send me a document that clearly has wrong information and I'll do my best to have it fixed. The only ones making these allegations appear to be posters like yourself who have a track record in c.d.o.server, but none in c.d.ibm-db2. Shouldn't the DB2 folks be more annoyed if they had been mislead? After all they "took the bait" so to speak. People hear what they are trained to hear. Are you sure it wasn't an Oracle rep claiming that IBM claims? And next time you spoke to an IBM rep/instructor perhaps (s)he didn't label everything (s)he said with a platform and he re-enforced your perception? Cheers Serge SignatureSerge Rielau DB2 Solutions Development IBM Toronto Lab >>> In all my years in this newsgroup I have never seen any substantiation >>> of the claim actually being made. We hear this nearly exclusively in the [quoted text clipped - 22 lines] > E.g. send me a document that clearly has wrong information and I'll do my > best to have it fixed. Why are repeating this? We have already agreed DB2 for z/OS is different from LUW. > The only ones making these allegations appear to be posters like yourself > who have a track record in c.d.o.server, but none in c.d.ibm-db2. > Shouldn't the DB2 folks be more annoyed if they had been mislead? After > all they "took the bait" so to speak. What allegations? Can you be more specific? I am not in this group as often. Does that mean I don't work with DB2? Judging from your comments here, I don't see you being any different from some people in c.d.o.server. > People hear what they are trained to hear. Are you sure it wasn't an > Oracle rep claiming that IBM claims? And next time you spoke to an IBM > rep/instructor perhaps (s)he didn't label everything (s)he said with a > platform and he re-enforced your perception? Do you see this as being constructive or mature? What have I said earlier? EOT SignatureSerge Rielau DB2 Solutions Development IBM Toronto Lab > EOT People at IBM are smart. They know when to quit. >> EOT > People at IBM are smart. They know when to quit. Die Wand gibt nach... Find a native German speaker to explain what it means... Cheers Serge SignatureSerge Rielau DB2 Solutions Development IBM Toronto Lab >>> EOT >> People at IBM are smart. They know when to quit. > Die Wand gibt nach... > > Find a native German speaker to explain what it means... I have no interest in German. This is an English forum. The use of other languages is a lack of, shall I say, netiquette? >>>> EOT >>> People at IBM are smart. They know when to quit. [quoted text clipped - 4 lines] > I have no interest in German. This is an English forum. The use of other > languages is a lack of, shall I say, netiquette? Spoken like an American. SignatureDaniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond) >>>>> EOT >>>> People at IBM are smart. They know when to quit. [quoted text clipped - 4 lines] >> other languages is a lack of, shall I say, netiquette? > Spoken like an American. As much as I love to disagree with Daniel, I can't oppose that one.... SignatureSerge Rielau DB2 Solutions Development IBM Toronto Lab > What I stated was that the claim Of "IBM states that DB2 is the same > code across DB2 for LUW and DB2 for zOS" is unsubstantiated. > E.g. send me a document that clearly has wrong information and I'll do > my best to have it fixed. Well - sometimes it's not made as clear as it could be, to the point of looking suspiciously like very carefully chosen language. For example, there is only one word, used twice, in the following sentence, that makes it clear that DB2 is in fact not DB2 is in fact not DB2. And this sentence is from the latest IBM documentation, last updated Jan 24 2008 > DB2 is DB2 is DB2 > The first thing that you should understand when choosing an edition of DB2 to service your workload is that, with the exception of DB2 Everyplace® and Apache Derby (whose SQL API is fully compatible with DB2), each DB2 edition has the same code base across all the distributed platforms. DB2's support for Linux extends across all of IBM's servers: System i®, System z®, System x®, and System p® -- the DB2 on all of these platforms is the distributed version too. For example, DB2 for Linux on System z is the same code base and licensed the same way as DB2 on an Intel or AMD-based workstation. This means that DB2 Connect is not required to access this data even though the DB2 for System z Linux server resides on a System z server. (Read that sentence twice - if you were connecting to a DB2 for z/OS data server on the System z server, you would require DB2 Connect; the difference here is that DB2 for Linux on a System z Integrated Facility for Linux (IFL) is a distributed versio n of DB2.) > A common code base offers portability and assurances that if you ever need to scale your DB2 solution, you can do so seamlessly without regard to costs, platform, or migration efforts; and since the SQL API within the DB2 family is about 95% common, movement between the DB2 family members is easy too. The text you post agrees with what Mark, Larry and I have been saying. SignatureSerge Rielau DB2 Solutions Development IBM Toronto Lab >> When the current generation of DB2 experts retire ... the quality of >> product will be of little import. [quoted text clipped - 5 lines] > Cheers > Serge Germany is not the world. Neither is the US. But a quick look around the data center will quickly demonstrate the demographic reality. The skill set coming out of college is irrelevant: I don't teach 20 year olds. But I do see a very substantial number of people writing in mySQL, Oracle, and SQL Server who are a full 10-15 years younger than those of us that remember punch cards. I spend quite a bit of time interviewing CTOs and IT managers about their concerns. Not one of them spends their time worrying about which of the big three commercial vendors has the better product. What they are talking about is the age and size of the talent pool. I just finished teaching a two week DBA intensive in Portland Oregon. Because there were developers there that wanted to become DBAs? Not one. Because product A was vastly superior to product B? Not a chance. Because a group of managers determined that there was not a big enough talent pool in their state from which to choose new employees! So they got together and made it bigger. It was just that simple. And two months from now we are going to run another boot camp for the same group for exactly the same reason. It is time for technologists to stop thinking about CPUs and tuples and start thinking about FTEs and net revenues. No business ever made a profit because they had the best IT department. SignatureDaniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond) > I just finished teaching a two week DBA intensive in Portland Oregon. > Because there were developers there that wanted to become DBAs? Not one. [quoted text clipped - 5 lines] > two months from now we are going to run another boot camp for the same > group for exactly the same reason. Assuming you didn't teach DB2. Didn't ou just contradict your own reasoning. 1. If I read this correctly your employer decided that there wasn't enough skills on Oracle 2. You appear to suggest that the pool can be made bigger with a few boot camps We have a gang here in the lab which actually never ever is in the lab. :-) They travel the world teaching DB2. They are bursting at the seams, trying to keep up with demand. Cheers Serge SignatureSerge Rielau DB2 Solutions Development IBM Toronto Lab >> I just finished teaching a two week DBA intensive in Portland Oregon. >> Because there were developers there that wanted to become DBAs? Not one. [quoted text clipped - 18 lines] > Cheers > Serge Was there a shortage of skilled DBAs in that state? You betcha. By the end of the year that shortage will be erased. There isn't a single organization in the region, not just the state, that could pull that off for DB2: That is the point I was making. The mechanism for replacing the aging workforce does not exist. And that may well explain the number of DB2 deployments in Oregon more than the marketing efforts and quality of software which is the point. My generation is rapidly aging itself out of the workforce. Nothing you are doing in Toronto will change that fact. PS: One of my Portland students flew in from Toronto. He is working on getting together a class up there so I may be in the neighborhood later this year. Heading for Victoria on Thursday. Come on out and I'll take you to dinner at the Empress. They've a reasonably good selection of single malts. <g> SignatureDaniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond) > Come on out and I'll take > you to dinner at the Empress. They've a reasonably good selection of > single malts. <g> I don't drink beer. SignatureSerge Rielau DB2 Solutions Development IBM Toronto Lab >> Come on out and I'll take >> you to dinner at the Empress. They've a reasonably good selection of >> single malts. <g> > I don't drink beer. You might want to move across the border into French Canada. Single malts are scotch: Not beer. <g> SignatureDaniel A. Morgan Oracle Ace Director & Instructor University of Washington damorgan@x.washington.edu (replace x with u to respond) Puget Sound Oracle Users Group www.psoug.org >>> Come on out and I'll take >>> you to dinner at the Empress. They've a reasonably good selection of [quoted text clipped - 4 lines] > > Single malts are scotch: Not beer. <g> Don't drink that either. Seems like we just don't fit that well. SignatureSerge Rielau DB2 Solutions Development IBM Toronto Lab > We have a gang here in the lab which actually never ever is in the lab. :-) > They travel the world teaching DB2. They are bursting at the seams, > trying to keep up with demand. And some other "collegues" from Rochester are out of the labs teaching DB2 for i5/OS ;-) > Cheers > Serge Regards Stefano P. Signature"Niuna impresa, per minima che sia, può avere cominciamento e fine senza queste tre cose: e cioè senza sapere, senza potere, senza con amor volere" [Anonimo fiorentino, XIV sec.] (togliere le "pinzillacchere" dall'indirizzo email ;-) > The number of potential 20 year olds moving into the workforce with > DB2 classes under their belt is zero. How about 30 year olds? You > get the point. > If I am running an organization I have far more important considerations > than whether product A is faster or cheaper than product B. I have > considerations about the size of the pool from which I can choose my > future employees. DB2 might be the best product since silicon was > discovered but if I can't find people to run my data center in 10 years > then I don't want it. > When the current generation of DB2 experts retire ... the quality of > product will be of little import. In my experience (till now limited to Italy), this is the type of discussion usually related to "system i" (aka iSeries aka AS/400) that - don't forget - has DB2 "embedded" in it: "there are no young people/programmers able to use/manage this system etc. etc."... ...but discussing here about this would be rather off topic. My two cents Stefano P. Signature"Niuna impresa, per minima che sia, può avere cominciamento e fine senza queste tre cose: e cioè senza sapere, senza potere, senza con amor volere" [Anonimo fiorentino, XIV sec.] (togliere le "pinzillacchere" dall'indirizzo email ;-) >>> On 1/27/2008 at 5:51 AM, in message <603d1pF1omia2U1@mid.individual.net>, Serge Rielau<srielau@ca.ibm.com> wrote: > DA Morgan wrote: >> Mark A wrote: >> >>> Oracle folks like to make a big deal about the facts that DB2 for >>> Linux, UNIX, and Windows is a different product than DB2 for z/OS, but >>> very few shops run Oracle on z/OS for any kind of important application. >> Except the little folks like The Boeing Company: But that really isn't >> the issue. [quoted text clipped - 21 lines] > 4 major RDBMS servers with _distinct_ codebases: > IDS, DB2 for i5/OS, DB2 for zOS, DB2 for LUW Don't forget DB2 Server for VSE and VM! Version 7.5 just released! :-) (Is DB2 VSE/VM supported out of Toronto? Just wondering.) Frank >>> On 1/26/2008 at 4:00 PM, in message <HXOmj.73818$rc2.58542@bignews1.bellsouth.net>, Mark A<nobody@nowhere.com> wrote: >> I thought DB2 for z/OS is 99% the same as LUW as IBM used to claim. Is > it [quoted text clipped - 31 lines] > > anything meaningful. I haven't seen any mention of this yet in this thread, but Oracle version 10 is the last version that will run on z/OS. (I think it is version 10. I can't seem to find any links to this announcement, but I've gotten at least two emails about it (which I must have deleted).). Frank |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.