Re: Company thought DB2 will be better than Oracle.

Mark A wrote: > <snipped> > >DB2 is good on Unix, Linux, and Windows also. DBA's don't like DB2 because >it takes fewer of them to operate and they think there are more Oracle jobs >in the marketplace. > ><snipped> > > Couldn't possibly be the lack of security without Tivoli or other similar products? Couldn't possibly be the lack of training classes? Couldn't possibly be the lack of books? Couldn't possibly be the fact that you need a C compiler on a production box? Couldn't possibly be the lack of third-party tools and applications? Couldn't possibly be .... And this from someone with 10+ years of DB2. In short ... there are plenty of reasons why someone might not like DB2. Which does not mean I am one of them. But rather to try to pin it on DBAs is a bit of a farse. Oracle, itself, is currently redesigning the DBA's roles and responsibilities to be less RDBMS management and more and more integration with application servers and other components. The idea that Oracle is hard to manage is just a repetition of mythology: It is no longer true. Just as many things about DB2 that were true five years ago are no longer true. -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply)

> >DB2 is good on Unix, Linux, and Windows also. DBA's don't like DB2 because > >it takes fewer of them to operate and they think there are more Oracle jobs > >in the marketplace. > > > Couldn't possibly be the lack of security without Tivoli or other > similar products? > Couldn't possibly be the lack of training classes? > Couldn't possibly be the lack of books? > Couldn't possibly be the fact that you need a C compiler on a production > box? > Couldn't possibly be the lack of third-party tools and applications? > Couldn't possibly be .... > > And this from someone with 10+ years of DB2. > > In short ... there are plenty of reasons why someone might not like DB2. > Which does not mean I am one of them. But rather to try to pin it on > DBAs is a bit of a farse. Oracle, itself, is currently redesigning the > DBA's roles and responsibilities to be less RDBMS management and more > and more integration with application servers and other components. The > idea that Oracle is hard to manage is just a repetition of mythology: It > is no longer true. Just as many things about DB2 that were true five > years ago are no longer true. > > -- > Daniel Morgan Those might be good reasons (if they were all true, but I don't agree that they are) for a manager to make that decision in favor of one product over another. But 90% of DBA's only care about the state of the job market and how their skills match up to that market.

Daniel, I don't have any problem with you expressing your opinion. But I do have to set the record straight. What lack of security? DB2 uses the underlying OS for authentication security and has the same internal object security that other rdbmses have. Can you provide more specifics on what you mean by this and how it manifests itself in the form of any issues? Plenty of DB2 training classes. Take a look at the IBM Education schedules. There are some very good DB2 books published on DB2. Do we need tons of them by different authors each serving the same purpose? What makes you think that you need a compiler on a production box? I do not think that is accurate. And as far as the third-party tools and applications, I can't believe you took a swat at that one. There were something like > 40000 last time I checked. Your points are sometimes well-taken. With all due respect, these had some significant inaccuracies. Larry Edelstein Daniel Morgan wrote: > Mark A wrote: > > > <snipped> > > > >DB2 is good on Unix, Linux, and Windows also. DBA's don't like DB2 because > >it takes fewer of them to operate and they think there are more Oracle jobs > >in the marketplace. > > > ><snipped> > > > > > Couldn't possibly be the lack of security without Tivoli or other > similar products? > Couldn't possibly be the lack of training classes? > Couldn't possibly be the lack of books? > Couldn't possibly be the fact that you need a C compiler on a production > box? > Couldn't possibly be the lack of third-party tools and applications? > Couldn't possibly be .... > > And this from someone with 10+ years of DB2. > > In short ... there are plenty of reasons why someone might not like DB2. > Which does not mean I am one of them. But rather to try to pin it on > DBAs is a bit of a farse. Oracle, itself, is currently redesigning the > DBA's roles and responsibilities to be less RDBMS management and more > and more integration with application servers and other components. The > idea that Oracle is hard to manage is just a repetition of mythology: It > is no longer true. Just as many things about DB2 that were true five > years ago are no longer true. > > -- > Daniel Morgan > http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp > http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp > damorgan@x.washington.edu > (replace 'x' with a 'u' to reply)

Mark A wrote: >>>DB2 is good on Unix, Linux, and Windows also. DBA's don't like DB2 >>> >>> >because > > >>>it takes fewer of them to operate and they think there are more Oracle >>> >>> >jobs > > >>>in the marketplace. >>> >>> >>> >>Couldn't possibly be the lack of security without Tivoli or other >>similar products? >>Couldn't possibly be the lack of training classes? >>Couldn't possibly be the lack of books? >>Couldn't possibly be the fact that you need a C compiler on a production >>box? >>Couldn't possibly be the lack of third-party tools and applications? >>Couldn't possibly be .... >> >>And this from someone with 10+ years of DB2. >> >>In short ... there are plenty of reasons why someone might not like DB2. >>Which does not mean I am one of them. But rather to try to pin it on >>DBAs is a bit of a farse. Oracle, itself, is currently redesigning the >>DBA's roles and responsibilities to be less RDBMS management and more >>and more integration with application servers and other components. The >>idea that Oracle is hard to manage is just a repetition of mythology: It >>is no longer true. Just as many things about DB2 that were true five >>years ago are no longer true. >> >>-- >>Daniel Morgan >> >> > >Those might be good reasons (if they were all true, but I don't agree that >they are) for a manager to make that decision in favor of one product over >another. But 90% of DBA's only care about the state of the job market and >how their skills match up to that market. > > > And why shouldn't they. The old social contract where employees were loyal to companies and companies were loyal to employees was stabbed in the back by MBA's quite a few years ago. Boeing, for example, has no shortage of people whose jobs were off-shored just because it saved a few dollars. And I'm not saying Boeing is bad and that I wouldn't have done the same in their position ... but under such conditions why shouldn't a DBA be thinking about the mortgage and putting the kids through college? -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply)

Comments interspersed. Larry Edelstein wrote: >Daniel, > >I don't have any problem with you expressing your opinion. But I do have to set >the record straight. > >What lack of security? DB2 uses the underlying OS for authentication security >and has the same internal object security that other rdbmses have. Can you >provide more specifics on what you mean by this and how it manifests itself in >the form of any issues? > My point was not that DB2 was unsecure on mainframes and UNIX ... but rather on Windows. Because, as demonstrated every week by a bunch of teenagers and 20 year olds ... the O/S itself is insecure. >Plenty of DB2 training classes. Take a look at the IBM Education schedules. > Exactly. Now try to find them from third-party training facilities here in Washington State, for example. Or from a community college or a university? And books? Try Amazon.com for example ... 245 DB2 books and how many relate to Windows? Then try Oracle ... 1128. Do you see the issue? And with Oracle there is a single code base an all operating systems so one book covers all platforms. Something not true with DB2. >There are some very good DB2 books published on DB2. Do we need tons of them by >different authors each serving the same purpose? > The reference in my post was to DB2 on Windows. Don't try to make it into something it was not intended to be. >What makes you think that you need a compiler on a production box? I do not >think that is accurate. > From my experience it is. Or do you run your databases without procedures? >And as far as the third-party tools and applications, I can't believe you took a >swat at that one. There were something like > 40000 last time I checked. > Third party means from companies other than IBM. And once again my reference was to the Windows platform only. >Your points are sometimes well-taken. With all due respect, these had some >significant inaccuracies. > >Larry Edelstein > > > Please reconsider. I am a DB2 user so I'm not slamming the product. But it has its fair share of weaknesses just as all products do. And I just think it is unfair to slam those that disagree with you as greedy DBAs that only care about their jobs. Though, as I've also posted ... the mortgage and putting the kids through college comes light-years before product loyalty. Neither IBM, nor Oracle, nor Microsoft is writing checks to me so I'm still responsible for the balance in the checkbook. -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply)

"Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1063411182.403065@yasure... > Mark A wrote: > Couldn't possibly be the lack of security without Tivoli or other > similar products? > Couldn't possibly be the lack of training classes? > Couldn't possibly be the lack of books? > Couldn't possibly be the fact that you need a C compiler on a production > box? > Couldn't possibly be the lack of third-party tools and applications? > Couldn't possibly be .... You forgot to mention that lovely old IBM tradition, BINDing.

Larry Edelstein <lsedels@us.ibm.com> wrote in message news:<3F6284C0.E95F4573@us.ibm.com>... > Daniel, [snip] > What makes you think that you need a compiler on a production box? I do not > think that is accurate. > > Larry Edelstein > > Daniel Morgan wrote: > > Couldn't possibly be the fact that you need a C compiler on a production > > box? Larry, what makes you think you'll get anything except more stupid arguments and big fat whopping lies from the Oracle crowd? The moment you explode one myth they'll pretend that wasn't the point, it was something else. C'mon, we're talking here about people who believe in a company that writes its own "independent reports" - a company for the dishonest. GET ROUTINE, PUT ROUTINE, Daniel. You really pretending you didn't know that, and if you really didn't know something that basic then how the hell do you figure you are qualified to discuss DB2? DG

Which many people see as an advantage by the way ... Larry Edelstein Neil Truby wrote: > "Daniel Morgan" <damorgan@x.washington.edu> wrote in message > news:1063411182.403065@yasure... > > Mark A wrote: > > > Couldn't possibly be the lack of security without Tivoli or other > > similar products? > > Couldn't possibly be the lack of training classes? > > Couldn't possibly be the lack of books? > > Couldn't possibly be the fact that you need a C compiler on a production > > box? > > Couldn't possibly be the lack of third-party tools and applications? > > Couldn't possibly be .... > > You forgot to mention that lovely old IBM tradition, BINDing.

Daniel Morgan wrote: > Comments interspersed. > > Larry Edelstein wrote: > > >Daniel, > > > >I don't have any problem with you expressing your opinion. But I do have to set > >the record straight. > > > >What lack of security? DB2 uses the underlying OS for authentication security > >and has the same internal object security that other rdbmses have. Can you > >provide more specifics on what you mean by this and how it manifests itself in > >the form of any issues? > > > My point was not that DB2 was unsecure on mainframes and UNIX ... but > rather on Windows. Because, as demonstrated every week by a bunch of > teenagers and 20 year olds ... the O/S itself is insecure. > > >Plenty of DB2 training classes. Take a look at the IBM Education schedules. > > > Exactly. Now try to find them from third-party training facilities here > in Washington State, for example. Or from a community college or a > university? And books? Try Amazon.com for example ... 245 DB2 books and > how many relate to Windows? Then try Oracle ... 1128. Do you see the > issue? And with Oracle there is a single code base an all operating > systems so one book covers all platforms. Something not true with DB2. I see DB2 classes on the education schedule in Seattle offered by IBM. Why the "requirement" for third-party training? When your execs make a database decision, what is the business driver/justification behind insisting on third-party training? Personally, if I were the exec, I'd rather have it from the company that makes the product. As I said, why the requirement for a library-full of DB2 books, when you can get what you need with less? The books are available. Windows, Unix, Linux ... same code .... same book. Again you're misstating the facts: DB2 Windows, UNIX, Linux are all exactly the same code base. I don't understand the class/book thing being a significant decision criteria. I don't see any issue here at all. > > > >There are some very good DB2 books published on DB2. Do we need tons of them by > >different authors each serving the same purpose? > > > The reference in my post was to DB2 on Windows. Don't try to make it > into something it was not intended to be. Again ... don't need special books for DB2 on Windows. Next case. > > > >What makes you think that you need a compiler on a production box? I do not > >think that is accurate. > > > From my experience it is. Or do you run your databases without procedures? You don't need a compiler on a production box to run SPs. > > > >And as far as the third-party tools and applications, I can't believe you took a > >swat at that one. There were something like > 40000 last time I checked. > > > Third party means from companies other than IBM. And once again my > reference was to the Windows platform only. Same deal. > 40000 apps and increasing on Windows/UNIX/Linux. > > > >Your points are sometimes well-taken. With all due respect, these had some > >significant inaccuracies. > > > >Larry Edelstein > > > > > > > Please reconsider. I am a DB2 user so I'm not slamming the product. But > it has its fair share of weaknesses just as all products do. And I just > think it is unfair to slam those that disagree with you as greedy DBAs > that only care about their jobs. Though, as I've also posted ... the > mortgage and putting the kids through college comes light-years before > product loyalty. Neither IBM, nor Oracle, nor Microsoft is writing > checks to me so I'm still responsible for the balance in the checkbook. Daniel ... again ... please express your opinions :-). But please do some research and know your facts. On this post, there is almost no point where you have a valid case. > > > -- > Daniel Morgan > http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp > http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp > damorgan@x.washington.edu > (replace 'x' with a 'u' to reply) Larry Edelstein

> Larry Edelstein > > Neil Truby wrote: > > You forgot to mention that lovely old IBM tradition, BINDing. > "Larry Edelstein" <lsedels@us.ibm.com> wrote in message news:3F631D4B.899933B5@us.ibm.com... > Which many people see as an advantage by the way ... Please expand ..?

Binding is done to support a feature called Static/Embedded SQL. Static SQL is suitable for situations where the SQL is somewhat predictable. You develop the SQL as part of the application code and "embed" it into the application so to speak. Then, you precompile, compile, link edit, and BIND the SQL into what is called a package (which essentially is a Load module). The package is an executable ... and when invoked, no compilation or bind is necessary ... therefore, the performance tends to be significantly better than dynamic SQL. Larry Edelstein Neil Truby wrote: > > Larry Edelstein > > > > Neil Truby wrote: > > > > You forgot to mention that lovely old IBM tradition, BINDing. > > "Larry Edelstein" <lsedels@us.ibm.com> wrote in message > news:3F631D4B.899933B5@us.ibm.com... > > > Which many people see as an advantage by the way ... > > Please expand ..?

Daniel ... again ... please express your opinions :-). But please do some research >and know your facts. On this post, there is almost no point where you have a valid >case. > >-- >Daniel Morgan >http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp >http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp >damorgan@x.washington.edu >(replace 'x' with a 'u' to reply) > > > >Larry Edelstein > > Then please corrrect me. My recollection from a few years ago when I was doing some DB2 work was that the code base for Windows was different from that for AIX was different from that for AS/400 was different from that for VM was different from that for MVS was different from that for Z-series requiring recompilation with a C compiler on the production box. And that the C compiler was not included with the database but was an extra expense. I'd appreciate a clarification if this is no longer true or my memory is faulty. -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply)

dbguy101@hotmail.com (Database Guy) wrote in message news:<7fdee71c.0309130147.14a213ad@posting.google.com>... > Larry, what makes you think you'll get anything except more stupid > arguments and big fat whopping lies from the Oracle crowd? Oh, just like the "lie" about the multiple code bases? Which the DB2 "experts" two years ago REFUSED to accept and has now been openly recognized as the truth? > The moment > you explode one myth they'll pretend that wasn't the point, it was > something else. Heard that one before many times from the DB2 mob myself. > C'mon, we're talking here about people who believe in > a company that writes its own "independent reports" - a company for > the dishonest. and IBM doesn't do that? GMAB, if Oracle is a company for the dishonest, then IBM is a company for the bigots. > > GET ROUTINE, PUT ROUTINE, Daniel. You really pretending you didn't > know that, and if you really didn't know something that basic then how > the hell do you figure you are qualified to discuss DB2? The problem with some DB2 idiots is they think age of a product equates to qualification of any incompetent user to argue about it. Preferably with insulting arguments. Did you really read Daniel's reply? Nuno Souto wizofoz2k@yahoo.com.au.nospam PS: veiled threats do nothing for me. Neither does open hostility, innuendo posted on newsgroups under fake ids and all sorts of other DISHONEST techniques.

DB2 doesn't do dynamic SQL; it turns dynamic SQL into static SQL and runs that. If you issue dynamic SQL (and do not commit) then anyone who is trying to bind after you is hung until you commit. Why? Because the dynamic sql is bound and a plan is generated, a row is added to the plan table (thus blocking others from adding to the plan table, until you commit). Since the concurrency model in db2 is not very concurrent people issueing dynamic sql lock out those trying to bind their plans in. It really pisses the developers on the system off. I was at ATT (American Transtech) years ago with DB2 running on a mainframe and this was a major problem. So we had to take the application and remove any transactions and just do everything in an autocommit type of mode.(issue select...; commit;...etc.) Binding is a nice and powerfule thing, but the way IBM has implimented it it really makes DB2 an autocommit only type of database. Ugly real ugly. Jim "Larry Edelstein" <lsedels@us.ibm.com> wrote in message news:3F632A76.D3609842@us.ibm.com... > Binding is done to support a feature called Static/Embedded SQL. Static > SQL is suitable for situations where the SQL is somewhat predictable. > You develop the SQL as part of the application code and "embed" it into > the application so to speak. Then, you precompile, compile, link edit, > and BIND the SQL into what is called a package (which essentially is a > Load module). The package is an executable ... and when invoked, no > compilation or bind is necessary ... therefore, the performance tends to > be significantly better than dynamic SQL. > > Larry Edelstein > > Neil Truby wrote: > > > > Larry Edelstein > > > > > > Neil Truby wrote: > > > > > > You forgot to mention that lovely old IBM tradition, BINDing. > > > "Larry Edelstein" <lsedels@us.ibm.com> wrote in message > > news:3F631D4B.899933B5@us.ibm.com... > > > > > Which many people see as an advantage by the way ... > > > > Please expand ..? >

>Then please corrrect me. My recollection from a few years >ago when I was doing some DB2 work was that the code >base for Windows was different from that for AIX was different >from that for AS/400 was different from that for VM was different >from that for MVS was different from that for Z-series requiring >recompilation with a C compiler on the production box. And that >the C compiler was not included with the database but was an extra expense. >I'd appreciate a clarification if this is no longer true or my memory is faulty. You did not address the questions to me, but I will answer them. The DB2 code base for Windows, Linux and Unix is 90% the same. The MVS, VM , and AS/400 products are all different, which is not really a factor since either Oracle doesn't have a product on these platforms, or the if they do, the Oracle product is universally known to stink on these platforms. If you write stored procedures in C, you will need a compiler, but not sure if it needs to be on the production machine. But if you say so, I would concede that point. Stored procedures may also be written in SQL, which is the preferred method. With regards to the total cost of ownership, I think that you will find DB2 cheaper or the same as Oracle even with the compiler expense.

Jim, I can't answer your assertion to this level of detail ... I'll leave that to someone else from the lab who knows more about the DB2 concurrency model. I can tell you that - I'm not sure that this is accurate ... "turns dynamic SQL into static SQL"? - even if it is, you are talking about an experience on DB2/MVS from years ago - there are drawbacks about Oracle's concurrency model also. I believe that the lock status is maintained on each data block potentially requiring disk access in certain cases. Jim Kennedy wrote: > DB2 doesn't do dynamic SQL; it turns dynamic SQL into static SQL and runs > that. If you issue dynamic SQL (and do not commit) then anyone who is > trying to bind after you is hung until you commit. Why? Because the > dynamic sql is bound and a plan is generated, a row is added to the plan > table (thus blocking others from adding to the plan table, until you > commit). Since the concurrency model in db2 is not very concurrent people > issueing dynamic sql lock out those trying to bind their plans in. It > really pisses the developers on the system off. I was at ATT (American > Transtech) years ago with DB2 running on a mainframe and this was a major > problem. So we had to take the application and remove any transactions and > just do everything in an autocommit type of mode.(issue select...; > commit;...etc.) > > Binding is a nice and powerfule thing, but the way IBM has implimented it it > really makes DB2 an autocommit only type of database. Ugly real ugly. > Jim > > "Larry Edelstein" <lsedels@us.ibm.com> wrote in message > news:3F632A76.D3609842@us.ibm.com... > > Binding is done to support a feature called Static/Embedded SQL. Static > > SQL is suitable for situations where the SQL is somewhat predictable. > > You develop the SQL as part of the application code and "embed" it into > > the application so to speak. Then, you precompile, compile, link edit, > > and BIND the SQL into what is called a package (which essentially is a > > Load module). The package is an executable ... and when invoked, no > > compilation or bind is necessary ... therefore, the performance tends to > > be significantly better than dynamic SQL. > > > > Larry Edelstein > > > > Neil Truby wrote: > > > > > > Larry Edelstein > > > > > > > > Neil Truby wrote: > > > > > > > > You forgot to mention that lovely old IBM tradition, BINDing. > > > > "Larry Edelstein" <lsedels@us.ibm.com> wrote in message > > > news:3F631D4B.899933B5@us.ibm.com... > > > > > > > Which many people see as an advantage by the way ... > > > > > > Please expand ..? > >

Hi Daniel, Code Bases: The code base across Intel, UNIX, Linux (including with the partitioning option) is absolutely the same. There are some differences between the Intel/UNIX/Linux code base and the AS/400 and DB2/390 code bases ... but mostly in areas that a customer would actually want them to be different. For example, there must be slightly different code in order to exploit Windows threads/security vs. 390 Sysplex/Workload Manager. Key point: The DDL, DML, and APIs are virtually the same ... or very close, with any differences of note within the DDL ... because there are different physical storage structures on the 390. That's the nature of the beast when you have a database that is optimized to run so well on platforms that are vastly different. My own opinion is even if there are differences, why make an issue out of it? Suppose your shop or company is Windows/UNIX-only and doesn't even have a mainframe? In that case, any differences would not even enter into the business case for or against a database. In terms of the C compiler, there is no requirement for the C compiler to reside on a production machine. At the current point-in-time, you need a C compiler on a development machine ... and as long as it has the same os and db2 levels ... the SQL Stored procedure executables can be moved to any other box with those same levels. And ... I believe that IBM is working towards elimination of the C Compiler completely. Just like I'm sure that there are requirements against Oracle's db that they are working to address also. Larry Edelstein Daniel Morgan wrote: > Daniel ... again ... please express your opinions :-). But please do > some research > >> and know your facts. On this post, there is almost no point where >> you have a valid >> case. >> >> -- >> Daniel Morgan >> http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp >> http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp >> damorgan@x.washington.edu >> (replace 'x' with a 'u' to reply) >> >> Larry Edelstein >> > Then please corrrect me. My recollection from a few years ago when I > was doing some DB2 work was that the code base for Windows was > different from that for AIX was different from that for AS/400 was > different from that for VM was different from that for MVS was > different from that for Z-series requiring recompilation with a C > compiler on the production box. And that the C compiler was not > included with the database but was an extra expense. > > I'd appreciate a clarification if this is no longer true or my memory > is faulty. > > -- > Daniel Morgan > http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp > http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp > damorgan@x.washington.edu > (replace 'x' with a 'u' to reply) >

Larry, Thanks for admitting the differences in DB2 code for AS/400 , OS/390 and UNIX, Linux and Windows. DB2 on Main Frames is solid and stable system. On non-main frames system, company can run DB2 at business risk. DB2 is a simple database without any built in procedure language or message system. DB2 has no message system, you need IBM MQ series and 5-10 IT staff of MQ series administrator and developers. In Oracle and SQL Server, it is all built into the database. When you buy the product, you buy it in one bundle. Oracle has only one listener for both database and messaging. MQ admin. has to set channel and listener separately and DB2 Admin. and MQ admin. are two separate job areas. Oracle or SQL Server DBA does the job of 5-10 IBM MQ Administrators and developers also. I don't want to give a list of companies that have gone out of business because competitor was running Oracle or MySQL for that matter. Many companies are trying DB2 on non Main frames system because of political pressure in the IT department from the Main frames group. If you read my first mail carefully, I am saying it will take years for IBM DB2 to mature on non Main frame systems. Please wait and see DB2 instance all of sudden disappearing from your production system with a simple select usage. I am not anti DB2 but I am telling you the fact. Peter Larry Edelstein <lsedels@us.ibm.com> wrote in message news:<3F6350F3.2946747D@us.ibm.com>... > Hi Daniel, > > Code Bases: > > The code base across Intel, UNIX, Linux (including with the partitioning > option) is absolutely the same. There are some differences between the > Intel/UNIX/Linux code base and the AS/400 and DB2/390 code bases ... but > mostly in areas that a customer would actually want them to be > different. For example, there must be slightly different code in order > to exploit Windows threads/security vs. 390 Sysplex/Workload Manager. > Key point: The DDL, DML, and APIs are virtually the same ... or very > close, with any differences of note within the DDL ... because there are > different physical storage structures on the 390. That's the nature of > the beast when you have a database that is optimized to run so well on > platforms that are vastly different. > > My own opinion is even if there are differences, why make an issue out > of it? Suppose your shop or company is Windows/UNIX-only and doesn't > even have a mainframe? In that case, any differences would not even > enter into the business case for or against a database. > > In terms of the C compiler, there is no requirement for the C compiler > to reside on a production machine. At the current point-in-time, you > need a C compiler on a development machine ... and as long as it has the > same os and db2 levels ... the SQL Stored procedure executables can be > moved to any other box with those same levels. And ... I believe that > IBM is working towards elimination of the C Compiler completely. Just > like I'm sure that there are requirements against Oracle's db that they > are working to address also. > > Larry Edelstein > > Daniel Morgan wrote: > > > Daniel ... again ... please express your opinions :-). But please do > > some research > > > >> and know your facts. On this post, there is almost no point where > >> you have a valid > >> case. > >> > >> -- > >> Daniel Morgan > >> http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp > >> http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp > >> damorgan@x.washington.edu > >> (replace 'x' with a 'u' to reply) > >> > >> Larry Edelstein > >> > > Then please corrrect me. My recollection from a few years ago when I > > was doing some DB2 work was that the code base for Windows was > > different from that for AIX was different from that for AS/400 was > > different from that for VM was different from that for MVS was > > different from that for Z-series requiring recompilation with a C > > compiler on the production box. And that the C compiler was not > > included with the database but was an extra expense. > > > > I'd appreciate a clarification if this is no longer true or my memory > > is faulty. > > > > -- > > Daniel Morgan > > http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp > > http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp > > damorgan@x.washington.edu > > (replace 'x' with a 'u' to reply) > > > > --

"Peter" <peter_and_john2003@yahoo.com> wrote in message <snip> > Please wait and see DB2 instance all of sudden disappearing from > your production system with a simple select usage. I am not > anti DB2 but I am telling you the fact. > > Peter > This is the kind of trash that keeps this thread alive. One can argue all day long about features, price, etc, but when one comes up against this idiotic remark, what can be said?

Mark A wrote: >>Then please corrrect me. My recollection from a few years >>ago when I was doing some DB2 work was that the code >>base for Windows was different from that for AIX was different >> >> >>from that for AS/400 was different from that for VM was different >>from that for MVS was different from that for Z-series requiring > > >>recompilation with a C compiler on the production box. And that >>the C compiler was not included with the database but was an extra expense. >> >> > > > >>I'd appreciate a clarification if this is no longer true or my memory is >> >> >faulty. > >You did not address the questions to me, but I will answer them. > >The DB2 code base for Windows, Linux and Unix is 90% the same. > >The MVS, VM , and AS/400 products are all different, which is not really a >factor since either Oracle doesn't have a product on these platforms, or the >if they do, the Oracle product is universally known to stink on these >platforms. > >If you write stored procedures in C, you will need a compiler, but not sure >if it needs to be on the production machine. But if you say so, I would >concede that point. Stored procedures may also be written in SQL, which is >the preferred method. With regards to the total cost of ownership, I think >that you will find DB2 cheaper or the same as Oracle even with the compiler >expense. > > > When you say "is 90% the same" isn't that just saying they are different without saying it? Sort of like trying to say you are 90% half-pregnant. I don't think anyone should debate TOC as there are no standards by which to judge the accuracy of the statement. Anyone that paid list price for any hardware or software should buy their next car from me. -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply)

>>The DB2 code base for Windows, Linux and Unix is 90% the same. >>The MVS, VM , and AS/400 products are all different, which is not really a >>factor since either Oracle doesn't have a product on these platforms, or the >>if they do, the Oracle product is universally known to stink on these >>platforms. >>If you write stored procedures in C, you will need a compiler, but not sure >>if it needs to be on the production machine. But if you say so, I would >>concede that point. Stored procedures may also be written in SQL, which is >>the preferred method. With regards to the total cost of ownership, I think >>that you will find DB2 cheaper or the same as Oracle even with the compiler >>expense. >When you say "is 90% the same" isn't that just saying they are different >without saying it? Sort of like trying to say you are 90% half-pregnant. >I don't think anyone should debate TOC as there are no standards by >which to judge the accuracy of the statement. Anyone that paid list price >for any hardware or software should buy their next car from me. >Daniel Morgan The code base for DB2 on Windows, Linux, and Unix is 100% the same except for those things that are operating system specific. Everything that is possible to be the same, is the same on DB2 and that calculates to about 90%. Operating system specific code for DB2 has been isolated into separate modules. The same is true of Oracle. Please don't insult my intelligence by claiming otherwise.

Larry Edelstein wrote: >Jim, > >I can't answer your assertion to this level of detail ... I'll leave that to >someone else from the lab who knows more about the DB2 concurrency model. I can >tell you that > >- I'm not sure that this is accurate ... "turns dynamic SQL into static SQL"? >- even if it is, you are talking about an experience on DB2/MVS from years ago >- there are drawbacks about Oracle's concurrency model also. I believe that the >lock status is maintained on each data block potentially requiring disk access >in certain cases. > ><snipped> > > Speculating about the properties of a product you are not that familiar with is like trying to jog across quick sand. While I have worked extensively with DB2 it was some years ago so I try to step gingerly when discussing specifics. But to address your statement ... Oracle doesn't lock blocks. Period. You couldn't do it if you tried. And with Oracle dropping rollback segments in favor of undo almost all of the traditional concerns are gone. I haven't seen an ORA-01555 in more than a year. And that's in development. Haven't seen one in production on a 9i server since its release. I do think we should be careful that what started out as one thing has the potential to turn into a flame war. I'd suggest everyone remember this are tools not religions, take a deep breath, and step back form the abyss. Lets be sure to keep this discussion professional. -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply)

> Speculating about the properties of a product you are not that familiar > with is like trying to jog across quick sand. While > I have worked extensively with DB2 it was some years ago so I try to > step gingerly when discussing specifics. But to > address your statement ... Oracle doesn't lock blocks. Period. You > couldn't do it if you tried. And with Oracle dropping > rollback segments in favor of undo almost all of the traditional > concerns are gone. I haven't seen an ORA-01555 in more > than a year. And that's in development. Haven't seen one in production > on a 9i server since its release. > > I do think we should be careful that what started out as one thing has > the potential to turn into a flame war. I'd suggest > everyone remember this are tools not religions, take a deep breath, and > step back form the abyss. Lets be sure to keep > this discussion professional. > > -- > Daniel Morgan I think it is worth noting that issue raised about DB2 concurrency was talking about DB2 for OS/390. The person was referring to a development environment with lots of ad-hoc queries. Most shops have figured out how to deal with these issues, although apparently there are some who lack experienced DBA's. Hopefully, the person who complained about DB2 for OS/390 concurrency problems does not suggest that anyone use Oracle for OS/390 to run a business (even though it is an "available" product).

Peter, Peter wrote: > Larry, > > Thanks for admitting the differences in DB2 code for AS/400 , > OS/390 and UNIX, Linux and Windows. DB2 on Main Frames > is solid and stable system. On non-main frames system, company > can run DB2 at business risk. > Run DB2 at business risk? Gimme a break. You either don't realize what you are saying, or you do and your being deceptive. There are plenty of companies running large-scale applications vital to their business on DB2 Intel/UNIX/Linux. You should take a look at the IBM data management web pages. Applications and database sizes that are much larger than the competition can even think about right now. And just to clarify, my "admission" as you put it was that there are beneficial differences between the DB2 codebase on Intel/UNIX/Linux and DB2 on AS/400 and OS/390. NOT that there are differences in the codebase between DB2 on Intel and UNIX and Linux. It's interesting that sw vendors who make databases that do have OS/390 versions but which DON'T have these differences can't seem to be very successful on the 390 platform. > > DB2 is a simple database without any built in procedure language or > message system. DB2 has no message system, you need IBM MQ > series and 5-10 IT staff of MQ series administrator and > developers. In Oracle and SQL Server, it is all built into the > database. When you buy the product, you buy it in one bundle. > Oracle has only one listener for both database and messaging. > MQ admin. has to set channel and listener separately and DB2 > Admin. and MQ admin. are two separate job areas. Huh? No built in procedure language? DB2 is the only database with a procedure language based on the ANSI PSM standard. IBM and Oracle have two distinctly different strategies. IBM chooses to allow the customer to have choice in selection of best-of-breed products that integrate with DB2 vs. Oracle's strategy is to embed everything into the database and lock the customer in to features/functions that may not be best-of-breed. Most people who want to do queuing do it with MQ. > > > Oracle or SQL Server DBA does the job of 5-10 IBM MQ > Administrators and developers also. > > I don't want to give a list of companies that have gone out of > business because competitor was running Oracle or MySQL > for that matter. Please do ... I'd be very interested in backup to this claim. > > > Many companies are trying DB2 on non Main frames system > because of political pressure in the IT department from the > Main frames group. If you read my first mail carefully, I am > saying it will take years for IBM DB2 to mature on non Main > frame systems. > I don't know where you're getting this from. Nobody buys databases because of political pressure from I/T. I/T budgets have to be funded by application areas and the business. People buy databases because applications and the business drive them. > > Please wait and see DB2 instance all of sudden disappearing from > your production system with a simple select usage. I am not > anti DB2 but I am telling you the fact. > > Peter > Peter ... if this has really happened to you and there is nothing you could have done to avoid it, that is unfortunate indeed. Sometimes sw products have defects (if that is what turns out to be the case here). Are you gonna tell me that this kind of thing has never happened with any other sw product before? Why don't you keep us posted on what the problem turned out to be. And why don't you provide us with some more details on the problem? Larry > > > Larry Edelstein <lsedels@us.ibm.com> wrote in message news:<3F6350F3.2946747D@us.ibm.com>... > > Hi Daniel, > > > > Code Bases: > > > > The code base across Intel, UNIX, Linux (including with the partitioning > > option) is absolutely the same. There are some differences between the > > Intel/UNIX/Linux code base and the AS/400 and DB2/390 code bases ... but > > mostly in areas that a customer would actually want them to be > > different. For example, there must be slightly different code in order > > to exploit Windows threads/security vs. 390 Sysplex/Workload Manager. > > Key point: The DDL, DML, and APIs are virtually the same ... or very > > close, with any differences of note within the DDL ... because there are > > different physical storage structures on the 390. That's the nature of > > the beast when you have a database that is optimized to run so well on > > platforms that are vastly different. > > > > My own opinion is even if there are differences, why make an issue out > > of it? Suppose your shop or company is Windows/UNIX-only and doesn't > > even have a mainframe? In that case, any differences would not even > > enter into the business case for or against a database. > > > > In terms of the C compiler, there is no requirement for the C compiler > > to reside on a production machine. At the current point-in-time, you > > need a C compiler on a development machine ... and as long as it has the > > same os and db2 levels ... the SQL Stored procedure executables can be > > moved to any other box with those same levels. And ... I believe that > > IBM is working towards elimination of the C Compiler completely. Just > > like I'm sure that there are requirements against Oracle's db that they > > are working to address also. > > > > Larry Edelstein > > > > Daniel Morgan wrote: > > > > > Daniel ... again ... please express your opinions :-). But please do > > > some research > > > > > >> and know your facts. On this post, there is almost no point where > > >> you have a valid > > >> case. > > >> > > >> -- > > >> Daniel Morgan > > >> http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp > > >> http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp > > >> damorgan@x.washington.edu > > >> (replace 'x' with a 'u' to reply) > > >> > > >> Larry Edelstein > > >> > > > Then please corrrect me. My recollection from a few years ago when I > > > was doing some DB2 work was that the code base for Windows was > > > different from that for AIX was different from that for AS/400 was > > > different from that for VM was different from that for MVS was > > > different from that for Z-series requiring recompilation with a C > > > compiler on the production box. And that the C compiler was not > > > included with the database but was an extra expense. > > > > > > I'd appreciate a clarification if this is no longer true or my memory > > > is faulty. > > > > > > -- > > > Daniel Morgan > > > http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp > > > http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp > > > damorgan@x.washington.edu > > > (replace 'x' with a 'u' to reply) > > > > > > > --

"Mark A" <ma@switchboard.net> wrote in message news:CYL8b.796$TJ.79084@news.uswest.net... > > Speculating about the properties of a product you are not that familiar > > with is like trying to jog across quick sand. While > > I have worked extensively with DB2 it was some years ago so I try to > > step gingerly when discussing specifics. But to > > address your statement ... Oracle doesn't lock blocks. Period. You > > couldn't do it if you tried. And with Oracle dropping > > rollback segments in favor of undo almost all of the traditional > > concerns are gone. I haven't seen an ORA-01555 in more > > than a year. And that's in development. Haven't seen one in production > > on a 9i server since its release. > > > > I do think we should be careful that what started out as one thing has > > the potential to turn into a flame war. I'd suggest > > everyone remember this are tools not religions, take a deep breath, and > > step back form the abyss. Lets be sure to keep > > this discussion professional. > > > > -- > > Daniel Morgan > > I think it is worth noting that issue raised about DB2 concurrency was > talking about DB2 for OS/390. The person was referring to a development > environment with lots of ad-hoc queries. Most shops have figured out how to > deal with these issues, although apparently there are some who lack > experienced DBA's. > > Hopefully, the person who complained about DB2 for OS/390 concurrency > problems does not suggest that anyone use Oracle for OS/390 to run a > business (even though it is an "available" product). > > No, this was a production environment. In the days of client server GUI s these might be "labled" ad hoc queries but in fact they were queries to run a production system for NYNEX. The tool did not allow "binding" and without issuing explicit commit statements after every select , insert, or update statement everyone else would get locked out of issuing queries or binding their plans for the production system. I thought mainframes were for production quality code. (and so did ATT) Jim

Daniel, You are right about the flame war (although somehow I don't think we've seen the last of this one yet :-)). But let me tell you one thing: I may not be the most eloquent at describing the flaws or drawbacks of Oracle, but for you to take potshots at DB2 (many of which weren't even valid) and then pretend that Oracle has no drawbacks or flaws is insulting. Larry Edelstein Daniel Morgan wrote: > Larry Edelstein wrote: > > >Jim, > > > >I can't answer your assertion to this level of detail ... I'll leave that to > >someone else from the lab who knows more about the DB2 concurrency model. I can > >tell you that > > > >- I'm not sure that this is accurate ... "turns dynamic SQL into static SQL"? > >- even if it is, you are talking about an experience on DB2/MVS from years ago > >- there are drawbacks about Oracle's concurrency model also. I believe that the > >lock status is maintained on each data block potentially requiring disk access > >in certain cases. > > > ><snipped> > > > > > Speculating about the properties of a product you are not that familiar > with is like trying to jog across quick sand. While > I have worked extensively with DB2 it was some years ago so I try to > step gingerly when discussing specifics. But to > address your statement ... Oracle doesn't lock blocks. Period. You > couldn't do it if you tried. And with Oracle dropping > rollback segments in favor of undo almost all of the traditional > concerns are gone. I haven't seen an ORA-01555 in more > than a year. And that's in development. Haven't seen one in production > on a 9i server since its release. > > I do think we should be careful that what started out as one thing has > the potential to turn into a flame war. I'd suggest > everyone remember this are tools not religions, take a deep breath, and > step back form the abyss. Lets be sure to keep > this discussion professional. > > -- > Daniel Morgan > http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp > http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp > damorgan@x.washington.edu > (replace 'x' with a 'u' to reply)

Mark A wrote: >>>The DB2 code base for Windows, Linux and Unix is 90% the same. >>> >>> > > > >>>The MVS, VM , and AS/400 products are all different, which is not really a >>>factor since either Oracle doesn't have a product on these platforms, or >>> >>> >the > > >>>if they do, the Oracle product is universally known to stink on these >>>platforms. >>> >>> > > > >>>If you write stored procedures in C, you will need a compiler, but not >>> >>> >sure > > >>>if it needs to be on the production machine. But if you say so, I would >>>concede that point. Stored procedures may also be written in SQL, which is >>>the preferred method. With regards to the total cost of ownership, I think >>>that you will find DB2 cheaper or the same as Oracle even with the >>> >>> >compiler > > >>>expense. >>> >>> > > > >>When you say "is 90% the same" isn't that just saying they are different >>without saying it? Sort of like trying to say you are 90% half-pregnant. >> >> > > > >>I don't think anyone should debate TOC as there are no standards by >>which to judge the accuracy of the statement. Anyone that paid list price >>for any hardware or software should buy their next car from me. >>Daniel Morgan >> >> > >The code base for DB2 on Windows, Linux, and Unix is 100% the same except >for those things that are operating system specific. Everything that is >possible to be the same, is the same on DB2 and that calculates to about >90%. Operating system specific code for DB2 has been isolated into separate >modules. > >The same is true of Oracle. Please don't insult my intelligence by claiming >otherwise. > > > Sorry to say this but the code base for Oracle is 100% identical between platforms. I can develop on Win98, export tables, data, code, etc. Import directly to any other platform-operating system that Oracle supports and it runs, perfectly, with zero modifications. The only difference I can possibly think of would be things that are path specific such as c:\\temp changing to /opt/. It isn't about insulting your intelligence ... it is a fact. -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply)

Mark A wrote: >>Speculating about the properties of a product you are not that familiar >>with is like trying to jog across quick sand. While >>I have worked extensively with DB2 it was some years ago so I try to >>step gingerly when discussing specifics. But to >>address your statement ... Oracle doesn't lock blocks. Period. You >>couldn't do it if you tried. And with Oracle dropping >>rollback segments in favor of undo almost all of the traditional >>concerns are gone. I haven't seen an ORA-01555 in more >>than a year. And that's in development. Haven't seen one in production >>on a 9i server since its release. >> >>I do think we should be careful that what started out as one thing has >>the potential to turn into a flame war. I'd suggest >>everyone remember this are tools not religions, take a deep breath, and >>step back form the abyss. Lets be sure to keep >>this discussion professional. >> >>-- >>Daniel Morgan >> >> > >I think it is worth noting that issue raised about DB2 concurrency was >talking about DB2 for OS/390. The person was referring to a development >environment with lots of ad-hoc queries. Most shops have figured out how to >deal with these issues, although apparently there are some who lack >experienced DBA's. > >Hopefully, the person who complained about DB2 for OS/390 concurrency >problems does not suggest that anyone use Oracle for OS/390 to run a >business (even though it is an "available" product). > > > Well I know I was running Oracle on Amdahl's at Boeing a few years back and likely they still do. But I agree. If anyone has followed this thread ... they should remember as I have pointed out ... my comment was directed to DB2 on Windows and a statement that I wouldn't recommend it. I said nothing about OS/390 or AS/400. -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply)

Larry Edelstein wrote: >Daniel, > >You are right about the flame war (although somehow I don't think we've seen the >last of this one yet :-)). But let me tell you one thing: I may not be the most >eloquent at describing the flaws or drawbacks of Oracle, but for you to take >potshots at DB2 (many of which weren't even valid) and then pretend that Oracle has >no drawbacks or flaws is insulting. > >Larry Edelstein > > > I don't believe I took any potshots at DB2 nor do I recall ever saying Oracle was flawless. Perhaps you should attend my lectures sometime. I take no potshots at anyone. I do, however, criticize freely when I find flaws or bugs. Software is a tool, not a religion. And there is no reason to be offensive, defensive, or feel the least bit attached to any particular product except to the extent that your paycheck comes from one of them. I teach for a university and my loyalty is to my students. If they wanted to learn Fortran IV I'd teach that to them. So no attempt was made or intended to insult you, IBM, DB2, or anything else. What was made was a staight-forward statement of fact based on my years working with DB2 and statements confirmed by others here in the DB2 forum. Please don't take any of this personally. You just can't take a DB2 app on Windows and move it to OS/390 without recompiling. That's not an insult ... it is a fact. -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply)

Daniel, The point is this: in order for a sw product to run successfully on Windows, AIX, Solaris, HP, etc. ... in fact ... there must be some differences in the code base. You can't possibly be right about the Oracle code base being 100% the same. And if you are, it exposes a major flaw. You wouldn't want the codebase the be 100% the same because if that is the case, your db is not fully exploiting the features of that platform. Windows threads vs. Solaris semaphones, Windows registry, HACMP on AIX vs. MSCS vs. HP Serviceguard. The internal features/functions, the APIs, the DDL and DML ...across Intel/UNIX/Linux are virtually the same. Larry Edelstein Daniel Morgan wrote: > Mark A wrote: > >> >> The DB2 code base for Windows, Linux and Unix is 90% the same. >> >> >> >> The MVS, VM , and AS/400 products are all different, which is not >> >> really a >> >> factor since either Oracle doesn't have a product on these >> >> platforms, or >> >> >> the >> >> >> if they do, the Oracle product is universally known to stink on >> >> these >> >> platforms. >> >> >> >> If you write stored procedures in C, you will need a compiler, >> >> but not >> >> >> sure >> >> >> if it needs to be on the production machine. But if you say so, >> >> I would >> >> concede that point. Stored procedures may also be written in SQL, >> >> which is >> >> the preferred method. With regards to the total cost of >> >> ownership, I think >> >> that you will find DB2 cheaper or the same as Oracle even with >> >> the >> >> >> compiler >> >> >> expense. >> >> >> > When you say "is 90% the same" isn't that just saying they are >> > different >> > without saying it? Sort of like trying to say you are 90% >> > half-pregnant. >> > >> > I don't think anyone should debate TOC as there are no standards by >> > which to judge the accuracy of the statement. Anyone that paid list >> > price >> > for any hardware or software should buy their next car from me. >> > Daniel Morgan >> > >> The code base for DB2 on Windows, Linux, and Unix is 100% the same >> except >> for those things that are operating system specific. Everything that >> is >> possible to be the same, is the same on DB2 and that calculates to >> about >> 90%. Operating system specific code for DB2 has been isolated into >> separate >> modules. >> >> The same is true of Oracle. Please don't insult my intelligence by >> claiming >> otherwise. >> >> > Sorry to say this but the code base for Oracle is 100% identical > between platforms. I can develop on Win98, export tables, data, code, > etc. Import directly to any other platform-operating system that > Oracle supports and it runs, perfectly, with zero modifications. > > The only difference I can possibly think of would be things that are > path specific such as c:\\temp changing to /opt/. > > It isn't about insulting your intelligence ... it is a fact. > > -- > Daniel Morgan > http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp > http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp > damorgan@x.washington.edu > (replace 'x' with a 'u' to reply) >

"Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message news:UjM8b.434976 > No, this was a production environment. In the days of client server GUI s > these might be "labled" ad hoc queries but in fact they were queries to run > a production system for NYNEX. The tool did not allow "binding" and without > issuing explicit commit statements after every select , insert, or update > statement everyone else would get locked out of issuing queries or binding > their plans for the production system. I thought mainframes were for > production quality code. (and so did ATT) > Jim > Developers should not be doing binds in a production environment.

"Daniel Morgan" <damorgan@x.washington.edu> wrote in message <snip> > You just can't take > a DB2 app on Windows and move it to OS/390 without recompiling. That's > not an insult ... it is a fact. > -- > > Daniel Morgan You can't do on Oracle either, because very few (if any) companies use Oracle on OS/390 to run their business (even though they have managed to sell a few hundred licenses). I once asked Oracle for references of Oracle on OS/390. They gave a list of 5 Fortune 100 companies. When I called the companies to get a reference, no one of the companies was actually using it.

>"Daniel Morgan" <damorgan@x.washington.edu > wrote in message news:1063490318.287901@yasure... >Sorry to say this but the code base for Oracle is 100%> > identical between platforms. -- >Daniel Morgan The 10% of DB2 code that is different between OS's is the OS specific stuff. There is a lot of OS specific stuff like disk I/O (especially to raw devices) and how the programs uses processes vs. services, security, etc. You seem to lack fundamental knowledge of the products interface with the OS. Oracle does it the same way.

>"Daniel Morgan" damorgan@x.washington.edu >wrote in message news:1063490424.999085@yasure... >Well I know I was running Oracle on Amdahl's at Boeing >a few years back and likely they still do. But I agree. >If anyone has followed this thread ... they should remember >as I have pointed out ... my comment was directed >to DB2 on Windows and a statement that I wouldn't recommend> > it. I said nothing about OS/390 or AS/400. >Daniel Morgan Since version 7.2 DB2 for WIndows is an excellent product. Even better with version 8.1. I would not recommend DB2 AS/400 except that if you already have an AS/400 there probably are no other choices.

"Mark A" <ma@switchboard.net> wrote in message news:wGM8b.797$TJ.83525@news.uswest.net... > "Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message > news:UjM8b.434976 > > No, this was a production environment. In the days of client server GUI s > > these might be "labled" ad hoc queries but in fact they were queries to > run > > a production system for NYNEX. The tool did not allow "binding" and > without > > issuing explicit commit statements after every select , insert, or update > > statement everyone else would get locked out of issuing queries or binding > > their plans for the production system. I thought mainframes were for > > production quality code. (and so did ATT) > > Jim > > > Developers should not be doing binds in a production environment. > > Doesn't matter, in order for them to get the programs from one environment to another they needed to compile their code in production to bind it. (according to that group) It was a large company and we were just a small part of one group. (It was a mainframe after all.) The point being DB2 was poorly designed with respect to concurrency. No reason more than one person should not be able to bind at a time. It means that "ad hoc" or dynamic sql on DB2 means everyone serializes behind it. That is very very ugly. Sure one can administratively work around it by telling everyone not to use a feature of the database, still it is a severe limitation. Jim

"Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message news:KZM8b.440312$uu5.78501@sccrnsc04... > > "Mark A" <ma@switchboard.net> wrote in message > news:wGM8b.797$TJ.83525@news.uswest.net... > > Developers should not be doing binds in a production environment. > > > > > Doesn't matter, in order for them to get the programs from one environment > to another they needed to compile their code in production to bind it. > (according to that group) It was a large company and we were just a small > part of one group. (It was a mainframe after all.) The point being DB2 was > poorly designed with respect to concurrency. No reason more than one person > should not be able to bind at a time. It means that "ad hoc" or dynamic sql > on DB2 means everyone serializes behind it. That is very very ugly. Sure > one can administratively work around it by telling everyone not to use a > feature of the database, still it is a severe limitation. My point of raising the issue of bind was to demonstrate what a law unto itself IBM is, using this (warning, red-rag phrase alert!) dated concept beyond its sell-by date. I suppose we only comment upon it unfavourably because, er, well, because we comment upon it unfavourably. If it were some killer piece of functionality that set DB2 UDB above the herd, we'd talk about in awesome tones .... A personal take on the wider debate is that DB2 UDB sites are few and far between here in the UK, so far as our market and sales team can tell. We come at this subject from the Informix side. Of course, many customers are abandonning Informix because of the negative vibes they are getting from ISVs, or maybe from IBM themselves. Will they go to DB2? Well, presumably they chose Informix because they had some good reason not to go with the market leader. That strategy has bitten them in the arse. Surely they aren't going to risk obsolesence again by choosing another marginal player in the UNIX/Linux/NT space? And, irrrespective of its merits - and I write as a DB2 UDB certified professional - that's what DB2 UDB is in this space.

"Neil Truby" <neil.truby@ardenta.com> wrote in message news:bk0e3j$il8he$1@ID-162943.news.uni-berlin.de... > My point of raising the issue of bind was to demonstrate what a law unto > itself IBM is, using this (warning, red-rag phrase alert!) dated concept > beyond its sell-by date. > > I suppose we only comment upon it unfavourably because, er, well, because we > comment upon it unfavourably. If it were some killer piece of functionality > that set DB2 UDB above the herd, we'd talk about in awesome tones .... > > A personal take on the wider debate is that DB2 UDB sites are few and far > between here in the UK, so far as our market and sales team can tell. We > come at this subject from the Informix side. Of course, many customers are > abandonning Informix because of the negative vibes they are getting from > ISVs, or maybe from IBM themselves. Will they go to DB2? Well, presumably > they chose Informix because they had some good reason not to go with the > market leader. That strategy has bitten them in the arse. Surely they > aren't going to risk obsolesence again by choosing another marginal player > in the UNIX/Linux/NT space? And, irrrespective of its merits - and I write > as a DB2 UDB certified professional - that's what DB2 UDB is in this space. > You seem to be judging the databases based on market share. Maybe in the UK DB2 is not popular, but in the US it is doing very well against Oracle. MS SQL Server is also doing well. Oracle is loosing market share, which is not surprising since the pretty much owned the market at one time. But again, your UK experience is not the same as in other countries.

You can't compare choosing IBM vs. choosing Informix. IBM is not likely to go out of business or be taken over by another company. The market share #'s are much closer than you indicate. The idea of using market share is blown way out of proportion. Other factors being equal, would you not buy a Toyota over a Nissan if you found out that Toyota had say 20% of the market and Nissan had 25%? Would you not buy a Panasonic television over a Sony if you found out that Panasonic had a 30% market share and Sony had a 25% share? The bottom line is you evaluate the product on its merits ... you evaluate the suitability of the database to your environment/applications ... you evaluate the vendor on its merits ... and you make a decision. What you CARE about is not whether the market share of vendor A is 3% more than vendor B ... you care about whether the vendor is going to be there to support you in the future ... and whether that vendor is likely to continue to invest in their products. Neil Truby wrote: > "Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message > news:KZM8b.440312$uu5.78501@sccrnsc04... > > > > "Mark A" <ma@switchboard.net> wrote in message > > news:wGM8b.797$TJ.83525@news.uswest.net... > > > > Developers should not be doing binds in a production environment. > > > > > > > > Doesn't matter, in order for them to get the programs from one environment > > to another they needed to compile their code in production to bind it. > > (according to that group) It was a large company and we were just a small > > part of one group. (It was a mainframe after all.) The point being DB2 > was > > poorly designed with respect to concurrency. No reason more than one > person > > should not be able to bind at a time. It means that "ad hoc" or dynamic > sql > > on DB2 means everyone serializes behind it. That is very very ugly. Sure > > one can administratively work around it by telling everyone not to use a > > feature of the database, still it is a severe limitation. > > My point of raising the issue of bind was to demonstrate what a law unto > itself IBM is, using this (warning, red-rag phrase alert!) dated concept > beyond its sell-by date. > > I suppose we only comment upon it unfavourably because, er, well, because we > comment upon it unfavourably. If it were some killer piece of functionality > that set DB2 UDB above the herd, we'd talk about in awesome tones .... > > A personal take on the wider debate is that DB2 UDB sites are few and far > between here in the UK, so far as our market and sales team can tell. We > come at this subject from the Informix side. Of course, many customers are > abandonning Informix because of the negative vibes they are getting from > ISVs, or maybe from IBM themselves. Will they go to DB2? Well, presumably > they chose Informix because they had some good reason not to go with the > market leader. That strategy has bitten them in the arse. Surely they > aren't going to risk obsolesence again by choosing another marginal player > in the UNIX/Linux/NT space? And, irrrespective of its merits - and I write > as a DB2 UDB certified professional - that's what DB2 UDB is in this space.

Peter wrote: > > Please wait and see DB2 instance all of sudden disappearing from > your production system with a simple select usage. I am not > anti DB2 but I am telling you the fact. > Please - can I have DDL to create table and text of simple SELECT statement which can remove DB2 instance from production server? Jan M. Nelken jasinek at attglobal dot net