Company thought DB2 will be better than Oracle.

[Peter]

Company thought DB2 will be better than Oracle.
The bottom line is when you do select, the system crash.

I think it may take 4-5 years for DB2 to reach Oracle standard.
Peter

[Larry]

Hmmm. So ... no details. No version/release levels ... no platform
information. No details on what you were trying to do. No details on the
application. No details on the crash. No details on what the corrective
fix was. You're obviously more experienced with Oracle. And you're ready
to pass judgement on DB2 already?

Larry

Peter wrote:

Company thought DB2 will be better than Oracle.
The bottom line is when you do select, the system crash.

I think it may take 4-5 years for DB2 to reach Oracle standard.

Peter

[Mark A]

"Peter" <pe****************@yahoo.com> wrote in message
news:39**************************@posting.google.c om...

Company thought DB2 will be better than Oracle.
The bottom line is when you do select, the system crash.

I think it may take 4-5 years for DB2 to reach Oracle standard.
Peter

Maybe it's a problem with the DBA's.

[Simon Verona]

sorry, this is comp.databases.PICK???????????

--
==============================
Simon Verona
si***@aphroditeuk.com
==============================
"Mark A" <[e-mail]> wrote in message
news:pr****************@news.uswest.net...

"Peter" <pe****************@yahoo.com> wrote in message
news:39**************************@posting.google.c om...

Company thought DB2 will be better than Oracle.
The bottom line is when you do select, the system crash.

I think it may take 4-5 years for DB2 to reach Oracle standard.
Peter

Maybe it's a problem with the DBA's.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 28/08/2003

[Mark Townsend]

Larry wrote:

And you're ready to pass judgement on DB2 already?

Surprised it took that long ? :-P

[efiryago]

"Simon Verona" <ne**@aphroditeuk.com> wrote in message news:<bj**********@hercules.btinternet.com>...

sorry, this is comp.databases.PICK???????????

--
==============================
Simon Verona
si***@aphroditeuk.com
==============================
"Mark A" <[e-mail]> wrote in message
news:pr****************@news.uswest.net...

"Peter" <pe****************@yahoo.com> wrote in message
news:39**************************@posting.google.c om...

Company thought DB2 will be better than Oracle.
The bottom line is when you do select, the system crash.

I think it may take 4-5 years for DB2 to reach Oracle standard.
Peter

Maybe it's a problem with the DBA's.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 28/08/2003

In the past, I had experienced DB2 V7.2 on Linux RH7.2 instance
crashing just from select too. IBM tech support wasn't able to fix
that so I had to find a workaround on my own at the app level. Hope
that V8.1 is more stable :-))

[Mark A]

> In the past, I had experienced DB2 V7.2 on Linux RH7.2 instance

crashing just from select too. IBM tech support wasn't able to fix
that so I had to find a workaround on my own at the app level. Hope
that V8.1 is more stable :-))

DB2 version 8.1 works quite well on RH Linux 7.2 or 8. I don't for one
second believe your version of what happened.

[Larry]

Let's put it this way ... I'd like to hear the entire story. The
application, the version/release levels, the PMR number, the error
message, the select statement, full details on the hardware and software
environment, the os levels, all patch levels, etc.

Larry

Mark A wrote:

In the past, I had experienced DB2 V7.2 on Linux RH7.2 instance
crashing just from select too. IBM tech support wasn't able to fix
that so I had to find a workaround on my own at the app level. Hope
that V8.1 is more stable :-))

DB2 version 8.1 works quite well on RH Linux 7.2 or 8. I don't for one
second believe your version of what happened.

[smartdba]

But not as quickly as a certain large HR software company passed
judgement on a certain RDBMS vendor :-)

Mark Townsend wrote:

Larry wrote:

And you're ready to pass judgement on DB2 already?

Surprised it took that long ? :-P

[Noons]

"Mark A" <[e-mail]> wrote in message news:<pr****************@news.uswest.net>...

"Peter" <pe****************@yahoo.com> wrote in message
news:39**************************@posting.google.c om...

Company thought DB2 will be better than Oracle.
The bottom line is when you do select, the system crash.

I think it may take 4-5 years for DB2 to reach Oracle standard.
Peter

Maybe it's a problem with the DBA's.

x-post trimmed in the interests of sanity...
I thought DB2 didn't need DBAs, that was just another
"expensive option" needed only for Oracle?
Tsk,tsk, there goes the TCO crap...

Cheers
Nuno Souto
wi*******@yahoo.com.au.nospam

[Peter]

Friends!

I am not anti DB2. It is a good
database on Main Frames system.

System crash, if it has not happened on your
production server running DB2 so far, please
wait for 6-8 months.
Peter

wi*******@yahoo.com.au (Noons) wrote in message news:<73**************************@posting.google. com>...

"Mark A" <[e-mail]> wrote in message news:<pr****************@news.uswest.net>...

"Peter" <pe****************@yahoo.com> wrote in message
news:39**************************@posting.google.c om...

Company thought DB2 will be better than Oracle.
The bottom line is when you do select, the system crash.

I think it may take 4-5 years for DB2 to reach Oracle standard.
Peter

Maybe it's a problem with the DBA's.

x-post trimmed in the interests of sanity...
I thought DB2 didn't need DBAs, that was just another
"expensive option" needed only for Oracle?
Tsk,tsk, there goes the TCO crap...

Cheers
Nuno Souto
wi*******@yahoo.com.au.nospam

[Mark A]

> Friends!

I am not anti DB2. It is a good
database on Main Frames system.

System crash, if it has not happened on your
production server running DB2 so far, please
wait for 6-8 months.
Peter

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. All systems have problems occasionally, just ask Ebay
about their outages caused by Oracle crashes and hangs.

If you personally had problems that could not be resolved with IBM support,
then maybe it was unique to your situation and use of the product.

[Database Guy]

Larry <ls*****@us.ibm.com> wrote in message news:<3F***************@us.ibm.com>...

Hmmm. So ... no details. No version/release levels ... no platform
information. No details on what you were trying to do. No details on the
application. No details on the crash. No details on what the corrective
fix was. You're obviously more experienced with Oracle. And you're ready
to pass judgement on DB2 already?

Larry

Peter wrote:

Company thought DB2 will be better than Oracle.
The bottom line is when you do select, the system crash.

I think it may take 4-5 years for DB2 to reach Oracle standard.

Peter

Troll, or part of a new Oracle marketing ploy?
DG

[Daniel Morgan]

Mark A wrote:

Friends!

I am not anti DB2. It is a good
database on Main Frames system.

System crash, if it has not happened on your
production server running DB2 so far, please
wait for 6-8 months.
Peter

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. All systems have problems occasionally, just ask Ebay
about their outages caused by Oracle crashes and hangs.

If you personally had problems that could not be resolved with IBM support,
then maybe it was unique to your situation and use of the product.

Just ask anybody about their crashes. What nonsense. Most systems crash
for the same reason most cars crash ... bad drivers.

But I'd stay away from promoting DB2 on Windows. I can't think of much
worse than a database with almost no built-in security on an operating
system with ... well ... almost no built-in security. Oracle and
Informix are far better choices if security is a concern.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Daniel Morgan]

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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Mark A]

> >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 jobsin 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.

[Peter]

I am only asking you to wait and watch on
production server of DB2 ,instance disappearance
because of select SQL query on a small table.
Peter

db******@hotmail.com (Database Guy) wrote in message news:<7f**************************@posting.google. com>...

Larry <ls*****@us.ibm.com> wrote in message news:<3F***************@us.ibm.com>...

Hmmm. So ... no details. No version/release levels ... no platform
information. No details on what you were trying to do. No details on the
application. No details on the crash. No details on what the corrective
fix was. You're obviously more experienced with Oracle. And you're ready
to pass judgement on DB2 already?

Larry

Peter wrote:

Company thought DB2 will be better than Oracle.
The bottom line is when you do select, the system crash.

I think it may take 4-5 years for DB2 to reach Oracle standard.

Peter

Troll, or part of a new Oracle marketing ploy?
DG

[Larry Edelstein]

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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Daniel Morgan]

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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Daniel Morgan]

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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Neil Truby]

"Daniel Morgan" <da******@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.

[Database Guy]

Larry Edelstein <ls*****@us.ibm.com> wrote in message news:<3F***************@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

[Larry Edelstein]

Which many people see as an advantage by the way ...

Larry Edelstein

Neil Truby wrote:

"Daniel Morgan" <da******@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]

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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

Larry Edelstein

[Neil Truby]

> Larry Edelstein

Neil Truby wrote:

You forgot to mention that lovely old IBM tradition, BINDing.

"Larry Edelstein" <ls*****@us.ibm.com> wrote in message

news:3F***************@us.ibm.com...
Which many people see as an advantage by the way ...

Please expand ..?

[Larry Edelstein]

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" <ls*****@us.ibm.com> wrote in message

news:3F***************@us.ibm.com...

Which many people see as an advantage by the way ...

Please expand ..?

[Daniel Morgan]

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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Noons]

db******@hotmail.com (Database Guy) wrote in message news:<7f**************************@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
wi*******@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.

[Jim Kennedy]

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" <ls*****@us.ibm.com> wrote in message
news:3F***************@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" <ls*****@us.ibm.com> wrote in message

news:3F***************@us.ibm.com...

Which many people see as an advantage by the way ...

Please expand ..?

[Mark A]

>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.

[Larry Edelstein]

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" <ls*****@us.ibm.com> wrote in message
news:3F***************@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" <ls*****@us.ibm.com> wrote in message
news:3F***************@us.ibm.com...

> Which many people see as an advantage by the way ...

Please expand ..?

[Larry Edelstein]

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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Peter]

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 <ls*****@us.ibm.com> wrote in message news:<3F***************@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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

--

[Mark A]

"Peter" <pe****************@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?

[Daniel Morgan]

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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Daniel Morgan]

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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Mark A]

>>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 theif 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 sureif 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 compilerexpense.

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.

[Mark A]

> 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).

[Larry Edelstein]

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 <ls*****@us.ibm.com> wrote in message news:<3F***************@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/e...ad/oad_crs.asp
> http://www.outreach.washington.edu/e...oa/aoa_crs.asp
> da******@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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

--

[Jim Kennedy]

"Mark A" <[e-mail]> wrote in message
news:CY****************@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

[Larry Edelstein]

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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Daniel Morgan]

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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Daniel Morgan]

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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Daniel Morgan]

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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Larry Edelstein]

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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Mark A]

"Jim Kennedy" <ke****************************@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.

[Mark A]

"Daniel Morgan" <da******@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.

[Mark A]

"Daniel Morgan" <da******@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.

[Mark A]

>"Daniel Morgan" da******@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.

[Jim Kennedy]

"Mark A" <[e-mail]> wrote in message
news:wG****************@news.uswest.net...

"Jim Kennedy" <ke****************************@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