QUEUE_CONF(5)              Grid Engine File Formats              QUEUE_CONF(5)



[1mNAME[0m
       queue_conf - Grid Engine queue configuration file format

[1mDESCRIPTION[0m
       This  manual  page  describes  the  format of the template file for the
       cluster queue configuration.  Via  the  [1m-aq  [22mand  [1m-mq  [22moptions  of  the
       [4mqconf[24m(1)  command, you can add cluster queues and modify the configura-
       tion 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 dec-
       imal numbers or boolean, time and memory specifiers (see [4mtime_specifier[0m
       and [4mmemory_specifier[24m in [4msge_types[24m(5)) as well as comma separated lists.

       Note, 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.

[1mFORMAT[0m
       The following list of parameters specifies the queue configuration file
       content:

   [1mqname[0m
       The   name   of   the  cluster  queue  as  defined  for  [4mqueue_name[24m  in
       [4msge_types[24m(1).  As template default "template" is used.

   [1mhostlist[0m
       A  list  of  host  identifiers  as  defined  for   [4mhost_identifier[24m   in
       [4msge_types[24m(1).  For each host 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:

       "["[4mhost_identifier[24m=<parameters_specifier_syntax>"]"   [,"["[4mhost_identi-[0m
       [4mfier[24m=<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 [4mhost_identifier[24m 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; oth-
       erwise  the queue configuration gets rejected. Ambiguous queue configu-
       rations 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  [1m-sds  [22mof
       [4mqconf[24m(1).   The  cluster queue should contain an unambiguous specifica-
       tion 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  [1m-explain  c [22mof [4mqstat[24m(1) and cause the queue
       instance with ambiguous  configurations  to  enter  the  c(onfiguration
       ambiguous) state.


   [1mseq_no[0m
       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
       [1mqueue_sort_method [22m(see [4msched_conf[24m(5) ).

       Regardless of the [1mqueue_sort_method  [22msetting,  [4mqstat[24m(1)  reports  queue
       information  in  the order defined by the value of the [1mseq_no[22m. Set this
       parameter to a monotonically increasing sequence.  (type  number;  tem-
       plate default: 0).

   [1mload_thresholds[0m
       [1mload_thresholds  [22mis  a  list  of load thresholds. Already if one of the
       thresholds is exceeded no further jobs will be scheduled to the  queues
       and  [4mqmon[24m(1) will signal an overload condition for this node. Arbitrary
       load values being defined in the "host"  and  "global"  complexes  (see
       [4mcomplex[24m(5) for details) can be used.

       The  syntax  is  that  of a comma separated list with each list element
       consisting of the [4mcomplex_name[24m (see [4msge_types[24m(5)) of a load  value,  an
       equal  sign and the threshold value being intended to trigger the over-
       load situation (e.g. load_avg=1.75,users_logged_in=5).

       [1mNote: [22mLoad values as well as consumable resources may be scaled differ-
       ently  for  different hosts if specified in the corresponding execution
       host definitions (refer to [4mhost_conf[24m(5)  for  more  information).  Load
       thresholds  are compared against the scaled load and consumable values.

   [1msuspend_thresholds[0m
       A list of load thresholds with  the  same  semantics  as  that  of  the
       [1mload_thresholds  [22mparameter (see above) except that exceeding one of the
       denoted thresholds initiates suspension of one of multiple jobs in  the
       queue.   See  the [1mnsuspend [22mparameter below for details on the number of
       jobs which are suspended.

   [1mnsuspend[0m
       The number of jobs which are suspended/enabled per time interval if  at
       least  one  of  the  load  thresholds in the [1msuspend_thresholds [22mlist is
       exceeded or if no [1msuspend_threshold [22mis violated  anymore  respectively.
       [1mNsuspend  [22mjobs  are  suspended  in  each  time  interval  until no [1msus-[0m
       [1mpend_thresholds [22mare exceeded anymore or all jobs in the queue are  sus-
       pended.  Jobs  are  enabled  in  the  corresponding  way  if  the  [1msus-[0m
       [1mpend_thresholds [22mare no longer exceeded.  The time interval in which the
       suspensions of the jobs occur is defined in [1msuspend_interval [22mbelow.

   [1msuspend_interval[0m
       The  time  interval in which further [1mnsuspend [22mjobs are suspended if one
       of the [1msuspend_thresholds [22m(see above for both) is exceeded by the  cur-
       rent 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
       [4mtime_specifier[24m in [4msge_types[24m(5).

   [1mpriority[0m
       The  [1mpriority  [22mparameter  specifies  the [4mnice[24m(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 Grid Engine adjusts pri-
       orities dynamically to implement ticket-based entitlement policy goals.
       Dynamic  priority  adjustment  is  switched   off  by  default  due  to
       [4msge_conf[24m(5) [1mreprioritize [22mbeing set to false.

   [1mmin_cpu_interval[0m
       The time between two automatic checkpoints  in  case  of  transparently
       checkpointing  jobs.  The maximum of the time requested by the user via
       [4mqsub[24m(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 inter-
       vals. [1mmin_cpu_interval [22mis of type time and the  default  is  5  minutes
       (which usually is suitable for test purposes only).  The syntax is that
       of a [4mtime_specifier[24m in [4msge_types[24m(5).

   [1mprocessors[0m
       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  [1m-pe[0m
       option  of  [4mqsub[24m(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 [4mge_execd[24m(8) running on the queue host. Therefore, the parsing of
       the parameter has to be provided by the execution daemon and the param-
       eter is only passed through [4mge_qmaster[24m(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.  [1mslots [22m(see above) should be set to 1 for this queue.

   [1mqtype[0m
       The type of queue. Currently [4mbatch,[24m [4minteractive[24m or a combination  in  a
       comma separated list or [4mNONE.[0m

       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 speci-
       fied for this queue instance in [1mpe_list[22m/[1mckpt_list[22m.   Formerly  possible
       settings e.g.

       qtype   PARALLEL

       could be transferred into

       qtype   NONE
       pe_list pe_name

       (type string; default: batch interactive).

   [1mpe_list[0m
       The  list of administrator-defined parallel environment (see [4msge_pe[24m(5))
       names to be associated with the queue. The default is [4mNONE.[0m

   [1mckpt_list[0m
       The list of administrator-defined checkpointing  interface  names  (see
       [4mckpt_name[24m in [4msge_types[24m(1)) to be associated with the queue. The default
       is [4mNONE.[0m

   [1mrerun[0m
       Defines a default behavior for jobs which are aborted by system crashes
       or  manual "violent" (via [4mkill[24m(1)) shutdown of the complete Grid Engine
       system (including the [4mge_shepherd[24m(8) of  the  jobs  and  their  process
       hierarchy)  on  the queue host. As soon as [4mge_execd[24m(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 [1m-r[0m
       option of [4mqsub[24m(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 automati-
       cally.

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

   [1mtmpdir[0m
       The  [1mtmpdir  [22mparameter  specifies  the absolute path to the base of the
       temporary directory filesystem. When [4mge_execd[24m(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).

   [1mshell[0m
       If  either  [4mposix_compliant[24m  or  [4mscript_from_stdin[24m  is specified as the
       [1mshell_start_mode [22mparameter in [4mge_conf[24m(5) the [1mshell [22mparameter  specifies
       the  executable path of the command interpreter (e.g.  [4msh[24m(1) or [4mcsh[24m(1))
       to be used to process the job scripts executed in the queue. The  defi-
       nition  of  [1mshell  [22mcan be overruled by the job owner via the [4mqsub[24m(1) [1m-S[0m
       option.

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

   [1mshell_start_mode[0m
       This parameter defines the mechanisms which are used to actually invoke
       the job scripts on the execution hosts. The following values are recog-
       nized:

       [4munix_behavior[0m
              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  Grid  Engine  when  starting  jobs  if
              [4munix_behavior[24m is defined as [1mshell_start_mode[22m.

       [4mposix_compliant[0m
              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  queu-
              ing  system  to  ignore  such lines but to use user specified or
              configured  default  command  interpreters  instead.  Thus,   if
              [1mshell_start_mode  [22mis  set  to  [4mposix_compliant[24m  Grid Engine will
              either use the command interpreter indicated by the [1m-S [22moption of
              the  [4mqsub[24m(1)  command  or the [1mshell [22mparameter of the queue to be
              used (see above).

       [4mscript_from_stdin[0m
              Setting the [1mshell_start_mode [22mparameter either to [4mposix_compliant[0m
              or  [4munix_behavior[24m  requires  you  to  set  the  umask in use for
              [4mge_execd[24m(8)  such  that  every  user  has  read  access  to  the
              active_jobs  directory in the spool directory of the correspond-
              ing execution daemon. In case you have [1mprolog [22mand [1mepilog [22mscripts
              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  [1mshell_start_mode [22mto [4mscript_from_stdin[24m. This will force Grid
              Engine to open the job script as well as the epilogue  and  pro-
              logue scripts for reading into STDIN as root (if [4mge_execd[24m(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 [1m-S [22moption  of  the  [4mqsub[24m(1)
              command  or  the  [1mshell  [22mparameter  of the queue to be used (see
              above).
              Thus setting [1mshell_start_mode [22mto [4mscript_from_stdin[24m also  implies
              [4mposix_compliant[24m  behavior.  [1mNote[22m,  however, that feeding scripts
              into the STDIN stream of a command interpreter may cause trouble
              if  commands like [4mrsh[24m(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 chan-
              nel of those commands to come from /dev/null (e.g. rsh host date
              <  /dev/null).  [1mNote also[22m, that any command-line options associ-
              ated 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 [1mshell_start_mode  [22mis  [4mposix_compliant[24m.   Note,  though,
       that  the [1mshell_start_mode [22mcan only be used for batch jobs submitted by
       [4mqsub[24m(1) and can't be used for interactive jobs  submitted  by  [4mqrsh[24m(1),
       [4mqsh[24m(1), [4mqlogin[24m(1).

   [1mprolog[0m
       The  executable path of a shell script that is started before execution
       of Grid Engine jobs with the same environment setting as that  for  the
       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 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 [1mprolog [22mdefinitions
       (see [4mge_conf[24m(5)).

       The default for [1mprolog [22mis the special value NONE, which  prevents  from
       execution  of a prologue script.  The  special variables for constitut-
       ing a command line are the same like in [1mprolog [22mdefinitions of the clus-
       ter configuration (see [4mge_conf[24m(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

   [1mepilog[0m
       The executable path of a shell script that is started  after  execution
       of  Grid  Engine jobs with the same environment setting as that for the
       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  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 [1mepilog [22mdefinitions
       (see [4mge_conf[24m(5)).

       The  default  for [1mepilog [22mis the special value NONE, which prevents from
       execution of a epilogue script.  The  special variables for  constitut-
       ing a command line are the same like in [1mprolog [22mdefinitions of the clus-
       ter configuration (see [4mge_conf[24m(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

   [1mstarter_method[0m
       The  specified  executable  path will be used as a job starter facility
       responsible for starting batch jobs.  The executable path will be  exe-
       cuted  instead  of the configured shell to start the job. The job argu-
       ments 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.


       [4mSGE_STARTER_SHELL_PATH[0m
              The name of the requested shell to start the job

       [4mSGE_STARTER_SHELL_START_MODE[0m
              The configured [1mshell_start_mode[0m

       [4mSGE_STARTER_USE_LOGIN_SHELL[0m
              Set  to  "true"  if  the shell is supposed to be used as a login
              shell (see [1mlogin_shells [22min [4mge_conf[24m(5))

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


   [1msuspend_method[0m
   [1mresume_method[0m
   [1mterminate_method[0m
       These parameters can be used for overwriting the default method used by
       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 appli-
       cations this is not appropriate.

       If no executable path is given, Grid Engine takes the specified parame-
       ter entries as the signal to be delivered instead of the  default  sig-
       nal.  A  signal  must be either a positive number or a signal name with
       [1m"SIG" [22mas prefix and the  signal  name  as  printed  by  [4mkill[24m  [4m-l[24m  (e.g.
       SIGTERM).

       If  an  executable  path is given (it must be an [4mabsolute[24m [4mpath[24m starting
       with a "/") then this command together with its arguments is started by
       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:


       [4m$host[24m  The name of the host on which the procedure is started.

       [4m$job_owner[0m
              The user name of the job owner.

       [4m$job_id[0m
              Grid Engine's unique job identification number.

       [4m$job_name[0m
              The name of the job.

       [4m$queue[24m The name of the queue.

       [4m$job_pid[0m
              The pid of the job.


   [1mnotify[0m
       The time waited between delivery of SIGUSR1/SIGUSR2  notification  sig-
       nals  and  suspend/kill  signals  if job was submitted with the [4mqsub[24m(1)
       [4m-notify[24m option.

   [1mowner_list[0m
       The [1mowner_list [22menlists comma separated the  [4mlogin[24m(1)  user  names  (see
       [4muser_name[24m in [4msge_types[24m(1)) of those users who are authorized to disable
       and suspend this queue through [4mqmod[24m(1) (Grid Engine operators and  man-
       agers  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 Grid Engine jobs, allowing the
       workstation owner to have priority access.  (default: NONE).

   [1muser_lists[0m
       The [1muser_lists [22mparameter contains a comma separated list of Grid Engine
       user  access list names as described in [4maccess_list[24m(5).  Each user con-
       tained in at least one of the enlisted access lists has access  to  the
       queue.  If  the  [1muser_lists  [22mparameter is set to NONE (the default) any
       user has access being  not  explicitly  excluded  via  the  [1mxuser_lists[0m
       parameter  described  below.   If a user is contained both in an access
       list enlisted in [1mxuser_lists [22mand [1muser_lists [22mthe user is  denied  access
       to the queue.

   [1mxuser_lists[0m
       The  [1mxuser_lists  [22mparameter  contains  a  comma  separated list of Grid
       Engine user access list names as  described  in  [4maccess_list[24m(5).   Each
       user  contained  in  at  least  one of the enlisted access lists is not
       allowed to access the queue. If the [1mxuser_lists  [22mparameter  is  set  to
       NONE (the default) any user has access.  If a user is contained both in
       an access list enlisted in  [1mxuser_lists  [22mand  [1muser_lists  [22mthe  user  is
       denied access to the queue.

   [1mprojects[0m
       The  [1mprojects  [22mparameter contains a comma separated list of Grid Engine
       projects (see [4mproject[24m(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  [1mxprojects  [22mparameter  described below. If a project is in both the
       [1mprojects [22mand [1mxprojects [22mparameters, the project is denied access to  the
       queue.

   [1mxprojects[0m
       The  [1mxprojects [22mparameter contains a comma separated list of Grid Engine
       projects (see [4mproject[24m(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 [1mprojects [22mparameter described  above.   If  a
       project  is  in both the [1mprojects [22mand [1mxprojects [22mparameters, the project
       is denied access to the queue.

   [1msubordinate_list[0m
       A list of  Grid  Engine  queue  names  as  defined  for  [4mqueue_name[24m  in
       [4msge_types[24m(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 [1mload_thresholds [22mparameter
       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  bet-
       ter 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).

   [1mcomplex_values[0m
       [1mcomplex_values  [22mdefines quotas for resource attributes managed via this
       queue. The syntax is the same as for [1mload_thresholds [22m(see  above).  The
       quotas  are  related to the resource consumption of all jobs in a queue
       in the case of consumable resources (see [4mcomplex[24m(5) for details on con-
       sumable  resources)  or  they  are interpreted on a per queue slot (see
       [1mslots [22mabove) 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 run-
       ning jobs in the queue from the quota in the [1mcomplex_values [22mlist.  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 [1mcomplex_values [22mlist 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.

       [1mNote: [22mLoad values replacing the quota specifications  may  have  become
       more  stringent because they have been scaled (see [4mhost_conf[24m(5)) and/or
       load adjusted (see [4msched_conf[24m(5)).  The [4m-F[24m option of [4mqstat[24m(1)  and  the
       load display in the [4mqmon[24m(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.

       [1mNote also: [22mThe 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 [4m-l[24m option to [4mqsub[24m(1)) or from a
       "default" value configured for an attribute by the  administrator  (see
       [4mcomplex[24m(5)).  The [4m-r[24m option to [4mqstat[24m(1) can be used for retrieving full
       detail on the actual resource requests of all jobs in the system.

       For non-consumable resources Grid  Engine  simply  compares  the  job's
       attribute requests with the corresponding specification in [1mcomplex_val-[0m
       [1mues [22mtaking the relation operator of the  complex  attribute  definition
       into  account  (see  [4mcomplex[24m(5)).   If  the result of the comparison is
       "true", the queue is suitable for the job with respect to the  particu-
       lar  attribute.  For  parallel jobs each queue slot to be occupied by a
       parallel task is meant to provide the same resource attribute value.

       [1mNote: [22mOnly 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.

   [1mcalendar[0m
       specifies the [1mcalendar [22mto 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 [4mcalendar_conf[24m(5) for
       details on the Grid Engine calendar facility.

       [1mNote: [22mJobs can request queues with a certain calendar model via  a  "[4m-l[0m
       [4mc=<cal_name>[24m" option to [4mqsub[24m(1).

   [1minitial_state[0m
       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 [4mge_execd[24m(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 [4mge_execd[24m(8) comes up  (this  corresponds
                 to  the behavior in earlier Grid Engine releases not support-
                 ing initial_state).

       enabled   The queue is enabled in either case. This is equivalent to  a
                 manual and explicit '[4mqmod[24m [4m-e[24m' command (see [4mqmod[24m(1)).

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


[1mRESOURCE LIMITS[0m
       The first two resource limit parameters, [1ms_rt [22mand [1mh_rt[22m, are implemented
       by Grid Engine. They define the "real time" or also called "elapsed" or
       "wall clock" time having passed since the start of the job. If [1mh_rt  [22mis
       exceeded  by  a job running in the queue, it is aborted via the SIGKILL
       signal (see [4mkill[24m(1)).  If [1ms_rt [22mis 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 [1mnotify [22m(see above) has passed.

       The  resource  limit parameters [1ms_cpu [22mand [1mh_cpu [22mare implemented by 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 [1mh_cpu [22mis
       exceeded by a job running in the queue, it is  aborted  via  a  SIGKILL
       signal  (see [4mkill[24m(1)).  If [1ms_cpu [22mis 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 [1ms_cpu [22mlimit to a lower value than [1mh_cpu[22m.   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 [1ms_vmem [22mand [1mh_vmem [22mare implemented by 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 [1mh_vmem [22mis
       exceeded by a job running in the queue, it is  aborted  via  a  SIGKILL
       signal (see kill(1)).  If [1ms_vmem [22mis 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 [1ms_vmem [22mlimit to a lower value than [1mh_vmem[22m.  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  [4msetr-[0m
       [4mlimit[24m(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 [4msetrlimit[24m(2) manual page). The
       value type for the CPU-time limits [1ms_cpu [22mand [1mh_cpu [22mis time.  The  value
       type  for  the  other  limits is memory.  [1mNote: [22mNot all systems support
       [4msetrlimit[24m(2).

       [1mNote also: [22ms_vmem and h_vmem (virtual memory)  are  only  available  on
       systems supporting RLIMIT_VMEM (see [4msetrlimit[24m(2) on your operating sys-
       tem).

       The UNICOS operating system supplied by SGI/Cray does not  support  the
       [4msetrlimit[24m(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.


[1mSEE ALSO[0m
       [4mge_intro[24m(1),  [4msge_types[24m(1),  [4mcsh[24m(1),  [4mqconf[24m(1),  [4mqmon[24m(1),  [4mqrestart[24m(1),
       [4mqstat[24m(1), [4mqsub[24m(1), [4msh[24m(1), [4mnice[24m(2), [4msetrlimit[24m(2), [4maccess_list[24m(5), [4mcalen-[0m
       [4mdar_conf[24m(5),  [4mge_conf[24m(5),  [4mcomplex[24m(5),   [4mhost_conf[24m(5),   [4msched_conf[24m(5),
       [4mge_execd[24m(8), [4mge_qmaster[24m(8), [4mge_shepherd[24m(8).

[1mCOPYRIGHT[0m
       See [4mge_intro[24m(1) for a full statement of rights and permissions.



GE 6.2u2                 $Date: 2009/01/12 13:54:14 $            QUEUE_CONF(5)
