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