Re: Adjusting to DB2

Noons wrote:
> 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?

I didn't say "can't". Let's use Oracle as an example. Oracle DBMS is supported on many platforms, right? Let's have a look at Oracle Collaboration suite. it sues Oracle DBMS (even shares the same Release numbers as far as I can tell). Checking out the download section I see that Oracle Collaboration Suite is supported for:

Oracle Collaboration Suite 10g Release 1 (10.1.1.0.2) Oracle Collaboration Suite 10g Release 1 (10.1.1.0.2) for HP-UX PA-RISC (64-bit)
Oracle Collaboration Suite 10g Release 1 (10.1.1.0.2) for Linux x86 Oracle Collaboration Suite 10g Release 1 (10.1.1.0.2) for Solaris Operating System (SPARC 32-bit)
Oracle Collaboration Suite 10g Release 1 (10.1.1.0.2) Clients

Oracle Collaboration Suite Release 2 (9.0.4.1.1) Oracle Collaboration Suite Release 2 (9.0.4.1.1) for Microsoft Windows

Now, let's not dwell on the fact that Windows still doesn't seem to be supported on 10g at all and that the downloads are for 10gR1 only. The point being that there are Oracle products which apparently are not supported on all platforms. No Mac, no AIX (huh?). I doubt that's a "can't". It's more likely a quite rational business decision. A Windows customer is likely to run Exchange, why would they put Oracle in there?

> 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....
So Oracle isn't teh same across all platforms because Oracle Collaboration suite isn't supported on Mac? Keep in mind teh difference between a codebase and branding. Things can be under the same brand, yet be different produ ts, tools, etc,...
>> 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.
Good. So we agree noone cares about that one ;-)

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

Clearly encapsulation was invented by Oracle the day after they asked for access for IBM's SQL codes. I don't know why the porting team of Oracle is so big. Ask Mark T. or Tom Kyte.

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

That's what coding standards are for. And that's what nighly builds across all platforms are there for.
DB2 engine development is done on Windows, AIX, Linux and Sun (inherited machined from Informix). You break the coding standards and hence a platform: No soup for you...
For Linux and AIX compiler problems are easily solved: fix em. AIX C-Compiler gang is downstairs.
In general compilers upgrades don't cause that many problems.

> 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. ;)
Apparently so. This isn't the day when the first C++ compiler rolled out. C/C++ is quite mature.

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

I can't comment on IGS doing custom apps which is what you appear to be taare talking about.
SWG is different. IBM SWG presently is the #2 sofware vendor by revenue (not sure how the Siebel deal changes things once it's done). You don't get there by being inefficient.

>> DB2 gets very few platform specific APARs due to this encapsulation.
> The expression "least-common denominator" springs to mind...
For C-compilers absolutely. For API's no. Encapsulation does not prevent exploitation.

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

What percentage of customers use Spatial on Oracle or whatever passed for the video and image extenders? Also separately pricing is not anything new to an Oracle person. Range partitioning is priced separately in Oracle last I recall, and of course RAC. Posters in thsi NG have gone through great length describing their attempts to work around having to buy the licence. Whenever one compares prices one must consider all the needs. Making a decision based on teh bare-bones price and being surpised by the "hidden fees" is as bad as having to pay for features one will never use.

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

No, nothing about what can be supported. Editions are picing schemes. I would be curious to know whether anyone ever tried to order Oracle SE 1 for Linux/zOS or HP OpenVMS Alpha

Cheers
Serge

-- 
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab