define snapdiff and other snap options on a per filesystem basis rather than per backup command

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Storage
Product - Tivoli Storage Manager (TSM) Family

For recording keeping, the previous attributes were:
Brand - Tivoli
Product family - Storage
Product - Tivoli Storage Manager (TSM) Family

Thank you for your suggestion however we will not be implementing a solution to your request in the next two years. If you would us to reconsider your request after the delivery of our next release, then please reopen the enhancement request or submit a new one .

Server 64bit RHEL5.6 TSM 6.2
Client 64bit RHEL5.6 TSM 6.2
when doing a scheduled backup you can only stipulate one option set which is applied to all filespaces.
so if you have a client which has the following mounted
/mnt/netapp/vol (snapdiff capable NFS mount)
/mnt/standardnfs/vol (non snapdiff capable NFS mount)
/mnt/localfs/vol (non snapdiff capable local mount)
I cannot create a single schedule that would back up all those mounts. I would have break it up into two schedules one for the snapdiff volumes and one for the non snapdiff volumes.
what I suggesting is either an option like
-snapdiff=available
where it would attempt a snap diff and if it couldn't would go back to a standard incremental
or
be able to define some thing like the following in the options file
SNAPDIFF /mnt/netapp/vol
similar to the automount or domain options.

Impact
As well as increasing the number of schedules, it also means it is trickier to run pre and post scripts for backups of the machine as a whole. eg if the DB data and logs are spread across these volumes it makes it trickier to put the db in backup mode and then into normal mode as you never know for sure which one will finish first.

Thanks for submitting this enhancement request, we did not see enough details in this requirement to have a significant discussion and a meaningful response, please provide more details about this requirement including the business reason (impact to SLAs, reduced RPO, simpler management etc.), technical functionality (what are you trying to achieve, and why do you think it should be done in this specific way, are you talking about a single server that has one filesystem residing on a netapp box, other local filesystems etc.), reason why current implementation and best practices aren't meeting those requirements and some additional details about their current environment (for example a TSM 6.2 server running on AIX, the client is running on RHEL etc.) we need these details to fully understand this requirement