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



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

[1mDESCRIPTION[0m
       [4mQueue_conf[24m  reflects  the  format  of the template file for the cluster
       queue configuration.  Via the [1m-aq [22mand [1m-mq [22moptions of the [4mqconf[24m(1)  com-
       mand,  you  can  add cluster queues and modify the configuration of any
       queue in the cluster.

       The [4mqueue_conf[24m parameters take as values strings, integer decimal  num-
       bers  or boolean, time and memory specifiers as well as comma separated
       lists. A time specifier either consists of a positive decimal, hexadec-
       imal  or octal integer constant, in which case the value is interpreted
       to be in seconds, or is built by 3 decimal integer numbers separated by
       colon  signs  where  the  first number counts the hours, the second the
       minutes and the third the seconds. If a number would be zero it can  be
       left  out but the separating colon must remain (e.g. 1:0:1 = 1::1 means
       1 hours and 1 second).

       Memory specifiers are positive decimal, hexadecimal  or  octal  integer
       constants  which  may  be followed by a multiplier letter. Valid multi-
       plier letters are k, K, m, M, g and G, where k means multiply the value
       by  1000,  K  multiply  by 1024, m multiply by 1000*1000, M multiply by
       1024*1024,  g  multiply   by   1000*1000*1000   and   G   multiply   by
       1024*1024*1024.  If no multiplier is present, the value is just counted
       in bytes.

       If more than one host is specified under 'hostlist' (by means of a list
       of  hosts  or  with  host groups) it can be desirable to specify diver-
       gences from the setting used for each host. These  divergences  can  be
       expressed  using the enhanced [4mqueue_conf[24m specifier syntax.  This syntax
       builds upon the regular parameter specifier syntax as  described  below
       under  'FORMAT'  separately  for  each  parameter  and in the paragraph
       above:

       "["host_identifier=<parameters_specifier_syntax>"]"   [,"["host_identi-
       fier=<parameters_specifier_syntax>"]" ]

       Even in the enhanced [4mqueue_conf[24m specifier syntax an entry

       <current_attribute_syntax>

       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 [4mqueue_conf[24m specifier syntax a
       default setting is always needed for all configuration attributes.

       Integrity verifications will be applied on the configuration.

       Configurations without default setting are rejected.  Ambiguous config-
       urations 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-sick [22mof
       [4mqconf[24m(1) The cluster queue should contain an unambiguous  specification
       for each configuration attribute of each queue instance specified under
       hostname in [4mqueue_conf[24m. 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.

[1mFORMAT[0m
       The  following  list  of [4mqueue_conf[24m parameters specifies the [4mqueue_conf[0m
       content:

   [1mqname[0m
       The name of the cluster queue(type string; template default: template).

   [1mhostlist[0m
       A list of host names (fully-qualified) and host group names. Host group
       names must begin with an "@" sign. If multiple hosts are specified  the
       [4mqueue_conf[24m constitutes multiple queue instances. Each host may be spec-
       ified only once in this list. (type string; template default: NONE).

   [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 name 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).

       [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.

   [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).

   [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  [4msge_execd[24m(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 [4msge_qmaster[24m(8) as a string.

       Currently,  support  is  only  provided for SGI multiprocessor machines
       running IRIX 6.2 and Digital UNIX multiprocessor machines. 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 environments to  be  associ-
       ated with the queue. The default is [4mNONE.[0m

   [1mckpt_list[0m
       The  list of administrator-defined checkpointing interfaces to be asso-
       ciated 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 [4msge_shepherd[24m(8) of the  jobs  and  their  process
       hierarchy)  on the queue host. As soon as [4msge_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.

   [1mtmpdir[0m
       The  [1mtmpdir  [22mparameter  specifies  the absolute path to the base of the
       temporary directory filesystem. When [4msge_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 [4msge_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
              [4msge_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 [4msge_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  can  only used for batch jobs submitted by[0m
       [1mqsub and can not used for interactive jobs submitted by qrsh, qsh, qlo-[0m
       [1mgin.[0m

   [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 [4msge_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 [4msge_conf[24m(5)).

   [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 [4msge_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 [4msge_conf[24m(5)).


   [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 [4msge_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 [22mnames the login names (in a  comma  separated  list)  of
       those  users  who  are  authorized  to  disable  and suspend this queue
       through [4mqmod[24m(1) (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  interac-
       tive  sessions  and Grid Engine jobs, allowing the workstation owner to
       have priority access (type string; default: NONE).

   [1muser_lists[0m
       The [1muser_lists [22mparameter contains a comma separated list of  so  called
       user  access lists as described in [4maccess_list[24m(5).  Each user contained
       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  [22mparameter
       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 so called
       user access lists 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 projects that
       have access to the queue. Any projects 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[0m
       parameters, the project is denied access to the queue.

   [1mxprojects[0m
       The [1mxprojects [22mparameter contains a comma  separated  list  of  projects
       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 cluster queues. Subordinate relationships are in
       effect only between queue instances residing at the same host. If there
       is  a queue instance (be in the sub- or superordinated one) on only one
       particular host this relationship is ignored.  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 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 [4msge_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 [4msge_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
       [4msge_intro[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),   [4msge_conf[24m(5),  [4mcomplex[24m(5),  [4mhost_conf[24m(5),  [4msched_conf[24m(5),
       [4msge_execd[24m(8), [4msge_qmaster[24m(8), [4msge_shepherd[24m(8).

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



GE 6.0                   $Date: 2007/06/05 16:55:36 $            QUEUE_CONF(5)
