Not creating jobs that have to wait for execution
If the initialization file is defined using the Create/Edit Queues window so that the same limits are specified for both the multiplicity level of jobs in a queue and the number of jobs that can be submitted to the queue, then the number of jobs submitted cannot exceed the multiplicity limit.
If a suitable limit value is specified for multiplicity (taking the load on the system into account), then it is possible to operate in such a way that jobs that cannot be executed immediately will be rejected if they are submitted, and so jobs that have to wait for execution will not be created.
The multiplicity of jobs in a queue is defined using Limit the number of jobs to execute simultaneously (Max Execution Jobs) in the Create/Edit Queues window that is called from the Define Operating Information window. The number of jobs that can be submitted is defined using Limit the number of jobs to submit (Number of jobs) in the same window.
The following figure shows a representation of this kind of job queuing operation.
Controlling job execution priority
The execution priority of jobs can be specified when they are submitted. If this specification is omitted, the default priority for the queue (the value specified for "Specify default job priority (Default Job Priority)" in the Create/Edit Queues window) will be used.
The job with the highest priority is executed first. Jobs with higher priority are still executed first even if they are submitted later.
If this arrangement is being used and a job that requires immediate execution needs to be submitted, specify a priority that is higher than that of other waiting jobs.
It is also possible to dynamically change the priority of any or all waiting jobs.
The following example shows a representation of an operation where an urgent job is submitted and execution priorities are changed dynamically.
Executing jobs by exclusively occupying resources
You can specify any name and either the shared or exclusive attribute for a job resource. In addition, as implicit resources, all jobs have "host name" and "execution queue name" as shared attributes. You can use this mechanism to exclusively occupy the server on which Systemwalker Operation Manager is installed (so that no other job is being executed) and then execute jobs, as is done with the backup job in the following example:
Example: Execute a backup job
Set Resource Used to the host name and Type to Exclusive, and then submit the job.
The backup job waits for all jobs that are running to end.
The backup job starts after all running jobs have ended.
Jobs submitted during or after step 1 wait until the backup job has ended.
If exclusive attributes are specified for the jobs with the same name
If exclusive attributes are specified for jobs with the same name, the jobs with the same name will not be executed simultaneously. All but one of these jobs will be queued as "jobs waiting to be executed" and then executed sequentially. The execution sequence of these jobs depends on their priorities and resource specifications. If no priorities or resources have been specified, the jobs will be executed in the order in which they were submitted.
This specification is effective when a number of related jobs are executed in order.
The following figure shows a representation of operations where jobs with two identical names are submitted and exclusive attributes have been specified for jobs with the same name.
Calculation processing is distributed to multiple machines and executed to enable load leveling
The execution rate can be leveled using the Distributed Execution function, even if the deployed status of the calculation application has not been integrated.
To level the execution rate, firstly define the execution server as an identical host group according to the condition, such as the deployed status of the application, and associate it with the queue.
To effectively distribute execution evenly, consider the server load between the queue and the host groups, and configure the settings so that the number of jobs between host groups is shared.
To configure the settings to share the number of jobs between host groups, select Share the number of job entries to same execution servers between host groups. on the Backward compatibility sheet of the Define Operating Information window.
If the job is submitted to a queue associated with an application used by the user, then the number of jobs in the queue will be reflected in all the execution servers with the same name, even if the server is in another group. As a result, jobs can be executed on servers with a lower load.
