ADSM on the mainframe use to use DB2 and they killed it because of the cost
to the customer, both maintaining another product and the actual license
cost.  The TSM relational engine is optimized for TSM processing.  A general
relational database cannot hold a candle to the performance differences on
equal hardware.  The other issue is Tivoli does not want you mucking around
in the tables updating them with update commands.  The referential integrity
is paramount to TSM stability.  The real missing piece in TSM's DB engine is
the ability to partition the database and parallel backup/restore.  More
important is the 4K block size that kills IO performance on sequential
operations such as a backup/restore.  I think Tivoli will see the need and
do something about it.  These have been discussed at Share.

You will find that "black box" is what most customers require to protect
themselves.  I realize if they used a general RDBMS that we could extend the
code of TSM significantly further than with the current command
capabilities.  But, that is exactly what they want to prevent.  You end up
with large customers developing extensions that are impacted by Tivoli
architectural changes that carry a loud voice about making changes that
affect them and thus prevent progress.  I am one of them, trust me it
happens.

This all said.  If you can define the requirements that a RDBMS would solve
for you that I have not mentioned, we will carry those requirements forward.

Paul D. Seay, Jr.
Technical Specialist
Naptheon, INC
757-688-8180