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: 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/08/2002 06:03
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        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
-------- -------------------- 3,102 Tcp/Ip RecvW 0 S 8.0 K 11.6 G Node TDP
EXCHANGE03_DB MSExc- hgV2 NT
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.