Hi all

for the following question a user gave me an answer:

Where a file server is that cranky and can't be fixed, I would take
such file systems out of TSM scheduled backups and instead
conditionally run them from a client OS script which performed tests
on the viability of the served file system before unleashing a dsmc
Incremental on it. I would not expect TSM client software to contend
with unreliable file systems.

    Richard Sims

*******************************************************************************************

I mean, yes, I could just exclude those file spaces if I would have knew in 
advance. 

My question is: there are occasionally such file systems (I don't know what 
developpers are dowing), however it is hard to predict. 

But still my question:

How can I avoid that dsm simply stops further backups but instead how can I 
instruct dsmc not to backup such filespaces or how is it possible create some 
sort of "exclude" list. Nevertheles my question still remains: Why dsmc 
produces an internal program error? I was able to scan through all directories 
with a C or JAVA program. When there was a stale file handle my programs 
continued to scan the next file handle.

Also is there any PTF? What is the statement of IBM?

Thanks four your help
Regards
Werner Nussbaumer

*******************************************************************************************
*******************************************************************************************
*******************************************************************************************

Original Message:


> We have directories for which "ls" displays:
> 
> USER@IMAGE1: /data/test:==>ls -al
> ls: ./TST: EDC8134I Stale file handle.
> ls: ./TST.B0.AHO: EDC8134I Stale file handle.
> ...
> ...
> 
> When dsmc tries to backup this data, then the following error message is 
> displayed:
> 
> ********************************************************************************
> USER@IMAGE1: /home/user:==>dsmc
> IBM Tivoli Storage Manager
> Command Line Backup/Archive Client Interface
>   Client Version 5, Release 3, Level 0.0
>   Client date/time: 12.07.2005 13:15:43
> (c) Copyright by IBM Corporation and other(s) 1990, 2004. All Rights Reserved.
> 
> Node Name: IMAGE1
> Session established with server ADSM: MVS
>   Server Version 5, Release 1, Level 9.0
>   Server date/time: 12.07.2005 13:15:43  Last access: 12.07.2005 13:15:22
> 
> tsm> incr /data/test/*
> 
> Incremental backup of volume '/data/test/*'
> ANS1999E Incremental processing of '/data/test/*' stopped.
> 
> 
> Total number of objects inspected:        1
> Total number of objects backed up:        0
> Total number of objects updated:          0
> Total number of objects rebound:          0
> Total number of objects deleted:          0
> Total number of objects expired:          0
> Total number of objects failed:           0
> Total number of bytes transferred:        0  B
> Data transfer time:                    0.00 sec
> Network data transfer rate:            0.00 KB/sec
> Aggregate data transfer rate:          0.00 KB/sec
> Objects compressed by:                    0%
> Elapsed processing time:           00:00:03
> ANS1028S An internal program error occurred.
> ********************************************************************************
> dsmerror.log:
> 
> 12.07.2005 13:15:51 TransErrno: Unexpected error from GetFSInfo:statfs, errno 
> =
> 1134
> 12.07.2005 13:15:53 TransErrno: Unexpected error from lstat, errno = 1134
> 12.07.2005 13:15:53 PrivIncrFileSpace: Received rc=131 from fioGetDirEntries: 
>  /
> data  /test
> 12.07.2005 13:15:53 ANS1999E Incremental processing of '/data/test/*' stopped.
> 
> 12.07.2005 13:15:53 ANS1028S An internal program error occurred.
> ********************************************************************************
> 
> How it is possible to avoid that dsmc stops processing the backup when it 
> tries to backup a stale file?> 
> 
> Thanks for any help,
> regards
> Werner Nussbaumer