Hello all, my question is mainly targeted to Andy Raibeck but all opinions are welcome. This behavior was first implemeted at v4.2.1.0 client. The discussion at that time finished with opinion this was a bug and later behavior restored to normal. Now RC=4 is getting back but as a feature and is documented. So the question I am asking myself and hoping for your help: Is RC=4 good indicator for successful backup with some files skipped? How would we check which files are not backed up? How to distinguish between files we can skip and files we absolutely do not want to miss backup?
Zlatko Krastev IT Consultant P.S. Some of you are lucky enough and already have the code. I am still waiting to put my hands on it. Zlatko Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: TSM V5.1 - new return codes I think the addition of return codes is great but have a question on the rc=4 with excluded files: The doc specifies: rc=4: The operation completed successfully, but some files were not processed. There were no other errors or warnings. This return code is very common. Files are not processed for various reasons. The most common reasons are: - The file is in an exclude list.. - The file was in use by another application and could not be accessed by the client - The file changed during the operation to an extent prohibited by the copy serialization attribute. I have a directory with one subdirectory exluded via exclude and exlude.archive. For an incremental of the directory I get rc=0, for an archive or a selective backup I get rc=4. I would rather see a different return code for an excluded file (I'm excluding it so I expect it to not get backed up!). I think a file that is missed because it is open or changed is much more serious than a file that is excluded. Why are the return codes inconsistent between incrementals and selective or archives? Or was my testing incorrect? Thanks, Tim Rushforth City of Winnipeg -----Original Message----- From: Andrew Raibeck [mailto:[EMAIL PROTECTED]] Sent: Friday, April 12, 2002 12:49 PM To: [EMAIL PROTECTED] Subject: Re: TSM V5.1 Yes, you've discovered a new feature. If you are using PRESCHEDULECMD, then presumably you have some operation that you wish to complete prior to the scheduled TSM operation (i.e. shut down a database before incremental backup runs). In 5.1, we changed PRESCHEDULECMD so that if the command does end with return code 0, then the scheduled operation will not run. This change was based on user requirements. >From the use rmanual, in the section on what's new in 5.1: ================================================== Reliable, consistent, and documented return codes have been added to the command line client and the scheduler. This facilitates automation of client operations via user-written scripts. By using the QUERY EVENT command with the FORMAT=DETAILED option, administrators can now distinguish between scheduled backups that completed successfully with no skipped files and scheduled backups that completed successfully with one or more skipped files. Also if you use the processing option preschedulecmd to run a command, and that command returns a non-zero return code, the scheduled event will not run. This ensures that scheduled events will not run if prerequisite commands do not complete successfully. See Return Codes from the Command Line Interface, Preschedulecmd/Prenschedulecmd, and Postschedulecmd/Postnschedulecmd for more information. ================================================== Alternatively, if the command does not need to complete prior to running the scheduled operation, you can use PRENSCHEDULECMD, which runs asynchronously, and whose return code is not tracked. 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.