Job Queuing

To maximize processing speed and reduce "traffic jams" when writing back data, Personal Workspace and Sandbox submissions can be processed using a job queue.

To turn on job queuing, your administrator sets the JobQueuing=T parameter in the server configuration file. If this parameter is set to F or not present, Sandbox or Personal Workspace submissions do not use a job queue. In Direct Writeback mode there is no job queuing regardless of this setting. IBM® Cognos® TM1® Contributor does not use the job queue.

The benefits of using submission queuing include:

Performance improvements.
Use of the queue prevents data that is waiting for resources to hold up other jobs that are ready to process.
Concurrent work.
The queue allows users to continue working on other jobs while waiting for resources to be freed up on a particular job.
Transparency of processing.
The queue lets users monitor the activity level in the queue.
Efficient use of processing resources.
The queue allows users to cancel jobs if necessary.

When the Job Queue is enabled and a Personal Workspace or sandbox is submitted using a Commit or Submit button, the changed data enters the queue as a job and is processed only when the resources needed to complete the calculations specified by the cubes become available. If other sandboxes or Personal Workspace's are submitted while the original sandbox waits for resources, the second submitted sandbox can proceed without waiting for the first one to resolve its resources.

When job queuing is enabled, the job queue button displays on the toolbar. You can press this button to display the contents of the job queue. You can use the Job Queue and Refresh buttons proactively to see how many jobs are waiting to be submitted or to monitor the progress of a particular submission. Administrators can see all the jobs waiting to be processed in the queue. Users without Admin rights see only their own sandbox submissions.

Queuing progress is based on whether resources are available, not on the amount of data being processed. A submission with a large amount of data that resolves its resources will be processed before a submission with a small amount of data that needs a resource that is in contention.

In many cases sandbox submission will be instantaneous. At times of high concurrent submissions, a user can display the queue and decide to cancel a job. Users can cancel only their own jobs. Administrators can cancel any job in the queue.

When you have submitted a Personal Workspace or sandbox to the job queue:

In the data, any changed cells remain blue. When the sandbox completes processing, those cells turn black.
If you have Sandbox turned on, you can create a new sandbox or select an existing one and work as usual, including performing a read, write, or submit. Those submissions will also become subject to the queue. You can even create a new sandbox based on the queued data and work with those values in the new sandbox before the queue processes the transactions.
You can freely query any data in or out of a sandbox or Personal Workspace, but if you try to update the data, the following message displays so you can indicate your intentions:
```
 You are attempting to perform Data Entry while previously committed data
 changes reside in the queue. Click Yes to remove your submission
 from the Queue and continue with data entry, or click No to defer
 your current data entry until the system completes processing of your
 currently queued job. 
```
- To remove your submission from the queue and retain the data changes you just entered, click Yes.
  When you cancel the job, the data entry is appended to the current sandbox so you can continue working with it and possibly submit it at a later time.
- To wait until the current job completes processing, click No.
  When you click No, the data entry that is not part of the job is disregarded and the submission continues uninterrupted. Be sure you are willing to lose that data when you click No in this situation.