Quoting Philippe Girard <Philippe.Girard AT NOVIPRO DOT COM>:
> 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.