Scheduler - staggered start

[NeilPannett]

Am facing a challenge with creating a stable schedule, and I was hoping someone can help. Currently using v4.2, but if the solution lies in v5.0 I'll be happy as we are soon upgrading... Anyway - the problem: I have a sequence of processes that I have to run, some singularly, some concurrently - as thus; 1) Process A runs (one machine) 2) Process B runs (multiple machines) 3) Process C, D and E run (concurrently, multiple machines) 4) Process F runs (multiple machines). The problem I have is with the second and fourth steps of this process - I need the same process to run across multiple machines concurrently, but I need to stagger the start times - probably by 90-120 seconds. The reason for this is that multiple instances running at EXACTLY the same time is overloading the connected application and causing it to error - by staggering the start times slightly we avoid this. Any ideas?

[TomBlackburn1]

Neil, I would forget about staggered schedules. I would use environment locks to create your staggered effect of accessing the application. Tom

[Anonymous]

Or you could add a parametrized wait stage at the start of processes B and F, and make the wait time an input to the process. Then you can configure each session within the same task of the schedule with different initial wait times.

[Denis__Dennehy]

I agree with Tom, the correct solution to throttle system usage where a system has user concurrency issues is not to stagger schedules but to design a solution that limits access whilst the process runs. Take the scenario where the system goes down for 10 minutes, if you have built in robust system down exception handling the processes will pause for 10 minutes (after sending an alert to the controlelr) and retry accessing the system every 5 minutes. Then, once the system comes back up all your robots will attempt to accesss the system at the same time. Simply trying to use Schedular as a work around does not fix this scenario.

[Anonymous]

I was not trying to start a discussion, merely pointing out how Neil could do exactly what he asked for. It should be obvious that this solution is not robust, but in some cases it might be sufficient.

[NeilPannett]

Thanks everyone for your replies - great to have a few solutions to look at.