I find it useful to have the dsmsched.log file backed up.
That way if I have a user turn up with no backups for something after a
system crash, I can pull down the dsmsched.log from the TSM backups and see
why (believe me, it has happened before!)

SO instead of excluding the dsmsched.log, I bind it to a management class
that specifies SERIALIZATION=SHRDYNAMIC.   That tells TSM to go ahead and
back it up, whether it's changing or not.

(My management class name for this is "CHANGING", so to bind the file to
that ruleset, you specify:
INCLUDE  *:\...\dsmsched.log  CHANGING
in your dsm.opt file, or the appropriate client option set)

We use the same technique for other sequential log files; then you get a
backup of whatever is in there, up to the last few lines.

Do NOT use this technique for data bases, where change can occur in the
middle of the file.  It also won't work where the error is due to the file
being LOCKED, rather than being open for output.

Just another idea..
************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu

"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************