Re: Adjusting to DB2

Serge Rielau apparently said,on my timestamp of 26/10/2005 5:22 PM:

> Let me try to clarify a few things as unpassionately as possible hoping
> I don't break more dishes than I want to mend.

oh boy! Batten down, there is a storm coming... :)

> 1. When talking about one code base for DB2 for LUW what is referred to
> is the DB2 for LUW DBMS. Anything but the DBMS are applications built on
> top of DB2. Really they are separate products grouped together using the
> DB2 brand. Thsi includes the extenders, such as the spatial extender.
> Of course the underlying DB2 DBMS features are supported on all
> platforms and on all editions which DB2 DBMS supports.

<double crash>
why on Earth can the "underlying DB2 DBMS features" be supported on all platforms and on all editions but the actual "separate products" can't?

Ah yes: because they are all part of the "same codebase" that makes up the "single product" that is the "same everywhere". But somehow, somewhere, always *not quite* the same....

Hmmmm-mmmm! Of course.

> To be entirely correct I have to not eone exception: DATALINKS.
> DATALINK, by their very nature deeply interact with the OS and the
> filesystem. I presume the same must be true for the matching Oracle
> technology.

Lost me: haven't a clue what DATALINKS does.

> So DB2 DBMS is the same codebase across all Linux platforms, HP UX, Sun
> OS, AIX and Windows. There is a thin layer <<10% called Operating
> Systems Service (OSS) which encapsulates each and every interaction with
> the OS or any devices.
> As a direct result of this DB2 does not need to get ported to be shipped
> across all platforms. Ports to new platforms (e.g. if IBM decided to
> support Apple) are possible within a few weeks and can occur at a
> servicepack level. Also th eplatform support team can be comparatively
> small.

This reminds me so of the old Oracle V4 internals slides! Only 20 years ago but the same old concept is there: onion-like structure, inner 10% of layers are ported, the rest just re-compiled. Obviously someone at IBM got hold of all those overhead slides of ages ago and is milking them for all it can give.

Completely forgetting this is 2005. With all the unfortunate crap we have to deal with nowadays.

Here is a hint: just on small version-to-version differences of the *compilers* over each platform - and sometimes in the *same* platform! - you got enough to keep a full time porting group flat out for ALL the code. Let alone the bits that are specific to each port!

Calm down, old fella: talking to granny when it comes to porting efforts, K? Don't jump up and down, it shakes the foundations and more stuff will fall off the shelves. ;)

> I know from reliable sources that the porting teams at Oracle are a lot
> bigger.

I know from reliable sources that development teams at IBM are known as Cecil B. de Mille teams:

"with a cast of thousands".

I must admit: my last experience with them was with 27 DBAs and half as many middle "managers" in a project with 4 coders.

It failed, of course. Except for the subsystem my group did. But heck, what can I say: apparently I was "too dangerous" to have around...

> DB2 gets very few platform specific APARs due to this encapsulation.

The expression "least-common denominator" springs to mind...

> 2. Talking of extenders and DB2 branded tools such as intelligent miner:
> (We do not call these features, maybe they are called as such in Oracle)

No, you folks call them separately priced products. Which never make it to the TCO comparisons but somehow all customers end up having to buy anyway. Otherwise the darn thing is next to useless. Another "reliable source"...

> simply is no HP demand. Again thsi has nothing to do with single
> codebase. This is about enablement and support.

Agreed.

> 3. DB2 Editions
> Not all editions are supported on all platforms with all features.
> Of course!

I beg your pardon? Why on Earth NOT?
(please, don't waste our collective time with the usual marketing nonsense about what each OS can support or not. K?)

> All in all I think this part of the thread has been quite a divergence
> from teh OP's question since none of the properties above have anything
> to do with the effort for an Oracle DBA to become skilled in DB2.

Ding. As usual, spot-on. Sometimes with a crash or two. But not bad.

-- 
Cheers
Nuno Souto
in sunny Sydney, Australia
wizofoz2k_at_yahoo.com.au.nospam