Provided by: gridengine-common_6.2u5-7.3_all bug

NAME

       queue_conf - Sun Grid Engine queue configuration file format

DESCRIPTION

       This  manual  page  describes  the  format  of  the  template  file  for the cluster queue
       configuration.  Via the -aq and -mq options of the qconf(1) command, you can  add  cluster
       queues  and  modify  the  configuration  of  any queue in the cluster. Any of these change
       operations can be rejected, as a result of a failed integrity verification.

       The queue configuration parameters take as values  strings,  integer  decimal  numbers  or
       boolean,   time   and  memory  specifiers  (see  time_specifier  and  memory_specifier  in
       sge_types(5)) as well as comma separated lists.

       Note, Sun Grid Engine  allows  backslashes  (\)  be  used  to  escape  newline  (\newline)
       characters. The backslash and the newline are replaced with a space (" ") character before
       any interpretation.

FORMAT

       The following list of parameters specifies the queue configuration file content:

   qname
       The name of the cluster queue as defined for  queue_name  in  sge_types(1).   As  template
       default "template" is used.

   hostlist
       A  list of host identifiers as defined for host_identifier in sge_types(1).  For each host
       Sun Grid Engine maintains a queue instance for running jobs on that particular host. Large
       amounts  of  hosts  can  easily be managed by using host groups rather than by single host
       names.  As list separators white-spaces and "," can be used.  (template default: NONE).

       If more than one host is specified it can be desirable to  specify  divergences  with  the
       further  below  parameter  settings for certain hosts.  These divergences can be expressed
       using the enhanced queue configuration specifier  syntax.  This  syntax  builds  upon  the
       regular parameter specifier syntax separately for each parameter:

       "["host_identifier=<parameters_specifier_syntax>"]"
       [,"["host_identifier=<parameters_specifier_syntax>"]" ]

       note, even in the enhanced queue configuration specifier syntax an entry without  brackets
       denoting  the  default  setting  is  required  and  used  for all queue instances where no
       divergences are specified.  Tuples with a host group host_identifier override the  default
       setting.  Tuples  with  a host name host_identifier override both the default and the host
       group setting.

       Note that also with the enhanced queue configuration specifier syntax a default setting is
       always  needed  for  each  configuration attribute; otherwise the queue configuration gets
       rejected. Ambiguous queue configurations with  more  than  one  attribute  setting  for  a
       particular  host  are  rejected.   Configurations containing override values for hosts not
       enlisted under 'hostname' are accepted but are indicated by -sds of qconf(1).  The cluster
       queue should contain an unambiguous specification for each configuration attribute of each
       queue  instance  specified  under  hostname  in   the   queue   configuration.   Ambiguous
       configurations with more than one attribute setting resulting from overlapping host groups
       are indicated by -explain c of qstat(1)  and  cause  the  queue  instance  with  ambiguous
       configurations to enter the c(onfiguration ambiguous) state.

   seq_no
       In  conjunction  with  the  hosts  load  situation at a time this parameter specifies this
       queue's position in the scheduling order within the  suitable  queues  for  a  job  to  be
       dispatched under consideration of the queue_sort_method (see sched_conf(5) ).

       Regardless  of  the  queue_sort_method  setting, qstat(1) reports queue information in the
       order defined by the value of the seq_no. Set this parameter to a monotonically increasing
       sequence. (type number; template default: 0).

   load_thresholds
       load_thresholds is a list of load thresholds. Already if one of the thresholds is exceeded
       no further jobs will be scheduled to the  queues  and  qmon(1)  will  signal  an  overload
       condition  for  this  node. Arbitrary load values being defined in the "host" and "global"
       complexes (see complex(5) for details) can be used.

       The syntax is that of a comma separated list with each  list  element  consisting  of  the
       complex_name  (see  sge_types(5))  of  a load value, an equal sign and the threshold value
       being intended to trigger the overload situation (e.g. load_avg=1.75,users_logged_in=5).

       Note: Load values as well as consumable resources may be scaled differently for  different
       hosts  if specified in the corresponding execution host definitions (refer to host_conf(5)
       for more information). Load thresholds are compared against the scaled load and consumable
       values.

   suspend_thresholds
       A list of load thresholds with the same semantics as that of the load_thresholds parameter
       (see above) except that exceeding one of the denoted thresholds  initiates  suspension  of
       one  of  multiple  jobs in the queue.  See the nsuspend parameter below for details on the
       number of jobs which are  suspended.  There  is  an  important  relationship  between  the
       uspend_threshold and the cheduler_interval. If you have for example a suspend threshold on
       the np_load_avg, and the load exceeds the threshold, this does not have immediate  effect.
       Jobs  continue  running  until  the  next  scheduling run, where the scheduler detects the
       threshold has been exceeded and sends an order to qmaster to suspend  the  job.  The  same
       applies for unsuspending.

   nsuspend
       The  number  of  jobs which are suspended/enabled per time interval if at least one of the
       load thresholds in the suspend_thresholds list is exceeded or if no  suspend_threshold  is
       violated anymore respectively.  Nsuspend jobs are suspended in each time interval until no
       suspend_thresholds are exceeded anymore or all jobs in the queue are suspended.  Jobs  are
       enabled  in  the  corresponding way if the suspend_thresholds are no longer exceeded.  The
       time interval in which the suspensions of the jobs occur is  defined  in  suspend_interval
       below.

   suspend_interval
       The   time  interval  in  which  further  nsuspend  jobs  are  suspended  if  one  of  the
       suspend_thresholds (see above for both) is exceeded by the current load  on  the  host  on
       which  the  queue is located.  The time interval is also used when enabling the jobs.  The
       syntax is that of a time_specifier in sge_types(5).

   priority
       The priority parameter specifies the nice(2) value at which jobs in  this  queue  will  be
       run.  The  type  is  number  and  the  default  is  zero (which means no nice value is set
       explicitly). Negative values (up to -20)  correspond  to  a  higher  scheduling  priority,
       positive values (up to +20) correspond to a lower scheduling priority.

       Note,  the  value  of  priority  has  no  effect,  if  Sun  Grid Engine adjusts priorities
       dynamically  to  implement  ticket-based  entitlement  policy  goals.   Dynamic   priority
       adjustment is switched  off by default due to sge_conf(5) reprioritize being set to false.

   min_cpu_interval
       The  time  between  two automatic checkpoints in case of transparently checkpointing jobs.
       The maximum of the time requested by the user via qsub(1) and  the  time  defined  by  the
       queue  configuration  is  used  as  checkpoint  interval.  Since  checkpoint  files may be
       considerably large and thus writing them to the file system may  become  expensive,  users
       and   administrators   are   advised   to   choose   sufficiently  large  time  intervals.
       min_cpu_interval is of type time and the default is 5 minutes (which usually  is  suitable
       for test purposes only).  The syntax is that of a time_specifier in sge_types(5).

   processors
       A set of processors in case of a multiprocessor execution host can be defined to which the
       jobs executing in this queue are bound. The value  type  of  this  parameter  is  a  range
       description  like that of the -pe option of qsub(1) (e.g. 1-4,8,10) denoting the processor
       numbers for the processor group to be used. Obviously the interpretation of  these  values
       relies  on operating system specifics and is thus performed inside sge_execd(8) running on
       the queue host. Therefore, the parsing  of  the  parameter  has  to  be  provided  by  the
       execution daemon and the parameter is only passed through sge_qmaster(8) as a string.

       Currently,  support  is  only  provided  for  multiprocessor machines running Solaris, SGI
       multiprocessor machines running IRIX 6.2 and Digital UNIX multiprocessor machines.  In the
       case  of  Solaris  the processor set must already exist, when this processors parameter is
       configured. So the processor set has to be created manually.  In the case of Digital  UNIX
       only  one  job  per processor set is allowed to execute at the same time, i.e.  slots (see
       above) should be set to 1 for this queue.

   qtype
       The type of queue. Currently batch, interactive or a combination in a comma separated list
       or NONE.

       The  formerly  supported types parallel and checkpointing are not allowed anymore. A queue
       instance is implicitly of type parallel/checkpointing if there is a  parallel  environment
       or  a  checkpointing  interface  specified  for  this queue instance in pe_list/ckpt_list.
       Formerly possible settings e.g.

       qtype   PARALLEL

       could be transferred into

       qtype   NONE
       pe_list pe_name

       (type string; default: batch interactive).

   pe_list
       The list of  administrator-defined  parallel  environment  (see  sge_pe(5))  names  to  be
       associated with the queue. The default is NONE.

   ckpt_list
       The  list  of  administrator-defined  checkpointing  interface  names  (see  ckpt_name  in
       sge_types(1)) to be associated with the queue. The default is NONE.

   rerun
       Defines a default behavior for  jobs  which  are  aborted  by  system  crashes  or  manual
       "violent"  (via  kill(1))  shutdown  of the complete Sun Grid Engine system (including the
       sge_shepherd(8) of the jobs and their process hierarchy) on the queue  host.  As  soon  as
       sge_execd(8)  is restarted and detects that a job has been aborted for such reasons it can
       be restarted if the jobs are restartable. A job may not be restartable, for example, if it
       updates  databases (first reads then writes to the same record of a database/file) because
       the abortion of the job may have left the database in an inconsistent state. If the  owner
       of a job wants to overrule the default behavior for the jobs in the queue the -r option of
       qsub(1) can be used.

       The type of this parameter is boolean, thus either TRUE or FALSE  can  be  specified.  The
       default is FALSE, i.e. do not restart jobs automatically.

   slots
       The  maximum  number of concurrently executing jobs allowed in the queue.  Type is number,
       valid values are 0 to 9999999.

   tmpdir
       The tmpdir parameter specifies the absolute path to the base of  the  temporary  directory
       filesystem.  When  sge_execd(8)  launches  a job, it creates a uniquely-named directory in
       this filesystem for the purpose of holding scratch files  during  job  execution.  At  job
       completion,  this  directory  and  its contents are removed automatically. The environment
       variables TMPDIR and TMP are set to the path of each jobs scratch directory (type  string;
       default: /tmp).

   shell
       If  either  posix_compliant  or  script_from_stdin  is  specified  as the shell_start_mode
       parameter in sge_conf(5) the shell parameter specifies the executable path of the  command
       interpreter  (e.g.  sh(1) or csh(1)) to be used to process the job scripts executed in the
       queue. The definition of shell can be overruled by  the  job  owner  via  the  qsub(1)  -S
       option.

       The type of the parameter is string. The default is /bin/csh.

   shell_start_mode
       This parameter defines the mechanisms which are used to actually invoke the job scripts on
       the execution hosts. The following values are recognized:

       unix_behavior
              If a user starts a job shell script under UNIX interactively by  invoking  it  just
              with  the script name the operating system's executable loader uses the information
              provided in a comment such as `#!/bin/csh' in the  first  line  of  the  script  to
              detect  which  command interpreter to start to interpret the script. This mechanism
              is used by Sun Grid Engine when  starting  jobs  if  unix_behavior  is  defined  as
              shell_start_mode.

       posix_compliant
              POSIX  does  not  consider  first script line comments such a `#!/bin/csh' as being
              significant. The POSIX standard for  batch  queuing  systems  (P1003.2d)  therefore
              requires  a compliant queuing system to ignore such lines but to use user specified
              or configured default command interpreters instead. Thus,  if  shell_start_mode  is
              set  to  posix_compliant  Sun  Grid  Engine will either use the command interpreter
              indicated by the -S option of the qsub(1) command or the  shell  parameter  of  the
              queue to be used (see above).

       script_from_stdin
              Setting  the  shell_start_mode parameter either to posix_compliant or unix_behavior
              requires you to set the umask in use for sge_execd(8) such that every user has read
              access  to  the  active_jobs  directory in the spool directory of the corresponding
              execution daemon. In case you have prolog and epilog scripts configured, they  also
              need to be readable by any user who may execute jobs.
              If this violates your site's security policies you may want to set shell_start_mode
              to script_from_stdin. This will force Sun Grid Engine to open  the  job  script  as
              well  as  the  epilogue  and  prologue  scripts  for reading into STDIN as root (if
              sge_execd(8) was started as root) before changing to the job owner's user  account.
              The  script  is then fed into the STDIN stream of the command interpreter indicated
              by the -S option of the qsub(1) command or the shell parameter of the queue  to  be
              used (see above).
              Thus  setting  shell_start_mode  to  script_from_stdin also implies posix_compliant
              behavior. Note, however, that feeding scripts into the STDIN stream  of  a  command
              interpreter  may  cause  trouble  if  commands like rsh(1) are invoked inside a job
              script as they also process the STDIN stream  of  the  command  interpreter.  These
              problems can usually be resolved by redirecting the STDIN channel of those commands
              to come from /dev/null (e.g. rsh host  date  <  /dev/null).  Note  also,  that  any
              command-line options associated with the job are passed to the executing shell. The
              shell will only forward them to the job if they are not recognized as  valid  shell
              options.

       The   default   for   shell_start_mode   is   posix_compliant.   Note,  though,  that  the
       shell_start_mode can only be used for batch jobs submitted by qsub(1) and  can't  be  used
       for interactive jobs submitted by qrsh(1), qsh(1), qlogin(1).

   prolog
       The  executable path of a shell script that is started before execution of Sun Grid Engine
       jobs with the same environment setting as that for the Sun Grid Engine jobs to be  started
       afterwards. An optional prefix "user@" specifies the user under which this procedure is to
       be started. The procedures standard output and the error output stream are written to  the
       same  file used also for the standard output and error output of each job.  This procedure
       is intended as a means for the Sun Grid Engine administrator to automate the execution  of
       general  site  specific tasks like the preparation of temporary file systems with the need
       for the same context information as the job. This  queue  configuration  entry  overwrites
       cluster global or execution host specific prolog definitions (see sge_conf(5)).

       The  default  for  prolog  is  the  special value NONE, which prevents from execution of a
       prologue script.  The  special variables for constituting a command line are the same like
       in prolog definitions of the cluster configuration (see sge_conf(5)).

       Exit codes for the prolog attribute can be interpreted based on the following exit values:
              0: Success
              99: Reschedule job
              100: Put job in error state
              Anything else: Put queue in error state

   epilog
       The  executable  path of a shell script that is started after execution of Sun Grid Engine
       jobs with the same environment setting as that for the Sun Grid Engine jobs that has  just
       completed.  An optional prefix "user@" specifies the user under which this procedure is to
       be started. The procedures standard output and the error output stream are written to  the
       same  file  used also for the standard output and error output of each job. This procedure
       is intended as a means for the Sun Grid Engine administrator to automate the execution  of
       general  site  specific tasks like the cleaning up of temporary file systems with the need
       for the same context information as the job. This  queue  configuration  entry  overwrites
       cluster global or execution host specific epilog definitions (see sge_conf(5)).

       The  default  for  epilog  is  the  special value NONE, which prevents from execution of a
       epilogue script.  The  special variables for constituting a command line are the same like
       in prolog definitions of the cluster configuration (see sge_conf(5)).

       Exit codes for the epilog attribute can be interpreted based on the following exit values:
              0: Success
              99: Reschedule job
              100: Put job in error state
              Anything else: Put queue in error state

   starter_method
       The  specified  executable  path  will  be  used as a job starter facility responsible for
       starting batch jobs.  The executable path will be executed instead of the configured shell
       to  start  the  job. The job arguments will be passed as arguments to the job starter. The
       following environment variables are used to pass information to the job starter concerning
       the shell environment which was configured or requested to start the job.

       SGE_STARTER_SHELL_PATH
              The name of the requested shell to start the job

       SGE_STARTER_SHELL_START_MODE
              The configured shell_start_mode

       SGE_STARTER_USE_LOGIN_SHELL
              Set  to  "true"  if  the  shell  is  supposed  to  be  used  as  a login shell (see
              login_shells in sge_conf(5))

       The starter_method will not be invoked for qsh, qlogin or qrsh acting as rlogin.

   suspend_method
   resume_method
   terminate_method
       These parameters can be used for overwriting the default method used by  Sun  Grid  Engine
       for  suspension,  release  of  a suspension and for termination of a job. Per default, the
       signals SIGSTOP, SIGCONT and SIGKILL are delivered to the job to  perform  these  actions.
       However, for some applications this is not appropriate.

       If  no  executable path is given, Sun Grid Engine takes the specified parameter entries as
       the signal to be delivered instead of the default  signal.  A  signal  must  be  either  a
       positive  number  or  a signal name with "SIG" as prefix and the signal name as printed by
       kill -l (e.g.  SIGTERM).

       If an executable path is given (it must be an absolute path starting with a "/") then this
       command  together  with  its  arguments  is  started  by  Sun  Grid  Engine to perform the
       appropriate action. The following special variables are expanded at  runtime  and  can  be
       used  (besides  any  other  strings  which  have  to  be interpreted by the procedures) to
       constitute a command line:

       $host  The name of the host on which the procedure is started.

       $job_owner
              The user name of the job owner.

       $job_id
              Sun Grid Engine's unique job identification number.

       $job_name
              The name of the job.

       $queue The name of the queue.

       $job_pid
              The pid of the job.

   notify
       The time waited between delivery of SIGUSR1/SIGUSR2 notification signals and  suspend/kill
       signals if job was submitted with the qsub(1) -notify option.

   owner_list
       The  owner_list  enlists  comma  separated  the  login(1)  user  names  (see  user_name in
       sge_types(1)) of those users who are authorized to disable and suspend this queue  through
       qmod(1)  (Sun  Grid Engine operators and managers can do this by default). It is customary
       to set this field for queues on interactive workstations where the computing resources are
       shared  between  interactive  sessions  and Sun Grid Engine jobs, allowing the workstation
       owner to have priority access.  (default: NONE).

   user_lists
       The user_lists parameter contains a comma separated list of Sun Grid  Engine  user  access
       list  names  as  described  in access_list(5).  Each user contained in at least one of the
       enlisted access lists has access to the queue. If the user_lists parameter is set to  NONE
       (the  default)  any  user  has  access  being  not explicitly excluded via the xuser_lists
       parameter described below.  If a user is contained both in  an  access  list  enlisted  in
       xuser_lists and user_lists the user is denied access to the queue.

   xuser_lists
       The  xuser_lists  parameter contains a comma separated list of Sun Grid Engine user access
       list names as described in access_list(5).  Each user contained in at  least  one  of  the
       enlisted  access lists is not allowed to access the queue. If the xuser_lists parameter is
       set to NONE (the default) any user has access.  If a user is contained both in  an  access
       list enlisted in xuser_lists and user_lists the user is denied access to the queue.

   projects
       The  projects  parameter  contains a comma separated list of Sun Grid Engine projects (see
       project(5)) that have access to the queue. Any project not in this list are denied  access
       to  the  queue.  If  set  to  NONE  (the  default),  any  project  has  access that is not
       specifically excluded via the xprojects parameter described below. If a project is in both
       the projects and xprojects parameters, the project is denied access to the queue.

   xprojects
       The  xprojects  parameter contains a comma separated list of Sun Grid Engine projects (see
       project(5)) that are denied access to the queue. If set to NONE (the default), no projects
       are denied access other than those denied access based on the projects parameter described
       above.  If a project is in both the projects and  xprojects  parameters,  the  project  is
       denied access to the queue.

   subordinate_list
       There are two different types of subordination:

       1. Queuewise subordination

       A  list  of  Sun  Grid  Engine  queue  names  as  defined  for queue_name in sge_types(1).
       Subordinate relationships are in effect only between queue instances residing at the  same
       host.   The  relationship  does  not  apply  and is ignored when jobs are running in queue
       instances on other hosts.  Queue instances residing on the same  host  will  be  suspended
       when  a specified count of jobs is running in this queue instance.  The list specification
       is the same as that of the load_thresholds parameter above, e.g. low_pri_q=5,small_q.  The
       numbers  denote  the  job  slots of the queue that have to be filled in the superordinated
       queue to trigger the suspension of the subordinated queue.  If  no  value  is  assigned  a
       suspension is triggered if all slots of the queue are filled.

       On  nodes  which  host  more  than  one  queue, you might wish to accord better service to
       certain classes of jobs (e.g., queues that are dedicated to parallel processing might need
       priority over low priority production queues; default: NONE).

       2. Slotwise preemption

       The  slotwise  preemption  provides  a  means  to  ensure  that high priority jobs get the
       resources they need, while at the same time low priority jobs on the  same  host  are  not
       unnecessarily  preempted,  maximizing  the  host  utilization.  The slotwise preemption is
       designed to provide different preemption actions, but with the current implementation only
       suspension  is provided.  This means there is a subordination relationship defined between
       queues similar to the queuewise subordination, but if the suspend threshold  is  exceeded,
       not  the  whole  subordinated  queue  is suspended, there are only single tasks running in
       single slots suspended.

       Like with queuewise subordination, the subordination  relationships  are  in  effect  only
       between  queue instances residing at the same host. The relationship does not apply and is
       ignored when jobs and tasks are running in queue instances on other hosts.

       The syntax is:

       slots=<threshold>(<queue_list>)

       where
       <threshold> =a positive integer number
       <queue_list>=<queue_def>[,<queue_list>]
       <queue_def> =<queue>[:<seq_no>][:<action>]
       <queue>     =a Sun Grid Engine queue name as defined for
                    queue_name in sge_types(1).
       <seq_no>    =sequence number among all subordinated queues
                    of the same depth in the tree. The higher the
                    sequence number, the lower is the priority of
                    the queue.
                    Default is 0, which is the highest priority.
       <action>    =the action to be taken if the threshold is
                    exceeded. Supported is:
                    "sr": Suspend the task with the shortest run
                          time.
                    "lr": Suspend the task with the longest run
                          time.
                    Default is "sr".

       Some examples of possible configurations and their functionalities:

       a) The simplest configuration

       subordinate_list   slots=2(B.q)

       which means the queue "B.q" is subordinated to the current queue (let's  call  it  "A.q"),
       the suspend threshold for all tasks running in "A.q" and "B.q" on the current host is two,
       the sequence number of "B.q" is "0" and the action is "suspend task with shortest run time
       first". This subordination relationship looks like this:

             A.q
              |
             B.q

       This  could be a typical configuration for a host with a dual core CPU. This subordination
       configuration ensures that tasks that are scheduled to "A.q" always get  a  CPU  core  for
       themselves,  while jobs in "B.q" are not preempted as long as there are no jobs running in
       "A.q".

       If there is no task running in "A.q", two tasks are running in "B.q" and  a  new  task  is
       scheduled to "A.q", the sum of tasks running in "A.q" and "B.q" is three. Three is greater
       than two, this triggers the defined action. This causes the task  with  the  shortest  run
       time  in the subordinated queue "B.q" to be suspended. After suspension, there is one task
       running in "A.q", on task running in "B.q" and one task suspended in "B.q".

       b) A simple tree

       subordinate_list   slots=2(B.q:1, C.q:2)

       This defines a small tree that looks like this:

             A.q
            /   \
          B.q   C.q

       A use case for this configuration could be a host with a dual core CPU and queue "B.q" and
       "C.q"  for  jobs  with  different requirements, e.g. "B.q" for interactive jobs, "C.q" for
       batch jobs.  Again, the tasks in "A.q" always get a CPU core, while  tasks  in  "B.q"  and
       "C.q" are suspended only if the threshold of running tasks is exceeded.  Here the sequence
       number among the queues of the same depth comes into play.  Tasks scheduled to "B.q" can't
       directly trigger the suspension of tasks in "C.q", but if there is a task to be suspended,
       first "C.q" will be searched for a suitable task.

       If there is one task running in "A.q", one in "C.q" and a new task is scheduled to  "B.q",
       the  threshold  of "2" in "A.q", "B.q" and "C.q" is exceeded. This triggers the suspension
       of one task in either "B.q" or "C.q". The sequence number gives "B.q"  a  higher  priority
       than  "C.q", therefore the task in "C.q" is suspended. After suspension, there is one task
       running in "A.q", one task running in "B.q" and one task suspended in "C.q".

       c) More than two levels

       Configuration of A.q: subordinate_list   slots=2(B.q)
       Configuration of B.q: subordinate_list   slots=2(C.q)

       looks like this:

             A.q
              |
             B.q
              |
             C.q

       These are three queues with high, medium and low priority.  If  a  task  is  scheduled  to
       "C.q",  first  the  subtree  consisting of "B.q" and "C.q" is checked, the number of tasks
       running there is counted. If the threshold which is defined in "B.q" is exceeded, the  job
       in  "C.q"  is suspended. Then the whole tree is checked, if the number of tasks running in
       "A.q", "B.q" and "C.q" exceeds the threshold  defined  in  "A.q"  the  task  in  "C.q"  is
       suspended.  This  means,  the  effective  threshold  of any subtree is not higher than the
       threshold of the root node of the tree.  If in this example a task is scheduled to  "A.q",
       immediately  the  number of tasks running in "A.q", "B.q" and "C.q" is checked against the
       threshold defined in "A.q".

       d) Any tree

              A.q
             /   \
           B.q   C.q
          /     /   \
        D.q    E.q  F.q
                       \
                        G.q

       The computation of the tasks that are to be  (un)suspended  always  starts  at  the  queue
       instance  that is modified, i.e. a task is scheduled to, a task ends at, the configuration
       is modified, a manual or other automatic (un)suspend is issued, except when it is  a  leaf
       node,  like  "D.q",  "E.q"  and  "G.q" in this example. Then the computation starts at its
       parent queue instance (like "B.q", "C.q" or "F.q" in this example). From there  first  all
       running  tasks in the whole subtree of this queue instance are counted. If the sum exceeds
       the threshold configured in the subordinate_list, in this subtree a task is searched to be
       suspended.  Then  the  algorithm proceeds to the parent of this queue instance, counts all
       running tasks in the whole subtree below the parent and checks if the number  exceeds  the
       threshold  configured  at  the parent's subordinate_list. If so, it searches for a task to
       suspend in the whole subtree below the parent. And so on, until it  did  this  computation
       for the root node of the tree.

   complex_values
       complex_values  defines  quotas for resource attributes managed via this queue. The syntax
       is the same as for load_thresholds (see above). The quotas are  related  to  the  resource
       consumption of all jobs in a queue in the case of consumable resources (see complex(5) for
       details on consumable resources) or they are interpreted on a per queue  slot  (see  slots
       above)  basis  in the case of non-consumable resources. Consumable resource attributes are
       commonly used to manage free memory,  free  disk  space  or  available  floating  software
       licenses  while  non-consumable attributes usually define distinctive characteristics like
       type of hardware installed.

       For  consumable  resource  attributes  an  available  resource  amount  is  determined  by
       subtracting  the  current  resource  consumption of all running jobs in the queue from the
       quota in the complex_values list. Jobs can only be dispatched to a queue  if  no  resource
       requests exceed any corresponding resource availability obtained by this scheme. The quota
       definition in the complex_values list is automatically replaced by the current load  value
       reported  for  this  attribute, if load is monitored for this resource and if the reported
       load value is more stringent than the quota. This effectively avoids  oversubscription  of
       resources.

       Note:  Load  values  replacing  the  quota  specifications  may have become more stringent
       because they have been scaled (see host_conf(5)) and/or load adjusted (see sched_conf(5)).
       The  -F  option  of  qstat(1)  and  the  load  display in the qmon(1) queue control dialog
       (activated by clicking on a queue icon while the "Shift" key is pressed) provide  detailed
       information  on  the  actual availability of consumable resources and on the origin of the
       values taken into account currently.

       Note  also:  The  resource  consumption  of  running  jobs  (used  for  the   availability
       calculation)  as well as the resource requests of the jobs waiting to be dispatched either
       may be derived from explicit user requests during job submission (see  the  -l  option  to
       qsub(1))  or  from a "default" value configured for an attribute by the administrator (see
       complex(5)).  The -r option to qstat(1) can be used for  retrieving  full  detail  on  the
       actual resource requests of all jobs in the system.

       For  non-consumable resources Sun Grid Engine simply compares the job's attribute requests
       with the corresponding specification in complex_values taking the relation operator of the
       complex  attribute  definition  into  account  (see  complex(5)).   If  the  result of the
       comparison is "true", the queue is suitable for the job with  respect  to  the  particular
       attribute. For parallel jobs each queue slot to be occupied by a parallel task is meant to
       provide the same resource attribute value.

       Note: Only numeric complex attributes can be defined as  consumable  resources  and  hence
       non-numeric attributes are always handled on a per queue slot basis.

       The  default  value  for  this  parameter  is NONE, i.e. no administrator defined resource
       attribute quotas are associated with the queue.

   calendar
       specifies the calendar to be valid for this  queue  or  contains  NONE  (the  default).  A
       calendar  defines  the  availability  of  a queue depending on time of day, week and year.
       Please refer to calendar_conf(5) for details on the Sun Grid Engine calendar facility.

       Note: Jobs can request queues with a certain calendar model via a "-l c=<cal_name>" option
       to qsub(1).

   initial_state
       defines  an initial state for the queue either when adding the queue to the system for the
       first time or on start-up of the sge_execd(8) on the host  on  which  the  queue  resides.
       Possible values are:

       default   The  queue  is  enabled when adding the queue or is reset to the previous status
                 when sge_execd(8) comes up (this corresponds to the behavior in earlier Sun Grid
                 Engine releases not supporting initial_state).

       enabled   The queue is enabled in either case. This is equivalent to a manual and explicit
                 'qmod -e' command (see qmod(1)).

       disabled  The queue is disable in either case. This is equivalent to a manual and explicit
                 'qmod -d' command (see qmod(1)).

RESOURCE LIMITS

       The  first  two  resource  limit  parameters,  s_rt  and h_rt, are implemented by Sun Grid
       Engine. They define the "real time" or also called "elapsed" or "wall clock"  time  having
       passed  since  the start of the job. If h_rt is exceeded by a job running in the queue, it
       is aborted via the SIGKILL signal (see kill(1)).  If s_rt is exceeded, the  job  is  first
       "warned" via the SIGUSR1 signal (which can be caught by the job) and finally aborted after
       the notification time defined in the queue configuration parameter notify (see above)  has
       passed.  In  cases  when  s_rt  is  used  in combination with job notification it might be
       necessary to configure a signal other than SIGUSR1 using the NOTIFY_KILL  and  NOTIFY_SUSP
       execd_params  (see  sge_conf(5))  so that the jobs' signal-catching mechanism can "differ"
       the cases and react accordingly.

       The resource limit parameters s_cpu and h_cpu are implemented by Sun Grid Engine as a  job
       limit.  They  impose  a  limit  on  the  amount  of  combined CPU time consumed by all the
       processes in the job.  If h_cpu is exceeded by a job running in the queue, it  is  aborted
       via  a  SIGKILL  signal  (see  kill(1)).   If s_cpu is exceeded, the job is sent a SIGXCPU
       signal which can be caught by the job.  If you wish to allow a job to be  "warned"  so  it
       can  exit  gracefully  before  it is killed then you should set the s_cpu limit to a lower
       value than h_cpu.  For parallel processes, the limit is applied per slot which means  that
       the limit is multiplied by the number of slots being used by the job before being applied.

       The  resource  limit  parameters s_vmem and h_vmem are implemented by Sun Grid Engine as a
       job limit.  They impose a limit on the amount of combined virtual memory consumed  by  all
       the  processes  in  the  job.  If  h_vmem is exceeded by a job running in the queue, it is
       aborted via a SIGKILL signal (see kill(1)).  If s_vmem is exceeded,  the  job  is  sent  a
       SIGXCPU  signal which can be caught by the job.  If you wish to allow a job to be "warned"
       so it can exit gracefully before it is killed then you should set the s_vmem  limit  to  a
       lower  value  than  h_vmem.   For  parallel processes, the limit is applied per slot which
       means that the limit is multiplied by the number of slots being used  by  the  job  before
       being applied.

       The remaining parameters in the queue configuration template specify per job soft and hard
       resource limits as implemented by the setrlimit(2) system call. See this  manual  page  on
       your  system for more information.  By default, each limit field is set to infinity (which
       means RLIM_INFINITY as described in the setrlimit(2) manual page). The value type for  the
       CPU-time  limits  s_cpu  and h_cpu is time. The value type for the other limits is memory.
       Note: Not all systems support setrlimit(2).

       Note also: s_vmem and h_vmem (virtual memory) are only  available  on  systems  supporting
       RLIMIT_VMEM (see setrlimit(2) on your operating system).

       The  UNICOS operating system supplied by SGI/Cray does not support the setrlimit(2) system
       call, using their own resource limit-setting system  call  instead.   For  UNICOS  systems
       only, the following meanings apply:

       s_cpu     The per-process CPU time limit in seconds.

       s_core    The per-process maximum core file size in bytes.

       s_data    The per-process maximum memory limit in bytes.

       s_vmem    The same as s_data (if both are set the minimum is used).

       h_cpu     The per-job CPU time limit in seconds.

       h_data    The per-job maximum memory limit in bytes.

       h_vmem    The same as h_data (if both are set the minimum is used).

       h_fsize   The total number of disk blocks that this job can create.

SEE ALSO

       sge_intro(1),  sge_types(1),  csh(1),  qconf(1),  qmon(1), qrestart(1), qstat(1), qsub(1),
       sh(1), nice(2), setrlimit(2), access_list(5), calendar_conf(5),  sge_conf(5),  complex(5),
       host_conf(5), sched_conf(5), sge_execd(8), sge_qmaster(8), sge_shepherd(8).

COPYRIGHT

       See sge_intro(1) for a full statement of rights and permissions.