I agree with Steve.

The ADSM/TSM database structure is a pretty good transaction processor, and I 
commend the designers for that.  There is quite a lot of time and manpower
(person-power would be more PC, but I didn't think it'd get my point accross) 
invested in the current database by the developers, and it would be a pity to 
throw that out the window.  But who says we have to do that.  Let's discuss 
the possibility of a third party database as an option, similar to DRM being 
an option.  This way, both camps are happy with their product.

The current database also has some shortcomings.  I think that the 
introduction of an SQL interface at Version 3 is an example of how 
non-standard the design really is.  While we can now query some of the 
information using this method, I am suspicious that there is still a great 
deal more that is inaccessible.  This would lead me to believe that the SQL 
interface was really just a 'kludge'.  So I would hope the re-design of the 
database backend and incorporation of a commercial database might allow you to 
see the whole picture.

Also, this might lead to the capability to add data to the database.  I have 
been in a database corruption situation where we had to go back a week and do a 
point in time restore.  We lost a full weeks worth of backups which were _on 
tape_ because we couldn't add records back into the ADSM database about 
that data.

My suggestion is, don't cut this idea down without giving it some thought.  
It might not be useful in your environment, and that's fine, but if it 
increased performance by even 10%, I for one would be interested.