On Feb 14, 2005, at 4:03 PM, Thach, Kevin G wrote:

We see the exact same behavior when attempting to perform
multi-threaded
restores using the "resourceutilization" parameter and the maxnummp =
x.

As you say, some of the time it works as expected, sometimes it does
not. ...

What I think is going on in all this...
The amount of parallelism you can achieve in such a restoral is limited
by practical realities. Various IBM site Technotes supplement the
client manual in providing further insights into NQR restorals. For
example, recent Technote 1067365 says that the server starts sending
data to the client as soon as it comes up with some candidates, and
resumes plowing through the database. We all know how painful it is to
perform a Select on the Contents table, particularly in large TSM
servers housing hundreds of millions of files. Even running at non-SQL,
native database search speed, it's going to take time for the server to
gather up all the candidates - worse so as the restoral request is more
complex. (Some options cause fall-over to Classic Restore on the
client, which can make things even slower, as clients are usually less
powerful than a server system.) This is all to say that the entire list
of candidate files may not be available as the restoral starts - and we
would be complaining about restoral times if the scheme was that the
full list be constituted before the restoral process begins. The only
answer here may be dramatically better and far more modern database
technology, to better deal with the enormous object populations of
contemporary data processing - particularly as regulatory requirements
call for retaining more data than ever.

   Richard Sims