>>
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.
<<
A keen observation, but entirely coincidental, and thus not an apt
characterization. In 4.2.1.0, the RC=4 behavior was not "implemented" per
se, as that would suggest intent. It wasn't as if that were a "sneak
preview" of things to come. Rather, it was a bug (well documented in APAR
IC31844) that was introduced as an unintentional side effect of another
otherwise unrelated code change.
RC=4 notwithstanding, in 5.1, the underlying intent, design, and code for
the "consistent return codes" feature in no way, shape, or form, resembles
the bug from 4.2.1.0. The RC=4 is at most a vague resemblance, but that is
where any similarity ends.
>>
So the question I am asking myself and hoping for your help:
Is RC=4 good indicator for successful backup with some files skipped?
<<
Yes, just as it is documented in the book, which Tim quoted from below.
This is what the "consistent" in "consistent return codes" is all about!
:-)
>>
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?
<<
Probably by whichever methods you already have in place (i.e. check the
dsmerror.log, dsmsched.log, etc.). The "consistent return codes" feature
is intended only to let you know the general status of the operation. By
having the RC=0 and RC=4, you know exactly which clients skipped files. In
prior versions of ADSM/TSM, you always got RC=0, regardless of whether any
files were skipped, so you always had to check every client to see if it
skipped files.
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.
Zlatko Krastev <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
04/13/2002 05:57
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: TSM V5.1 - RC=4
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.
