Andy,
I do not want to say this was intentional. What I am mostly interested is
which parts of v4.2.1.0 discussions are applicable for v5.1 client.
If we look at the client as a black-box (and in fact customer does not
need to know why and what drives the client to perform this way) we are
having same behavior. Coincidence or not it doesn't matter. Backward
compatibility is not a bad thing so I personally would be happy to see
some kind of client option restoring v4.x behavior.
After Tim's post I visited the site to check was is in the docs. And I
wrote that this behavior is documented. For sure we do not have v4.2.1
"inconsistency" `-)
I appreciated the RC=4 in v4.2.1 client and even was sad seeing its a bug
and will go away. But as you know some inventions in Physics and Chemistry
were results of mistakes :-)
Unfortunately Share is too far for me (I have to traverse too many time
zones to go there) and have no power to influence the development. Maybe
would be worth to have some way to define which files should produce rc=4
on backup failure instead of digging down the logs. OTOH maybe I am too
lazy.
Zlatko Krastev
IT Consultant
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: TSM V5.1 - RC=4
>>
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: 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.
Zlatko Krastev <acit AT ATTGLOBAL DOT NET>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/13/2002 05:57
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
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" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
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
|
