Re: Company thought DB2 will be better than Oracle.
Date: 13 Sep 2003 13:56:03 -0700
Message-ID: <396cd6da.0309131256.1615ca98_at_posting.google.com>
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.
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_at_us.ibm.com> wrote in message news:<3F6350F3.2946747D_at_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_at_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_at_x.washington.edu
> > (replace 'x' with a 'u' to reply)
> >
>
> --
Received on Sat Sep 13 2003 - 22:56:03 CEST