Not flexible enough. What if just one very critical file fails, like an
Oracle table space file? Or a control file? I think RC=4 should be given
if there are *ANY* failures, but continue with the session, and we handle
the return codes in our scripts. Yes, it may mean more work for us, but I
don't see any other way that Tivoli can accomodate everyone's wishes. And
whatever they do, it should not be forced... we should have the option of
overriding.
Robin Sharpe
Berlex Laboratories
"Seay, Paul"
<seay_pd@NAPT
HEON.COM> To: [EMAIL PROTECTED]
cc: (bcc: Robin Sharpe/WA/USR/SHG)
10/18/01 Subject:
10:25 AM Return Code Changes with V4.2.1 TSM Clients
Please
respond to
"ADSM: Dist
Stor Manager"
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.
**********************************************************************
