I completely agree with Richard on this.  This problem alone
(unreliable restore performance) has caused us a large amount of
grief, and some abandonment of the product here.  We definitely have
some departments who have stopped using TSM because of this.  Users
should not have to figure out whether to use DISABLENQR or not.  As
Richard says, we need a solution not just a workaround.

At 10:47 AM 2/24/2006, Richard Sims wrote:

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

--
Paul Zarnowski                            Ph: 607-255-4757
Manager, Storage Systems                  Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801    Em: psz1 AT cornell DOT edu