Starting and Stopping a Queue
Stopping a queue prevents any jobs from being dispatched to the queue, after it is stopped. However, jobs will queue up (wait on the queue) when it is stopped. When the queue is started again, the waiting jobs will start to be dispatched.
When an Execution Queue
is stopped, this means jobs will not be allowed to start execution when they are directly associated to the Execution Queue that is being stopped. If triggered, they will go into a "Waiting Queue Busy (Queue Closed/Stopped)" state until the Execution Queue is started. If job(s) are already executing, stopping an Execution Queue does not impact already running jobs - they will keep running until completion.
When a Generic Queue is stopped, jobs that are triggered and associated with that queue will not be dispatched to any member Execution Queue(s). If triggered, jobs will go into a "Waiting Queue Busy" state until the Generic Queue is started. If job(s) are already executing on member Execution Queue(s), stopping a Generic Queue does not impact already running jobs - they will keep running until completion.
One of the advantages of associating jobs to a Generic Queue is if one of the member Execution Queues is stopped, the remaining member systems are still eligible to run the job when it triggers.
See the Queue's Stop menu option as depicted in the image below.
Use the Queue's Start menu option to start the Queue again. Normally when you start an Execution Queue, the execution machine will be up and available. If it isn’t (for example, the Execution Agent application isn't running), the Queue will enter a “Starting” state and remain in that state until the execution machine becomes available. Jobs are not dispatched to a Queue in a “Starting” state.
Start/Stop operation is an in-context operation. This means ActiveBatch will select the proper operation depending on the current state of the Queue (e.g. if it’s started, you can stop the Queue).
You can also automatically stop (and start) a Queue based on the Queue’s properties. The image above is taken from the Queue's Properties tab. This is especially useful when you know a machine won’t be available during certain hours. One drawback to the timed queue operations above is that, once set they are applied each day. A more beneficial solution might be to create and schedule a job with the following Jobs Library Job Step.
A complementary job could be scheduled at a later time to start the queue using the StartQueue Job Step. Next, while the queue in this example is hard-coded (Server1), you could use a variable. That would make the set of jobs generic and applicable for use everywhere in your system. The Job Scheduler property is identified using a built-in variable ${@JobScheduler}. This is recommended when you have a high availability solution for the Job Scheduler. The variable will resolve to the Scheduler that is currently up and running (i.e. the primary Scheduler).
To start or stop a Queue, you must have “Manage” access permission on the Queue object.