I do not have the definitive answer on this, but I suspect the documented
limit was put in place because larger values offer diminishing returns.
That is, adding more sessions might increase session count, but show no
significant increase in backup performance (or maybe even hurt overall
backup performance). Besides performance, I am not aware of any negative
impact to using a higher value, but neither can I endorse using a higher
value.

If you have a need for a higher limit on this setting, you should open a
requirement. If indeed you can run with a higher value (of 30, as you say)
such that the overall backup time is substantially shorter than using the
max value of 10, then perhaps there is rationale for raising the supported
value.

Other alternatives:

- Use multiple nodes and schedulers to back up the file systems
concurrently.

- See if specifying the file systems in the desired order in the DOMAIN
statement makes any difference.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

IBM Tivoli Storage Manager support web page:
http://www-306.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 06/05/2006
02:45:00 PM:

> Andy, et al.
> [Is anyone out there using RESOURCEUTILZATION n w/ n > 10 ??]
>
> Andy Raibeck's presentation @ Oxford's 2001 TSM Symposium
>    http://tsm-symposium.oucs.ox.ac.uk/2001/papers/
>    Raibeck.APeekUnderTheHood.PDF
> includes this table showing what will result from setting:
>
> RESOURCEUTILIZATION n Max.Sess. ProducerSess. Threshold(Seconds)
> --------------------- --------  ------------  ------------------
>    <default>   2      1      30
>    1      1      0      45
>    2      2      1      45
>    3      3      1      45
>    4      3      1      30
>    5      4      2      30
>    6      4      2      20
>    7      5      2      20
>    8      6      3      20
>    9      7      3      20
>    10      8      4      10
>   (undocumented:
>    11<=n<=100)   n      0.5n      10
>
> and also includes these warnings:
> Undocumented, internal values subject to change without notice.
> RESOURCEUTILIZATION > 10 is unsupported.
>
> Management discourages use of undocumented/unsupported settings,
> but I'm arguing that we need to specify RESOURCEUTILIZATION 30
> in order to effect efficient backups for our email servers:
>    4 IMAP servers, each w/4 CPUs, running linux client 5.2.3,
>    each backs up 15 FS sending ~200GB/night (compressed)
>    via 100Mb -> Gb ethernet
>    to our TSM 5.2.3 service's disk stgpool
>
> With RESOURCEUTILIZATION 10 specified, we never see more than 8
> simultaneous FS backups, and some of 8 large IMAP filesystems are
> always the last backups to start, serially after other smaller FS
> backups complete!  Testing w/ RESOURCEUTILIZATION 30 causes one
> client to start up 31 sessions enabling all 15 FS backups to start
> essentially simultaneously.  I expect the smaller FS backups will
> complete first w/ the 8 larger IMAP FS backups completing later, but
> w/ all FS backups for each client finishing faster because none will
> wait to start serially after other FS backups because insufficient
> backup sessions were started.
>
> Asking only for your own advice, recognizing IBM probably does not
> allow you recommend using unsupported/undocumented optional settings:
>
> Is my understanding of the unsupported/undocumented setting (w/ N>10)
> correct?  Are we risking some unanticipated problems trying to use
> RESOURCEUTILIZAION 30 to backup all four of these email servers
> simultaneously?  [I believe we have sufficient network bandwidth,
> disk I/O capacity and CPU's for TSM clients and service.]
>
> Is there some important reason that IBM did not choose to document
> and support N>10 for RESOURCEUTILIZATION?  [The higher settings would
> seem to be useful and appropriate for some high-bandwidth circumstances,
> or did I miss something?]
>
> Is there a simple way to specify the order in which FS are selected for
> backup when multi-threading is active?
>
> Thanks [hoping] for your advice!
> --
> Jim.Owen AT Yale DOT Edu   (203.432.6693)