The fact that Tivoli hasn't delivered decent tools for the database
is what prompts all this discussion.  The question is why?  I will
assume that they would like to deliver good tools.  Since they haven't
I ask, why not?  My guess is that with the current blackbox private
database they just can't make the tools we need.  If they really put in an
extrordinary effort, they would end up just reinventing wheels, and
the current database may end up looking like a poorman's db2.

My original note quoted someone in Tivoli that the database in a standard
dbms would be for high-end customers.  I currently have 11.8 million pages in 
use
so I think I am high-end.  I expect to get to 20 million a year from now.
I am worried about scaling that high.  I know I could do it if the database
were multiple tables in db2.  Right now I don't know if a reorg is needed, but I
do know that I couldn't do it.  With db2 I would know if a reorg is needed and
I could do it.

Tivoli would be crazy to force everyone into db2 or oracle.  I just want an
option to go there if I think I could manage *sm better in a standard dbms.

--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <199911171236.HAA155602 AT acs4.bu DOT edu>, on 11/17/99
In <199911171236.HAA155602 AT acs4.bu DOT edu>, on 11/17/99
   at 07:36 AM, Richard Sims <rbs AT BU DOT EDU> said:

>I have to disagree with those who believe that a general purpose database
>package is appropriate to *SM, and agree with those who say that staying
>with the current database makes far more sense.  We all have enough to
>do in keeping up with *SM PTFs.  Imagine also having to worry about a
>whole regimen of maintenance for an accompanying database package.
>No thanks.

>However, there is some merit in the argument some have made that as to
>having a db package with a set of utilities to manage and recover the
>database.  Sadly, the database recovery facilities in *SM have been
>utterly neglected, completely disregarded by product managers who don't
>seem to care that enterprise customers are down for days recovering the
>*SM database because the recovery tools are so incredibly inefficient.
>It's always indifference to customer needs like this that cause the
>customer base to start looking for alternatives, as is evidenced in
>this database topic.

>       Richard Sims, BU