>With the current limit of 5.3GB, and the steps we've all taken to work
>within that limit, I don't think many people will be hitting the 13GB limit
>all that quick. An incremental database backup will still flush the log,
>and, with 13GB, I think we'll be OK if we don't change the way we are doing
>our business.
Hi, Nick - I agree that a lot of us will be fine with a 13 GB limit: neither
you nor I anticipate getting near it in our processing. In the
abstract, though, I take the long-term view, over the whole base of the
product...
One can sum it up by saying that a gigabyte isn't what it used to be. It wasn't
that long ago when a mainframe with 64 MB of memory was awesome. A few years
later and here we are accustomed to servers with a couple of gigabytes of memory.
I remember IBM getting a reality check when I worked in a large corporation:
VSAM was architected without a realistic view of the future, and referenced its
data via a Relative Byte Address. Well, one day we added a disk to our
growing, VSAM-based IMS database and VSAM could not address it. Very big ouch.
13 GB may seem like a lot for the Recovery Log; but, then, the customers who
today are fighting the 5.3 GB limit thought that was plenty - until their
corporate data grew. Consider also that 13 GB is less than half the size of
today's hard drives, and that lends further perspective. And that we were
limited to 5.3 GB for years, instead of seeing it grow over the evolution of the
product.
>From the perspective of DP history, I see this boost as a modest improvement,
but yet another limit that larger customers will soon approach. Again, TSM
is supposed to be an Enterprise-level product, and as such should have far
more expansive architecture than it's currently exhibiting. As many customers
have been complaining, the TSM database has been the dominant constraining
element in the product, and sorely needs to be addressed by Tivoli.
Richard Sims, BU
