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: [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.




Mark Bertrand <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
04/16/2002 12:29
Please respond to "ADSM: Dist Stor Manager"


        To:     [EMAIL PROTECTED]
        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.

----Original Message-----
From: Andrew Raibeck [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 16, 2002 10:07 AM
To: [EMAIL PROTECTED]
Subject: Re: Daily Backup Report


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

This is true only if the schedule definition launches a script, i.e. DEF
SCH mydomain myschedule ACTION=COMMAND OBJECTS="myscript", and the script
contains commands that run asynchronously; in that case, TSM has no way to
track the actions taken within the script. It can only say, "the script
was launched successfully". In short, the success or failure of the
command depends on the return code issued from the script.

For scheduled TSM operations (i.e. ACTION=INCREMENTAL), you should not
have any problems determining success or failure of the operation. For
ACTION=COMMAND operations where the command

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.




Mark Bertrand <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
04/16/2002 07:34
Please respond to "ADSM: Dist Stor Manager"


        To:     [EMAIL PROTECTED]
        cc:
        Subject:        Re: Daily Backup Report



We also used "query event * * begindate=today-1 enddate=today ex=yes"
until
I learned that this does not report on clients that were or were not
backed
up successfully, this ONLY reports on if the script or schedule was
successful. To quote straight from the h q event page "Use this command to
check whether schedules were processed successfully."

I will not go into a rant about this, just learn from my mistake, query
event will NOT tell you if your backup was successful.

-----Original Message-----
From: Williams, Tim P {PBSG} [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 16, 2002 9:01 AM
To: [EMAIL PROTECTED]
Subject: Re: Daily Backup Report


we generally run a q event command   ex=yes
you can use begindate begintime parms, etc....
help q event
fYI

-----Original Message-----
From: Orin Rehorst [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 16, 2002 8:48 AM
To: [EMAIL PROTECTED]
Subject: Daily Backup Report


What are some good ways to get an automated daily report on which clients
were or were no backed up successfully?

TIA,

Regards,
Orin

Orin Rehorst
Port of Houston Authority
(Largest U.S. port in foreign tonnage)
e-mail:  [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Phone:  (713)670-2443
Fax:      (713)670-2457
TOPAS web site: <www.homestead.com/topas/topas.html
<http://www.homestead.com/topas/topas.html> >

Reply via email to