Could this be affecting you??



The problem that you could be facing is the following:
 APAR= IC36543  SER=                            IN INCORROUT
 TSM CLIENT NQR (NO QUERY RESTORE) CAN TERMINATE IMPROPERLY
 IF THE RESTORE IS INTERRUPTED BY A DISK FULL/QUOTA CONDITION
.
If a TSM client no query restore (NQR) is being performed and is
interrupted due to a disk full condition (possibly caused by
disk quota management at a directory level), recovery from this
condition will prematurely terminate the NQR processing.  When
the TSM client resumes the NQR operation after the disk full
condition is corrected, the TSM server will terminate the
restore.  The TSM client will indicate it is done with the
restore as well, showing final statistics as if the restore had
completed.  However, the restore has not finished restoring all
objects yet, and potentially several files/folders could be
missing.
.
The NQR operation should properly continue from the point of
interruption after recovering from the disk full condition, and
not terminate as observed above.
.
This was observed on TSM 5.1.6 client for Netware and TSM server
5.1.x.
Initial Impact: High
LOCAL FIX:
Perform the restore again.  If possible, do not impose disk
quotas until after the TSM client restore operation is complete.
NOTE: V5.1.6.0 is the same code at V5.2.0.0 when refering to
fixes include.
.
There is a fix for this in V5.1.6.7 but there is no fix for this yet for
V5.2.0.0
code. Development should have a fix within a month or so(Estimate).
...
The problem you are probably getting is due to some disk quotas on
the netware filesystem/directory level. You are probably getting out of
disk conditions...
.
The following workaround could be used, add the following to the dsm.opt
file:
test disablenqr





At 03:51 PM 10/7/2003 -0400, you wrote:

Hi TSMers...

I've got a system here running Novell Netware 5.1 SP6, with
TSA500.NLM at 5.0.5d, TSANDS.NLM at 10110.95, and SMDR at 6.50c,
using the web client at version 5.2.0.0 to manage a restore process
to an alternate directory.  Here's the catch:

About 75% (of 2000) of the files that we're attempting to restore
fail with an error that says that the file could not be written, with
no reason code.  The users still appear to exist, and the other 25%
of the files restore without an issue.

We've tried everything we could think of to try and troubleshoot the problem:
        Extensive searches of the ADSM archive for 2003.
        Verified that the account running the client acceptor had
sufficient privs.
        Checked to see that the TSM server activity log for errors.
        Checked the web client error log, but got very non-descriptive
errors.
        Verified that we weren't trying to restore compressed files
to non-compressed volumes.
                (...and vice versa)
        Looked for maintenance for the Novell Client (there was none).
        Looked for patches (there was one with a non-applicable fix).

If anyone has any insight into this issue, either methods to more
accurately determine the cause of the error, or versions of the NLM's
that need upgrades, it would be greatly appreciated.

-JD.