Thank you for your answer. In my opinion if 99.9 percent of the files are backupable then TSM should backup them. If it tries to backup a file and the system returns any error condition it should simply pass an information about this and should try the next file. I don't want TSM to evaluate any consistency, but if for example a file space is not correctly mounted it should ignore this one.
Regards Werner Nussbaumer -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of Richard Sims Sent: Donnerstag, 10. Februar 2005 13:23 To: [email protected] Subject: Re: Tivoli Client stops processing when file is corrupt On Feb 10, 2005, at 4:55 AM, Werner Nussbaumer wrote: > > We use Tivoli Storage Manager Client for z/OS OMVS (USS / UNIX) > Version 5, Release 1, Level 6.0. > > How can we avoid that when a file is corrupt that the Tivoli client > just ignores this file and proceeds instead of stopping / crashing? As you intimate, client failure should not happen. You could try boosting your older client level and see if that resolves it. Else contact TSM Support to seek resolution of the defect causing the crash. Beyond, that, consider TSM the "canary" informing you of bad conditions in your data mine. Something like that is a symptom of something very wrong in the environment that needs to be corrected. Some perspective, too: It's TSM's assigned task to back up collections of bits which it is told to, not judge them. There are some obvious file conditions which result in OS file system errors to which the TSM client application can react, but beyond that, TSM can't be expected to evaluate the consistency of files or datasets created by other applications is it proceeds with Backup. Sometimes, "corrupt" is subjective. Richard Sims
