Less tape-commits with server-processes like Backup Stg, Migration and Reclamation to improve throuput

TSM does a tape-commit (and thus a time-consuming backhitch on the tape drive) every time the backup-date, the nodename, the filespace or even the managementclass within a single filespaces of a single node changes.

This is regardless of / precedes the parameters you set for txnbytelimit on your client and txngroupmax, movebatchsize and movesizethres on your server.

Since TSM does not order the objects in a pool with the same criteria when moving to tape you can end up with much more time-consuming backhitches on your tape drives as expected.
So if 10 nodes with 10 filespaces each and 2 managementclasses used who backed up a total 10GB of data I would expect this to be written in a single pass to the tape drive. Since a tape drive with 360MB/s would write this 10GB in under 30 seconds.
Instead you get at least 10x10x2=200 tape commits each taking 0,5-4seconds each depending on your tape drives resulting in 10GB written in 30seconds+(200*0,5seconds)=130seconds or 80MB/s
But if the data is "interweaved" in the pool because the clients backuped simultaniously and/or with many threads you can easily end up with much much more tape commits.

When transferring data within a TSM-server
instead of doing tape-commits based on the structure of the data (backup-date, nodename, filespace, managementclass)
TSM should do tape-commits every x seconds or every x GB
resulting in fewer tape-commits, fewer tape-buffer underruns, backhitches and subsequently in a much higher throughput.