Hi
I don't know what kind of OS you're using, but the pending move is only on
the TSM server. That because it's not the server that controls the
schedule, only the client.
If you look at the log on your client , it will tell you if it has received
the schedule. So, there is nothing wrong with the TSM scheduler. It a
client/server software, and this means almost all information is stored at
client level, not server level.
The reason for this is probably that if you have a lot of clients(>1000),
having all information stored at server level will be very hard to analyze.
You only want to analyze clients that have missed, failed or (?) status.
Therefore, it's easier to analyze at client level, when you have determined
which clients are having problems.
You could probably redirect information from the client scheduler to the
server, but this would mean that your actlog would grow beyond proportions,
and troubleshooting client errors could be very hard, if not impossible.
Best Regards
Daniel Sparrman
-----------------------------------
Daniel Sparrman
Exist i Stockholm AB
Bergkällavägen 31D
192 79 SOLLENTUNA
Växel: 08 - 754 98 00
Mobil: 070 - 399 27 51
Joseph Seigh
<jseigh@GENUI To: [EMAIL PROTECTED]
TY.COM> cc:
Sent by: Subject: Re: TSM with 3rd party scheduler
"ADSM: Dist
Stor Manager"
<[EMAIL PROTECTED]
RIST.EDU>
2002-02-27
12:52
Please
respond to
"ADSM: Dist
Stor Manager"
Quoting Philippe Girard <[EMAIL PROTECTED]>:
> I do not know what platform you are working on,
> but with your scheduler if you can send command to TSM like:
> DSMCADMC -ID=xxx -PA=xxxx command
>
> you can control TSM from your scheduler.
You got the question the wrong way around. We have a mechanism
to send commands and get the results from TSM. It's an expect/perl
script. Only naive and foolish persons would expose their passwords
by putting them in a unix command parameter list.
We're looking for a 3rd party scheduler that lends itself to scripting
and automation. The scheduler that is part of TSM is, to put it mildly,
less than inadequate. It takes a Darwinian approach to client scheduling.
There's no decent feedback mechanism on the status of a schedule. What's
"Pending" mean? Almost nothing. Just that the schedule's window is open
and you don't need the events log to tell you that. It doesn't tell you
whether the client has actually received the schedule and is waiting for
some other reason before starting such as not starttime yet, or no
schedule sessions available from server, etc... And that 5 minute
sleep loop in the schedule push thread does not help either. That's
why clientactions take an average of 2.5 minutes to start if any of
you were wondering. You would think that someone doing threads programming
would know about pthread condition variables.
I would think that with something as appallingly bad as the TSM scheduler,
that lots of people would not put up with it. But maybe not. Do most
people suffer this thing?
Joe Seigh
disclaimer: The opinions expressed herein are mine and not necessarily
those of Genuity.
