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:Eric-van.Loon AT KLM DOT COM]
> Sent: Thursday, October 18, 2001 7:44 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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:joachim.stumpf AT DATEV DOT DE]
> Sent: Thursday, October 18, 2001 08:09
> To: ADSM-L AT VM.MARIST DOT EDU
> 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" <CSSubash AT TELETECHINTL DOT COM> (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.
> **********************************************************************
>