Andrew, This was discussed at Share in Minneapolis. What you have said here is pretty much what was discussed with TSM development. I expect to bring this subject up further at Share in Nashville. The real issue is customers are now trying to use these open systems and schedule jobs just like they do on mainframes. Verification that a backup completed properly is of utmost importance, especially, when every file is a set that must be restored to restore a production application similar to a database.
This is why we need more functionality in this area. The next few releases of TSM need to make headway here for customers to run this in production. -----Original Message----- From: Andrew Raibeck [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 24, 2001 11:41 AM To: [EMAIL PROTECTED] Subject: Re: Return Code Changes with V4.2.1 TSM Clients 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: [EMAIL PROTECTED] 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:[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. **********************************************************************
