Hi,
 don't think so . Had this problem some years ago on aix-tsm 5.1.x server
and now actually the same on solaris-tsm 5.3.2.1 server.

When migrating from aix to solaris I first thought this problem
has evacuated. Moving our cyrus-mail-server on the new platform
the restore was continously very good - even after 8 months
( we have retver=45 ) . The data to be restored is located
on 2-4 tapes (3592) and disk-cache.
The relation between aktive - inactive files for this node is about
4.2 mio aktive files  + 1.1 mio inactive files.
Because of the fantastic new drives we did not do any tape-reclamation
and we had no problems at all.
Because my collegue who normally do the restorals on mail-folders
( mostly just some hundred files up to some thousand using
a restore command like   ' dsmc restore /mail/imap/x/user/xuser/remfolder/ ' )
is sitting vis-a-vis I know that the restore-performance was always very good.
Then I said to him   -ohhh we should use the tapes a bit more before
running out of warranty-  and started some reclamations on tapes
being full and with a usage of lets say 20% or less.
Thus one of the tapes the mail-server-tsm-client has data on
( the storagepool has node-collocation) has reclaimed ...
... and uuuuuups  : the old problem ( waiting for files ...) suddenly arised 
again.
So another 'workaround' might be not to use reclamation ;-)

Greetings
Rainer


"Whitlock, Brett" wrote:
>
> Is this problem platform specific?
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Richard Sims
> Sent: Friday, February 24, 2006 9:47 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] AW: (Too) long no query restore?
>
> Ironically, the most crucial part of the TSM product - restoral - has
> become its most troublesome.  Since the advent of the well-intentioned
> NQR, when customers perform qualified restorals they never know what to
> expect in terms of restoral speed.
> Indeed, restorals can end up being prohibitively long.
>
> I'm incredulous that IBM *still* has not tackled and resolved this
> long-festering problem in the product, which has simply lingered for
> years now.  Descriptive APARs and Technotes only tell of alternatives
> for when the customer runs into a debilitating restoral, but we see no
> initiative to address the architectural problems.  TSM is an Enterprise
> level product, and yet a crippling problem of this severity remains in
> it?
> Not good.
>
>     Richard Sims
>
> On Feb 24, 2006, at 10:22 AM, Rainer Wolf wrote:
>
> > Hi,
> >
> > I often experienced this and was in discussion with IBM - at last it
> > was closed by ibm-support with a point to
> > http://www-1.ibm.com/support/docview.wss?uid=swg1IC34713
> > IC34713: PERFORMANCE
> >          DEGRADATION WHEN
> >          RUNNING NO QUERY
> >          RESTORES
> > I don't know why this old one is still active ( tsm 4.2 ) ??
> >
> > In our case the performance-problem arised at that point when the
> > first reclamation-process has run on a tape on which the client has
> > data on ... maybe also by hazard.
> > For me that problem sometimes seems to be the most alarming one in
> > TSM.
> >
> > Greetings
> > Rainer

--
------------------------------------------------------------------------
Rainer Wolf                          eMail:       rainer.wolf AT uni-ulm DOT de
kiz - Abt. Infrastruktur           Tel/Fax:      ++49 731 50-22482/22471
Universitaet Ulm                     wwweb:        http://kiz.uni-ulm.de