ADSM-L

Re: Return Code Changes with V4.2.1 TSM Clients

2001-10-24 11:44:53
Subject: Re: Return Code Changes with V4.2.1 TSM Clients
From: Andrew Raibeck <storman AT US.IBM DOT COM>
Date: Wed, 24 Oct 2001 08:40:59 -0700
ADSM and TSM have always made the assumption that skipped files during he
course of an incremental backup are "normal", and thus should not
constitute a failed event (barring any other, more serious errors). As
I've stated before, the 4.2.1 return code change was unintentional, and is
being handled as a defect (APAR IC31844). A patch is expected to be
available in the near term that incorporates the fix for this problem.

While I am not permitted to make any formal announcements or commitments
regarding new features, I will say that we are looking at making it easier
to distinguish between successful backups that had 0 skipped files, and
successful backups that had 1 or more skipped files. The approach is not
going to be quite as elaborate as suggested below, but it will certainly
be an improvement. Associated with this change is that the command line
client will (finally!) issue a valid return code, which should make script
writers a lot happier.

Again, please observe the standard caveat that the above does not
represent a formal IBM announcement or commitment; I am just trying to
convey the sense that we understand the requirement, and are working on a
solution.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.



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.
 **********************************************************************