For starters most people will define spacetriggers to automatically expand
their DB and recovery log before it reaches 100% (do a help define
spacetrigger on dsmadmc cmdline). What this does is let you set a threshold
(say 80%) at which a process gets kicked off to create a new volume for your
DB or recovery log. Then TSM automatically does an extend on your DB or
recovery log and voila, TSM has more space to work with. I've always thought
this was kind of a patch personally because it insinuates you have unused
filesystem space sitting someplace for TSM to create volumes in. Why not
just make your recovery log that large in the first place if you have the
space?

Secondly, if your database is in roll forward mode, performing a DB backup
will reset the recovery log to 0 utilization. There is a mechanism you can
implement to cause a DB backup to kick off anytime your recovery log reaches
a certain threshold. This is done by setting a database backup trigger and
is for when your database is in roll-forward mode (you didn't specify
whether it was or wasn't. See 'help dbbackuptrigger' or look up "automating
database backups" in the admin guide). You need to make sure your threshold
isn't so high that the recovery log fills up before the DB backup completes
(i.e. 98% threshold is unlikely to work).

Now despite all this the recovery log still has a size limit.. 13GB.. and
TSM only automatically expands it to 12GB.. furthermore you may have your
recovery log on a filesystem that's even smaller in size and TSM can't
automatically expand a filesystem, it can only create volumes on it. so it's
still possible to hit 100% one way or another. The key here is identifying
why it's occurring despite having the above in place and addressing it. It
shouldn't really happen if you have the above in place and implemented
properly if you think about it.

Gerald Wichmann
Sr. Systems Development Engineer
Zantaz, Inc.
925.598.3099 w
408.836.9062 c