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: > > [EMAIL PROTECTED]: /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: > > ******************************************************************************** > [EMAIL PROTECTED]: /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