If they perform conceptually the same task, I like to have them in one executable. Because it's cheaper to refactor things that way, the code tends to end up closer to where it should. Can't say more without knowing more about your application domain.

How comfortable are you with your OS scheduler, and how refined are the scheduling requirements? I know how to do certain things with unix cron, but not others. If for example the exact timing of the next task depends on something that happened in the current one, I'd avoid the OS scheduler (although I also know how to use it if I wanted to). If all you need is "run daily at HH:MM", the system schduler can certainly do it. It's more a delivery/deployment/field engineering question than a deep architechtural one. But you need to consider:

- what happens when the system is restarted?
- what happens when a job is killed?
- who changes scheduling (the process/administrator/you)? how often? w
+here from?
- how is the system installed?
- how portable does this need to be?
[download]