You are perhaps right if the action, option or object-parameters are
changed.
However, in my case, only the start-time of the schedule was changed.
This is how one of my clients reacted to this when still at server level
3.7:

.
.
05/06/2001 02:04:18 --- SCHEDULEREC QUERY BEGIN
05/06/2001 02:04:18 --- SCHEDULEREC QUERY END
05/06/2001 02:04:18 Next operation scheduled:
05/06/2001 02:04:18
------------------------------------------------------------
05/06/2001 02:04:18 Schedule Name:         DAGLIG
05/06/2001 02:04:18 Schedule Name:         DAGLIG
05/06/2001 02:04:18 Action:                Incremental
05/06/2001 02:04:18 Objects:
05/06/2001 02:04:18 Options:               -incrbydate
05/06/2001 02:04:18 Server Window Start:   01:00:00 on 05/07/2001
05/06/2001 02:04:18
------------------------------------------------------------
05/06/2001 02:04:18 Command will be executed in 22 hours and 56 minutes.
05/06/2001 02:04:18 Command will be executed in 22 hours and 56 minutes.
05/07/2001 01:00:18
Executing scheduled command now.
05/07/2001 01:00:18 Node Name: HARALDSEN
05/07/2001 01:00:19 Session established with server SUMO: AIX-RS/6000
05/07/2001 01:00:19   Server Version 3, Release 7, Level 3.1
05/07/2001 01:00:19   Server date/time: 05/07/2001 01:00:19  Last access:
05/06/
2001 02:04:18

05/07/2001 01:00:19 ANS1814E Unable to start scheduled event 'DAGLIG'
05/07/2001 01:00:19 ANS1815E Either the window has elapsed or the schedule has 
been deleted
05/07/2001 01:00:19 ANS1483I Schedule log pruning started.
05/07/2001 01:00:19 Schedule Log Prune: 2036 lines processed.  111 lines pruned.
05/07/2001 01:00:19 ANS1484I Schedule log pruning finished successfully.
05/07/2001 01:00:19 Querying server for next scheduled event.
.
.

And, schedmode is polling.





On Mon, 14 May 2001, Mark Stapleton wrote:

> Tom Tann{s wrote:
> > Whith server-level 3.7 and earlier, if a client-scheduler was scheduled to
> > do something whithin its queryschedperiod, and the schedule on the server
> > in the meantime was changed to run at a later time, the client scheduler
> > would report a ANS1814E and "rescheduled" itself.
> >
> > I just upgraded to 4.1.3, and in this case, the client runs the original
> > scheduled task, just as if nothing was changed at the server.
> >
> > Is this another case of "buffers not cleared/updated" on the server?
>
> I don't recall this behavior at all. When you make a change in a client
> schedule on the server, you have to stop and restart the scheduler
> service running on each client associated to that scheduler so that the
> new parameters are read and obeyed by the client.
>
> --
> Mark Stapleton (stapleton AT berbee DOT com)
>