Enabling and configuring workload service assurance
A number of global and local options control the management of critical jobs. The HCL Workload Automation security file also must authorize users with proper access to all jobs, job streams, and workstations associated with critical jobs.
Global options
The workload service assurance feature is enabled and disabled by the global option enWorkloadServiceAssurance. It is enabled by default. Other global and local options are used to control different aspects of the processing of critical jobs and their predecessors.
| Option | Description |
|---|---|
| enWorkloadServiceAssurance | wa | Enables or disables privileged processing of mission-critical jobs and their predecessors. The default value is YES. Specify NO to disable. |
| promotionOffset | po | Workload service assurance calculates a critical
start time for the critical job itself and each of its predecessors.
This is the latest time that the job can start without putting the
timely completion of the critical job at risk. When the critical start time of a job is approaching and the job has not started, the promotion mechanism is used. A promoted job is assigned additional operating system resources and its submission is prioritized. The promotionoffset global option determines the length of time before the critical start time that a job becomes eligible for promotion. The default setting is 120 seconds. |
| longDurationThreshold | ld | The calculation of critical start times for
the jobs that form a critical network is based on the deadline defined
for the critical job and the estimated durations of the critical job
and each of its predecessors. If a job takes much longer than expected to complete, it could cause jobs that follow it to miss their critical start times and so put the timely completion of the critical job at risk. The longDurationThreshold global option is a percentage value. The default is 150. Using the default value, if the actual duration of a job is 150% of the estimated duration or longer, the job is considered to have a long duration and is added to the hot list that can be viewed on the Dynamic Workload Console. |
| approachingLateOffset | al | The critical start time of a job in the critical
network is the latest time that the job can start without causing
the critical job to end after the deadline. In most cases, a job will
start well before the critical start time so that if the job runs
longer than its estimated duration, the situation does not immediately
become critical. Therefore, if a job has not started and the critical
start time is only a few minutes away, the timely completion of the
critical job is considered to be potentially at risk. The approachingLateOffset option
allows you to determine the length of time before the critical start
time of a job in the critical network at which you are to alerted
to this potential risk. If a job has still not started the specified
number of seconds before the critical start time, the job is added
to a hot list that can be viewed on the Dynamic Workload Console.
The default is 120 seconds.
Note: The value of this parameter is checked
regularly. JnextPlan does not need to be run for changes to take effect.
|
| deadlineOffset | do | In general, a deadline should be specified for
a job flagged as critical. If it is not, the scheduler
uses the deadline defined for the job stream. The deadlineOffset option provides an offset used to calculate the critical start time in case the deadline is missing for both a critical job and its job stream. The plan end plus this offset is assumed as the critical job's deadline. The offset is expressed in minutes. The default is 2 minutes. Important: When the plan is extended, the start time
of critical jobs whose deadline is calculated with this mechanism
is automatically changed as a consequence of the fact that it must
now match the new plan finishing time.
|
Local options
| Option | Description |
|---|---|
| jm promoted nice | Sets the nice value to be assigned
to critical jobs or critical job predecessors that need to be promoted
on UNIX and Linux operating systems, so that they are assigned more
resources and processed ahead of other jobs. Specific values vary for the different platforms, but in general, the setting must be a negative integer. The default is -1 and lower numbers represent higher priorities. If you specify a positive integer, the default value is used. The jm nice local option has a similar role in prioritizing jobs that have been submitted by the root user. A critical job that has been submitted by the root user could be eligible for both prioritization mechanisms. In such a case, values would be added together. For example, if jm promoted nice is set to -4 and jm nice to -2, the critical job submitted by user root would have a priority of -6. |
| jm promoted priority | Sets the priority value for critical jobs or
critical job predecessors that need to be promoted so that Windows
operating systems assign them more resources and process them ahead
of other jobs. The possible values are:
The default is AboveNormal. Note that if you set a lower priority value than the one non-critical jobs might be assigned, no warning is given and no mechanism such as the one available for jm promoted nice sets it back to the default. |
Security file requirements
It is mandatory that the users who own the HCL Workload Automation instances running critical jobs are authorized to work with all jobs, job streams, and workstations associated with these jobs. These users must therefore have DISPLAY, MODIFY, and LIST rights in the security file for all the JOB, SCHEDULE and CPU associated objects.
See the HCL Workload Automation Administration Guide for details about the security file.