Historically (since ADSM V1), "successful" incremental backups had not
taken skipped files into account. The rationale was that when processing
entire file systems, you are very likely to run into one or more files
that could not be processed. That being the case, you still need to check
the client dsmerror.log and/or dsmsched.log file for skipped files.

I understand that this may not fit your definition of "successful", and it
doesn't take a very large TSM installation to make checking individual
logs a tedious task (to say the least). But likewise, if we flagged every
event as "failed" where a file was skipped, many users would not be happy
with that definition, either, i.e. "I don't care if TSM couldn't back up
junk.txt, I don't want the backup to be treated as failed".

While it has been a long time in coming, version 5.1 addresses this with
the "consistent return codes" feature. If files are skipped, then while
the event is still flagged as "completed", the "result code" field in the
QUERY EVENT F=D output will show you the return code for the event. If the
RC is 0, then all files that were eligible for backup were backed up. If
the RC is 4, then you know that one or more files were skipped. If the RC
is 8, then you know at least one warning-level message was issued (and it
is possible that one or more files were skipped). The purpose of the RC 8
is to let you know that while the file systems were processed to
completion, you may want to check the client for more severe problems than
skipped files (but also check for skipped files). If the RC is 12, then
one or more error messages were issued during the backup. In this case,
the problems encountered were probably severe enough to prevent processing
of one or more file systems, and the event is flagged as "failed".

Any behavior that deviates from this would most likely be a bug (i.e. if
you saw a skipped file, but the RC still showed as 0).

I am not trying to be argumentative, but I do not think it is entirely
correct to say that QUERY EVENT is not useful to determine success or
failure of the backup operation... as long as you understand the meaning.
Agreed, is was not so clear prior to 5.1 if you required a successful
backup to mean that no files were skipped (and I know this was a "hot
button" for some customers). Hopefully the 5.1 stuff I mentioned above
will address this for you.

I apologize in advance if I am "missing the boat" here, but this
discussion so far has been pretty general, and I am not aware of your
specific issues.... since you are addressing this through IBM's formal
channels, there most likely there is more to your issue(s) than can be
resolved on this forum.

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.




Mark Bertrand <Mark.Bertrand AT USUNWIRED DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/16/2002 12:29
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Daily Backup Report



I hate to correct IBM again... My statement was correct

>>
query event will NOT tell you if your backup was successful.
<<

As Andy so carefully stated in his last comment:

>>
you should not have any problems determining success or failure of the
operation.
<<

The operation and the actual successful backup are two different things.
In
referring to a TSM operations (i.e. ACTION=INCREMENTAL), not a script, can
show proof of missed files and errors from reports from my activity log
that
a "success of the operation" does not mean that you had a successful
backup.
I

We currently have a Critsit open with Tivoli and IBM hardware support and
this is one of the major issues.

Just trying to help, I guarantee that if you rely only on a q event to let
your customers know if you have all their files backed up you will get
burned.