You are absolutely correct. The purpose of this stream is to see if we can influence development to make the right decision.
What our company requires is to be able to do exactly what you are saying. That said, we will be creating separate jobs for different processes only including what we need to backup and using an external scheduler with dsmc commands and checking the return codes, just like you are proposing. That way the RC=0 really means something and anything with an RC=4 is bad from our point of view. Before the "correction" in 4.2.1 to make a RC=4 come out on any file not being backed up, we were concerned. We want it to work the way the new client works, but we are a newer TSM environment and the change has no legacy effect on us. IBM/Tivoli has always been good about backward compatibility with a few exceptions over the years. Now, we must also think about accommodating the desktop client user. They need something simple like was suggested in my first go round. A set of defaults that simulates kind of what is said. For the Oracle scenario, my suggested design would have said if >0 files do not get backed up or >0% fail then give me a RC=4 on that client or dsmc command. Sorry, if that is not what was communicated. We discussed this issue at SHARE in Minneapolis. It will come up again in Nashville. I can tell everyone, SHARE has a lot of influence on Tivoli Development. I am a Deputy Project Manager involved with the Distributed Storage Project. So, I am trying to get this right this time. And, make sure that we communicate the correct implementation requirements to Tivoli. You cannot ask for the world, but you can ask to make it meet the business needs in a way that lets Tivoli implement the functionality over several releases. Be careful what you ask for, you may actually get it. I will try to continue to monitor this discussion stream and collect the requirement and present it at the requirements session at SHARE in Nashville. Every TSM customer should think about sending people to SHARE, there are some brilliant people there from Tivoli Development and customers. -----Original Message----- From: Robin Sharpe [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 18, 2001 10:41 AM To: [EMAIL PROTECTED] Subject: Re: Return Code Changes with V4.2.1 TSM Clients 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. **********************************************************************
