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.
