Re: TSM V5.1

>>
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