Hi Orin,

Just to add to what Paul and Andy has already said:
TDP for Exchange - definately a problem - even a q files nodexyz f=d reports
a successfull backup - although the Rc425 in the exchange log says that
the backup of storage group xyz failed the TDP for exchange does NOT
comunicate
this fact to the TSM server - what we do is run SQL queries against the
TSM actvity log to see the success or failure of the backup.
Andy's statement that the q event is good for scheduled operations is not
true - I have an NT server where I have an ADMIN command to backup the
primary tape pool to a secondary tape pool with a wait=yes added.
When the server starts the command it ends without mounting the tapes,
because there is no free tapes available to make the copy.
In the TSM activity log you can see the process failed - but the q event
says it was fine.
According to me this should report a FAILED EVENT - but is says the event
was
OK return code 0.
Might be a bug - but I don't make use of the events table for reporting
AT ALL.

Cheers
Christo
----------------------------------------------------------------------------
Mark is absolutely correct.  This is an issue we have as well.  To solve the
Mark is absolutely correct.  This is an issue we have as well.  To solve the
problem we are running post processing of the output looking for a bogus
situation and setting return codes.  We use an external scheduler, so we can
do this.  With the TSM Scheduler you are just screwed if you are not
satisfied that a successful session does not necessarily equal a successful
backup.

The worst problem we have is the TDP for Exchange can get a 425 return code
because Norton Anti-virus has the Exchange store tied up and you still get a
successful backup.  This takes a bounce of the Exchange Server.  The issue
is you can go weeks without realizing you have not gotten an Information
Store backup.

Typically, I use SQL to looke for the message id and failed and that is how
this one is found.



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.