You can hold a group or queue to prevent jobs from executing: right-click the group, then select Hold > Disable All Execution. The Disable All option will prevent triggers and manual execution. See Hold Status for more information.

To disable all jobs on the server, do the same thing on the root ("Jobs") group or use one of the other approaches described in Disable Execution for All Jobs.

When a group or all jobs are put on hold, I assume that currently running jobs will continue to run to completion. Is that correct?

When a group has some jobs that are already on Hold, it appears that a group Release of any kind will keep jobs on Hold that were on Hold before the job Hold was applied. Is that correct?

While a group and/or job is on hold, what happens when a trigger file is created during that time? When the hold is removed, will the trigger file be recognized and fire the job?

Active jobs will continue to run.

In adTempus 4, hold/release is a group-level (or queue-level) operation (in previous versions, holding a group really just held every job in the group  individually). Holding the group overrides the hold settings for all jobs in the group, but when you remove the hold on the group, the jobs have their original hold state. Shorter answer: yes.

While a job is held, adTempus stops evaluating triggers. For a file trigger, if the file is still there when the job is released, it will trigger (because the trigger works by scanning the folder, not by watching for events). But if, say, the file was created and deleted before the job is released, it will not cause a trigger, because adTempus will never see it.

I need to revise my original answer. In your case "Disable all execution" is probably not what you want because that will also prevent chained jobs from being kicked off (by Responses). Since you want your job stream to keep executing, you probably want to choose the "Custom" option and then choose "Hold triggers" and "Prevent manual execution" but leave chained execution enabled. However, if you're using Job Triggers to link your chain together, you're stuck, because holding triggers will disable job triggers, so your chains cannot run. We maybe should be treating job trigger differently here.

If the file is not there after jobs are put on hold or when adTempus starts after a reboot, it seems reasonable that a job is not triggered.

We have a summary/collector job that is triggered by the successful completion of N other jobs. It sounds like the collector job would not be started if it was still waiting on Y <= N-1 jobs to complete. Is that what you are saying? Would this be true even if the trigger is based on the same run cycle? What is the meaning of "run cycle" in this situation?

Run cycle is irrelevant in this situation. When the job is held, no triggers are evaluated, and this includes job triggers. Your collector job would not start. So unfortunately there is no simple way to use the hold mechanism to prevent new jobs from starting while also letting your active chain run to completion.

I can think of various complicated ways to do this, none of which is great:

• Run the collector job manually once everything else is finished
  
• Move the collector job to a different group or queue that doesn't get held
• Use a script (or console plugin) to disable the schedule and file triggers on all the jobs in the group (leaving the job triggers alone), and then re-enable them when maintenance is finished. If this appeals, I can put together a quick script for you as proof of concept.
  

I have written this up to be considered as a change for the next release, because I think we should treat job triggers the same way we treat responses in this scenario, so that the chains can continue to execute to completion. Unfortunately I think it requires some pretty substantial changes to accommodate, so it's not something we can crank out for you as a quick solution.