Issue a q status
look for a setting under schedule randomization percentage
If that number is greater than 0, then this is the reason for the delay in
schedule start.
If you have a lot of node associated with a schedule, then it is a good idea to
use
randomization. It will prevent them all from attempting to start at the same
time.

On Tuesday, April 04, 2000 6:13 AM, Lindsay Morris [SMTP:lmorris AT OPENMIC DOT 
COM]
wrote:
> There's this annoying behavior ....
>
> When you change the start time of a schedule in TSM to NOW,
> it doesn't kick off then.  It kicks off maybe 3 minutes later.
>
> I tried a couple of things - none of these had any effect:
>
>     define clientaction (ie, create a schedule name @1, startt=now)
>
>     upd sched .... duration=1 durunits=minutes (in this case, the
>     schedule NEVER kicks off - but after a minute "query events" says
>     "MISSED")
>
>     upd sched .... perunits=onetime duration=indefinite
>
> One thing that DOES work is bouncing the scheduler.  i guess
> that's because the scheduler, waking up, contacts the server.
> But that's a pretty graceless solution.
>
> I checked to see if the clocks are set the same - they are.
> In fact the client is on the same machine as the server, so the
> clocks are identical.
>
> So, has anybody figured out a way to make the scheduler
> more responsive?
>
> Vital stats: AIX 4.3, TSM server 3.7.2.0, TSM client 3.7.0.0,
> schedmode prompted, commmethod tcpip.
>
> Thanks!
> --
> Mr. Lindsay Morris
> Gresham Enterprise Storage
> lmorris AT openmic DOT com
> 606-253-8000