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 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. ----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> > ______________________________________________ "The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. Absa is neither liable for the proper, complete transmission of the information contained in this communication, any delay in its receipt or that the mail is virus-free."