I don't this a percentage or count is sufficient as they could still result in the un-reported failure to backup a critical file. If your backup include/exclude list is perfect, then a non-zero RC is a failure.
However, its not always possible to build a perfect include/exclude list. For instance, there may be some files, that are occationally exclusively used, that you want backed up whenever they are available. To do, this while still getting a valid RC, would require another include/exclude option such as OPTIONAL and OPTIONAL.DIR. If all backup failures were OPTIONAL files, then the RC code would be zero. On Thu, 18 Oct 2001, Seay, Paul wrote: > We need to make sure that TSM Development gets this right when they change > it. Typically software is developed this way: > > RC=0 is for when nothing goes wrong, > RC=4 nothing went wrong that is serious, > RC=8 serious failure condition, > RC=12 some kind of internal error. > > What Tivoli needs to do is allow us to define what number of files (or > percentage of files) not backed up cause a RC=4 based on the needs of some > of the customers and the same for RC=8. I personally would like to see an > option that causes a RC=4 if a file misses a backup more than x number of > times in a row. That way I can determine it is not happening and take > action to either place it in a separate backup process when it can be backed > up and exclude it from the timeframe it is not available to be backed up. > > What does everyone think? > > -----Original Message----- > From: Loon, E.J. van - SPLXM [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 18, 2001 7:44 AM > To: [EMAIL PROTECTED] > Subject: Re: FW: v4.2.1 TSM Clients > > > Hi Joachim! > Jeff Connor had Tivoli open APAR IC31844 for this. > Kindest regards, > Eric van Loon > KLM Royal Dutch Airlines > > > -----Original Message----- > From: Stumpf, Joachim [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 18, 2001 08:09 > To: [EMAIL PROTECTED] > Subject: Fw: FW: v4.2.1 TSM Clients > > > I think it's true! > > I tested the new client on a W2k machine and I got the same RC you described > below. > If one file fails (e.g. it's in use by another proccess), the schedule > returns with a result code of 4. > > I hope Tivoli works on a fix for that. > We have some automatically checking for result code <> 0 (if there was > a problem while backing up; and I think "file in use..." isn't a big > problem) > > regards, > Joachim Stumpf > Datev eG > > "Subash, Chandra" <[EMAIL PROTECTED]> (Donnerstag, 18. Oktober 2001, > 06:41:31, MEST): > > > i HAVE GOT THIS EMAIL FROM ONE OF MY FRIENDS. GUYS WHAT DO YOU THINK IS IT > > TRUE ? > > > > Hi Guys > > > > According to Tivoli Support they have made an alteration to way client > > v4.2.1 reports Result code 4 to the server. Earlier version clients would > > allow for a certain number of files to fail during the backup and still > > report to the server that the Schedule was successful. However version > 4.2.1 > > has been altered so that a result code of failed will be reported to the > > server even if 1 file fails during a backup. > > ntcmachine had been failing on some WINNT system files which I have added > > exceptions for under direction of Tivoli support and now backups of this > > machine seem to be successful. > > Bob from Tivoli suggested that if we are worried about seeing failed > result > > codes on the daily report that there may be a way to generate a report > > listing statistics of how many files or how much data had been backed up > > from each machine to provide a more accurate picture as to whether the > > backups were successful. > > > > -- > > > > > ********************************************************************** > This e-mail and any attachment may contain confidential and privileged > material intended for the addressee only. If you are not the addressee, you > are notified that no part of the e-mail or any attachment may be disclosed, > copied or distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have received > this e-mail by error, please notify the sender immediately by return e-mail, > and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its > subsidiaries and/or its employees shall not be liable for the incorrect or > incomplete transmission of this e-mail or any attachments, nor responsible > for any delay in receipt. > ********************************************************************** >
