When you use the TSM scheduler to launch a script/batch file on the
client, then TSM invokes an instance of the operating system command
processor and passes it the name of the script. When the script finishes,
it passes back its return code to the command processor, which in turn
passes back a return code to the TSM scheduler. Hopefully the rc passed
back by the command processor is the same as the rc passed back by the
script, and on NT-based systems, this is true. (On 9x-based systems, the
command processor always seems to pass back rc 0, regardless of the rc
from the script.) Thus the status you see when you run QUERY EVENT is what
was passed back to TSM by the command processor.
So the issue becomes, what rc is being passed back by the script? Well, if
the script launches a program that runs asynchronously, then the script
probably does this:
1) Enter script
2) Launch program asynchronously
3) Exit script with rc = 0
Thus the script passes back rc 0, but the launched program is still
running. There is no way for TSM to monitor the status of the launched
program.
Does this more or less describe what you are seeing? If so, then you need
to modify your script as Level 2 suggested so that the program runs
synchronously, so the script does something like this:
1) Enter script
2) Start program synchronously
3) When program completes, exit script with rc from program
If I've completely missed the point, then please elaborate on what you are
seeing, and be sure to include the exact details of your setup, including
(but not limited to) schedule definition, contents of script you are
scheduling, etc.
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/08/2002 06:03
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: reporting on backup successes/failures
Let me begin by saying that this rant is in no way meant to be directed to
Mark Stapleton, his advice has helped me many times and he is a great
asset
to the group, he never hesitates to help.
Be aware, q event ONLY reports on the success or failure of the backup
script being ran, NOT the actual job.
Example: Last week the below method was used as it is everyday to check
the
status of scheduled jobs and it reported the following.
04/05/2002 01:30:00 04/05/2002 02:01:54 130AM_EXCHANGE03_DB- EXCHANGE03_DB
Completed
But.... when you actually look into the job you still see it running as a
session.
Sess Comm. Sess Wait Bytes Bytes Sess Platform Client Name Number Method
State Time Sent Recvd Type ------ ------ ------ ------ ------- -------
-----
-------- -------------------- 3,102 Tcp/Ip RecvW 0 S 8.0 K 11.6 G Node TDP
EXCHANGE03_DB MSExc- hgV2 NT
And the activity log only shows that the Directory completed, the
Information Store is still being backed up.
I spoke to level 2 support and I understand that q event only reports on
the
script, he suggested that I need to put some kind of wait statement in the
script to not let it complete until the job actually completes.
I am not very happy with his suggestion, I am querying the event, I am not
running a q script!!! I don't want a Band-Aid, I just want a q event that
works!!!
Is there another solution within Tivoli to query the actual events?
BTW, we are running TSM 4.1.3 on W2K server and the example is for
Exchange
TDP 2.2 on Exchange 5.5.
Thanks all,
Mark B.
-----Original Message-----
From: Mark Stapleton [mailto:[EMAIL PROTECTED]]
Sent: Sunday, April 07, 2002 10:39 PM
To: [EMAIL PROTECTED]
Subject: Re: reporting on backup successes/failures
On Tue, 5 Mar 2002 10:26:18 -0600, "Glass, Peter"
<[EMAIL PROTECTED]> wrote:
>What would be the best way to produce a report that shows the number of
>client backup successes vs. failures, for a given day?
This is not as hard as some folks seem to want to make it:
q event * * begind=<start_date> endd=<end_date>
If you want it in script form:
def script backup_check 'q event * * $1 $2 > /tmp/backup_check'
You run it by inputting
run backup_check 04/01/2002 04/03/2002
--
Mark Stapleton ([EMAIL PROTECTED])
