Job Attributes/Flags Overview
Job Attributes
*Note: By default, jobs may access QOS's based on the 'logical or' of the access lists associated with all job credentials. For example, a job associated with user John, group staff, and class batch may utilize QOS's accessible by any of the individual credentials. Thus the job's QOS access list, or QLIST, equals the 'or' of the user, group, and class QLIST's. (i.e., JOBQLIST = USERQLIST | GROUPQLIST | CLASSQLIST). If the ampersand symbol, '&', is associated with any list, this list is logically and'd with the other lists. If the carat symbol, '^', is associated with any object QLIST, this list is exclusively set, regardless of other object access lists using the following order of precedence user, group, account, QOS, and class. These special symbols affect the behavior of both QOS and partition access lists.
Job Flags
| ADVRES | |
| Format: | ADVRES[:<RESID>] |
| Default: | Use available resources where ever found, whether inside a reservation or not. |
| Description: | specifies the job may only utilize accessible, reserved resources. If <RESID> is specified, only resources in the specified reservation may be utilized. |
| Example: | FLAGS=ADVRES:META.1
(The job may only utilize resources located in the META.1 reservation) |
| BENCHMARK | |
| Format: | BENCHMARK |
| Default: | N/A |
| Description: | N/A |
| Example: | FLAGS=BENCHMARK |
| BESTEFFORT | |
| Format: | BESTEFFORT |
| Default: | N/A |
| Description: | N/A |
| Example: | FLAGS=BESTEFFORT |
| BYNAME | |
| Format: | BYNAME |
| Default: | N/A |
| Description: | N/A |
| Example: | FLAGS=BYNAME |
| DEDICATED | |
| Format: | DEDICATED |
| Default: | Use resources according to the global NODEACCESSPOLICY |
| Description: | specifies that the job should not share node resources with tasks from any other job |
| Example: | FLAGS=DEDICATED
(The job will only allocate resources from nodes which can be exclusively dedicated to this job) |
| DYNAMIC | |
| Format: | DYNAMIC |
| Default: | If set, active jobs may dynamically grow and shrink based on internal job requests or external scheduler driven requests based on application performance targets. Note: In order for a job to use this flag, the job's associated QOS credential must also have the DYNAMIC flag set within the QFLAGS attribute. |
| Description: | do not allow dynamic allocations for active jobs |
| Example: | FLAGS=DYNAMIC
The job will be allowed to dynamically allocate/de-allocate resources according to internal requests or scheduler-specified performance targets. |
| IGNIDLEJOBRSV | |
| Format: | IGNIDLEJOBRSV |
| Default: | N/A |
| Description: | Only applies to QOS. IGNIDLEJOBRSV allows jobs to start without a guaranteed walltime. Instead, it overlaps the idle reservations of real jobs and is preempted 2 minutes before the real job starts. |
| Example: | QOSCFG[standby] JOBFLAGS=IGNIDLEJOBRSV |
| NOQUEUE | |
| Format: | NOQUEUE |
| Default: | Jobs remain queued until the are able to run |
| Description: | specifies that the job should be removed it is is unable to allocate resources and start execution immediately. |
| Example: | FLAGS=NOQUEUE
(The job should be removed unless it can start running at submit time.) This functionality is identical to the resource manager extension QUEUEJOB:FALSE. |
| PREEMPTEE | |
| Format: | PREEMPTEE |
| Default: | Jobs may not be preempted by other jobs |
| Description: | Specifies that the job may be preempted by other jobs which have the PREEMPTOR flag set. |
| Example: | FLAGS=PREEMPTEE
(The job may be preempted by other jobs which have the 'PREEMPTOR' flag set) |
| PREEMPTOR | |
| Format: | PREEMPTOR |
| Default: | Jobs may not preempt other jobs |
| Description: | Specifies that the job may preempt other jobs which have the PREEMPTEE flag set |
| Example: | FLAGS=PREEMPTOR
(The job may preempt other jobs which have the 'PREEMPTEE' flag set) |
| PRESTART | |
| Format: | PRESTART |
| Default: | Jobs are started only after the first scheduling iteration |
| Description: | Note: used only in simulation mode to pre-populate a system. |
| Example: | FLAGS=PRESTART |
| RESTARTABLE | |
| Format: | RESTARTABLE |
| Default: | Jobs may not be restarted if preempted. |
| Description: | Specifies jobs can be requeued and later restarted if preempted |
| Example: | FLAGS=RESTARTABLE
(The associated job can be preempted and restarted at a later date) |
| SHAREDRESOURCE | |
| Format: | SHAREDRESOURCE |
| Default: | N/A |
| Description: | N/A |
| Example: | N/A |
| SUSPENDABLE | |
| Format: | SUSPENDABLE |
| Default: | Jobs may not be suspended if preempted. |
| Description: | Specifies jobs can be suspended and later resumed if preempted |
| Example: | FLAGS=SUSPENDABLE
(The associated job can be suspended and resumed at a later date) |
| SYSTEMJOB | |
| Format: | SYSTEMJOB |
| Default: | N/A |
| Description: | Creates an internal system job that does not require resources. |
| Example: | FLAGS=SYSTEMJOB |
| WIDERSVSEARCHALGO | |
| Format: | <BOOLEAN> |
| Default: | --- |
| Description: | When Moab is determining when and where a job can run, it either searches for the most resources or the longest range of resources. In almost all cases searching for the longest range is ideal and returns the soonest starttime. In some rare cases, however, a particular job may need to search for the most resources. In those cases this flag can be used to have the job find the soonest starttime. The flag can be specified at submit time, or you can use mjobctl -m to modify the job after it has been submitted. |
| Example: |
> msub -l flags=widersvsearchalgo > mjobctl -m flags+=widersvsearchalgo job.1 |
See Also