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



NNAAMMEE
       queue_conf - Grid Engine queue configuration file format

DDEESSCCRRIIPPTTIIOONN
       _Q_u_e_u_e___c_o_n_f  reflects  the  format  of the template file for the cluster
       queue configuration.  You can add cluster queues and modify the config-
       uration  of any queue in the cluster via the --aaqq and --mmqq options of the
       _q_c_o_n_f(1) command.

       The _q_u_e_u_e___c_o_n_f 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 have user speci-
       fied overrides from the setting used for each host. These overrides can
       be expressed using the enhanced _q_u_e_u_e___c_o_n_f specifier syntax.  This syn-
       tax 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 _q_u_e_u_e___c_o_n_f specifier syntax an entry

       <current_attribute_syntax>

       without  brackets denoting the default setting is required and used for
       all queue instances where no user specified  overrides  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  also that a default setting is always
       needed for all configuration attributes with  the  enhanced  _q_u_e_u_e___c_o_n_f
       specifier syntax.

       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
       listed under 'hostname' are accepted but  are  indicated  by  --ssiicckk  of
       _q_c_o_n_f(1)  The cluster queue should contain an unambiguous specification
       for each configuration attribute of each queue instance specified under
       hostname  in  _q_u_e_u_e___c_o_n_f.  Ambiguous  configurations with more than one
       attribute setting resulting from overlapping host groups are  indicated
       by  --eexxppllaaiinn  cc of _q_s_t_a_t(1) and cause the queue instance with ambiguous
       configurations to enter the c(onfiguration ambiguous) state.

FFOORRMMAATT
       The following list of _q_u_e_u_e___c_o_n_f parameters  specifies  the  _q_u_e_u_e___c_o_n_f
       content:

   qqnnaammee
       The name of the cluster queue(type string; template default: template).

   hhoossttlliisstt
       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
       _q_u_e_u_e___c_o_n_f constitutes multiple queue instances. Each host may be spec-
       ified only once in this list. (type string; template default: NONE).

   sseeqq__nnoo
       This  parameter,  in  conjunction  with  the hosts load, specifies this
       queue's position in the scheduling order within the suitable queues for
       a  job  to  be  dispatched under consideration of the qquueeuuee__ssoorrtt__mmeetthhoodd
       (see _s_c_h_e_d___c_o_n_f(5) ).

       Regardless of the qquueeuuee__ssoorrtt__mmeetthhoodd  setting,  _q_s_t_a_t(1)  reports  queue
       information  in  the order defined by the value of the sseeqq__nnoo. Set this
       parameter to a monotonically increasing sequence.  (type  number;  tem-
       plate default: 0).

   llooaadd__tthhrreesshhoollddss
       llooaadd__tthhrreesshhoollddss  is a list of load thresholds. If one of the thresholds
       is exceeded no further jobs will be scheduled to the queues and _q_m_o_n(1)
       will  signal an overload condition for this node. Arbitrary load values
       being defined in the "host" and "global" complexes (see _c_o_m_p_l_e_x(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).

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

   ssuussppeenndd__tthhrreesshhoollddss
       A list of load thresholds with  the  same  semantics  as  that  of  the
       llooaadd__tthhrreesshhoollddss  parameter (see above) except that exceeding one of the
       denoted thresholds initiates suspension of one of multiple jobs in  the
       queue.   See  the nnssuussppeenndd parameter below for details on the number of
       jobs which are suspended.

   nnssuussppeenndd
       The number of jobs which are suspended/enabled per time interval if  at
       least  one  of  the  load  thresholds in the ssuussppeenndd__tthhrreesshhoollddss list is
       exceeded or if no ssuussppeenndd__tthhrreesshhoolldd is violated  anymore  respectively.
       NNssuussppeenndd  jobs  are  suspended  in  each  time  interval  until no ssuuss--
       ppeenndd__tthhrreesshhoollddss are exceeded anymore or all jobs in the queue are  sus-
       pended.  Jobs  are  enabled  in  the  corresponding  way  if  the  ssuuss--
       ppeenndd__tthhrreesshhoollddss are no longer exceeded.  The time interval in which the
       suspensions of the jobs occur is defined in ssuussppeenndd__iinntteerrvvaall below.

   ssuussppeenndd__iinntteerrvvaall
       The  time  interval in which further nnssuussppeenndd jobs are suspended if one
       of the ssuussppeenndd__tthhrreesshhoollddss (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.

   pprriioorriittyy
       The pprriioorriittyy parameter specifies the _n_i_c_e(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
       _s_g_e___c_o_n_f(5) rreepprriioorriittiizzee being set to false.

   mmiinn__ccppuu__iinntteerrvvaall
       The  time  between  two  automatic checkpoints in case of transparently
       checkpointing jobs. The maximum of the time requested by the  user  via
       _q_s_u_b(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.  mmiinn__ccppuu__iinntteerrvvaall  is  of  type time and the default is 5 minutes
       (which usually is suitable for test purposes only).

   pprroocceessssoorrss
       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  --ppee
       option  of  _q_s_u_b(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 _s_g_e___e_x_e_c_d(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 _s_g_e___q_m_a_s_t_e_r(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.   sslloottss  (see above) should be set to 1 for this
       queue.

   qqttyyppee
       The type of queue. Currently _b_a_t_c_h_, _i_n_t_e_r_a_c_t_i_v_e or a combination  in  a
       comma separated list or _N_O_N_E_.

       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 ppee__lliisstt/cckkpptt__lliisstt.   Formerly  possible
       settings e.g.

       qtype   PARALLEL

       could be transferred into

       qtype   NONE
       pe_list pe_name

       (type string; default: batch interactive).

   ppee__lliisstt
       The  list  of administrator-defined parallel environments to be associ-
       ated with the queue. The default is _N_O_N_E_.

   cckkpptt__lliisstt
       The list of administrator-defined checkpointing interfaces to be  asso-
       ciated with the queue. The default is _N_O_N_E_.

   rreerruunn
       Defines a default behavior for jobs which are aborted by system crashes
       or manual "violent" (via _k_i_l_l(1)) shutdown of the complete Grid  Engine
       system  (including  the  _s_g_e___s_h_e_p_h_e_r_d(8)  of the jobs and their process
       hierarchy) on the queue host. As soon as _s_g_e___e_x_e_c_d(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 --rr
       option of _q_s_u_b(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.

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

   ttmmppddiirr
       The ttmmppddiirr parameter specifies the absolute path to  the  base  of  the
       temporary  directory  filesystem.  When _s_g_e___e_x_e_c_d(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).

   sshheellll
       If either _p_o_s_i_x___c_o_m_p_l_i_a_n_t or  _s_c_r_i_p_t___f_r_o_m___s_t_d_i_n  is  specified  as  the
       sshheellll__ssttaarrtt__mmooddee parameter in _s_g_e___c_o_n_f(5) the sshheellll parameter specifies
       the executable path of the command interpreter (e.g.  _s_h(1) or  _c_s_h(1))
       to  be used to process the job scripts executed in the queue. The defi-
       nition of sshheellll can be overruled by the job owner via  the  _q_s_u_b(1)  --SS
       option.

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

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

       _u_n_i_x___b_e_h_a_v_i_o_r
              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
              _u_n_i_x___b_e_h_a_v_i_o_r is defined as sshheellll__ssttaarrtt__mmooddee.

       _p_o_s_i_x___c_o_m_p_l_i_a_n_t
              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
              sshheellll__ssttaarrtt__mmooddee is set  to  _p_o_s_i_x___c_o_m_p_l_i_a_n_t  Grid  Engine  will
              either use the command interpreter indicated by the --SS option of
              the _q_s_u_b(1) command or the sshheellll parameter of the  queue  to  be
              used (see above).

       _s_c_r_i_p_t___f_r_o_m___s_t_d_i_n
              Setting the sshheellll__ssttaarrtt__mmooddee parameter either to _p_o_s_i_x___c_o_m_p_l_i_a_n_t
              or _u_n_i_x___b_e_h_a_v_i_o_r requires you  to  set  the  umask  in  use  for
              _s_g_e___e_x_e_c_d(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 pprroolloogg and eeppiilloogg 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 sshheellll__ssttaarrtt__mmooddee to _s_c_r_i_p_t___f_r_o_m___s_t_d_i_n. 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  _s_g_e___e_x_e_c_d(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 --SS option of the _q_s_u_b(1)
              command or the sshheellll parameter of the  queue  to  be  used  (see
              above).
              Thus  setting sshheellll__ssttaarrtt__mmooddee to _s_c_r_i_p_t___f_r_o_m___s_t_d_i_n also implies
              _p_o_s_i_x___c_o_m_p_l_i_a_n_t behavior. NNoottee, however,  that  feeding  scripts
              into the STDIN stream of a command interpreter may cause trouble
              if commands like _r_s_h(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). NNoottee aallssoo, 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  sshheellll__ssttaarrtt__mmooddee  is _p_o_s_i_x___c_o_m_p_l_i_a_n_t.  Note, though,
       that the sshheellll__ssttaarrtt__mmooddee ccaann oonnllyy uusseedd ffoorr  bbaattcchh  jjoobbss  ssuubbmmiitttteedd  bbyy
       qqssuubb aanndd ccaann nnoott uusseedd ffoorr iinntteerraaccttiivvee jjoobbss ssuubbmmiitttteedd bbyy qqrrsshh,, qqsshh,, qqlloo--
       ggiinn..

   pprroolloogg
       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 pprroolloogg definitions
       (see _s_g_e___c_o_n_f(5)).

       The  default  for pprroolloogg is 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 pprroolloogg definitions of the clus-
       ter configuration (see _s_g_e___c_o_n_f(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

   eeppiilloogg
       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 eeppiilloogg definitions
       (see _s_g_e___c_o_n_f(5)).

       The default for eeppiilloogg is 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 pprroolloogg definitions of the clus-
       ter configuration (see _s_g_e___c_o_n_f(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

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


       _S_G_E___S_T_A_R_T_E_R___S_H_E_L_L___P_A_T_H
              The name of the requested shell to start the job

       _S_G_E___S_T_A_R_T_E_R___S_H_E_L_L___S_T_A_R_T___M_O_D_E
              The configured sshheellll__ssttaarrtt__mmooddee

       _S_G_E___S_T_A_R_T_E_R___U_S_E___L_O_G_I_N___S_H_E_L_L
              Set to "true" if the shell is supposed to be  used  as  a  login
              shell (see llooggiinn__sshheellllss in _s_g_e___c_o_n_f(5))

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


   ssuussppeenndd__mmeetthhoodd
   rreessuummee__mmeetthhoodd
   tteerrmmiinnaattee__mmeetthhoodd
       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. By 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
       ""SSIIGG""  as  prefix  and  the  signal  name  as  printed by _k_i_l_l _-_l (e.g.
       SIGTERM).

       If an executable path is given (it must be an  _a_b_s_o_l_u_t_e  _p_a_t_h  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:


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

       _$_j_o_b___o_w_n_e_r
              The user name of the job owner.

       _$_j_o_b___i_d
              Grid Engine's unique job identification number.

       _$_j_o_b___n_a_m_e
              The name of the job.

       _$_q_u_e_u_e The name of the queue.

       _$_j_o_b___p_i_d
              The pid of the job.


   nnoottiiffyy
       The  time to wait between delivery of SIGUSR1/SIGUSR2 notification sig-
       nals and suspend/kill signals if job was  submitted  with  the  _q_s_u_b(1)
       _-_n_o_t_i_f_y option.

   oowwnneerr__lliisstt
       The  oowwnneerr__lliisstt  names  the  login names (in a comma separated list) of
       those users who are  authorized  to  disable  and  suspend  this  queue
       through  _q_m_o_d(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).

   uusseerr__lliissttss
       The  uusseerr__lliissttss  parameter contains a comma separated list of so called
       user access lists as described in _a_c_c_e_s_s___l_i_s_t(5).  Each user  contained
       in  at least one of the listed access lists has access to the queue. If
       the uusseerr__lliissttss parameter is set to NONE  (the  default)  any  user  has
       access  being  not  explicitly  excluded  via the xxuusseerr__lliissttss parameter
       described below.  If a user is contained both in an access list  listed
       in xxuusseerr__lliissttss and uusseerr__lliissttss the user is denied access to the queue.

   xxuusseerr__lliissttss
       The  xxuusseerr__lliissttss parameter contains a comma separated list of so called
       user access lists as described in _a_c_c_e_s_s___l_i_s_t(5).  Each user  contained
       in at least one of the listed access lists is not allowed to access the
       queue. If the xxuusseerr__lliissttss parameter is set to NONE  (the  default)  any
       user  has access.  If a user is contained both in an access list listed
       in xxuusseerr__lliissttss and uusseerr__lliissttss the user is denied access to the queue.

   pprroojjeeccttss
       The pprroojjeeccttss parameter 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 xxpprroojjeeccttss parameter
       described below. If a project is in both  the  pprroojjeeccttss  and  xxpprroojjeeccttss
       parameters, the project is denied access to the queue.

   xxpprroojjeeccttss
       The  xxpprroojjeeccttss  parameter  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
       pprroojjeeccttss parameter described above.   If  a  project  is  in  both  the
       pprroojjeeccttss  and xxpprroojjeeccttss parameters, the project is denied access to the
       queue.

   ssuubboorrddiinnaattee__lliisstt
       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 llooaadd__tthhrreesshhoollddss parameter 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).

   ccoommpplleexx__vvaalluueess
       ccoommpplleexx__vvaalluueess  defines quotas for resource attributes managed via this
       queue. The syntax is the same as for llooaadd__tthhrreesshhoollddss (see  above).  The
       quotas  are  related to the resource consumption of all jobs in a queue
       in the case of consumable resources (see _c_o_m_p_l_e_x(5) for details on con-
       sumable  resources)  or  they  are interpreted on a per queue slot (see
       sslloottss 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 run-
       ning jobs in the queue from the quota in the ccoommpplleexx__vvaalluueess 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 ccoommpplleexx__vvaalluueess 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.

       NNoottee:: Load values replacing the quota specifications  may  have  become
       more  stringent because they have been scaled (see _h_o_s_t___c_o_n_f(5)) and/or
       load adjusted (see _s_c_h_e_d___c_o_n_f(5)).  The _-_F option of _q_s_t_a_t(1)  and  the
       load display in the _q_m_o_n(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.

       NNoottee aallssoo:: 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 _q_s_u_b(1)) or from a
       "default" value configured for an attribute by the  administrator  (see
       _c_o_m_p_l_e_x(5)).  The _-_r option to _q_s_t_a_t(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 ccoommpplleexx__vvaall--
       uueess taking the relation operator of the  complex  attribute  definition
       into  account  (see  _c_o_m_p_l_e_x(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.

       NNoottee:: 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.

   ccaalleennddaarr
       specifies the ccaalleennddaarr 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 _c_a_l_e_n_d_a_r___c_o_n_f(5) for
       details on the Grid Engine calendar facility.

       NNoottee:: Jobs can request queues with a certain calendar model via  a  "_-_l
       _c_=_<_c_a_l___n_a_m_e_>" option to _q_s_u_b(1).

   iinniittiiaall__ssttaattee
       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 _s_g_e___e_x_e_c_d(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 _s_g_e___e_x_e_c_d(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 '_q_m_o_d _-_e' command (see _q_m_o_d(1)).

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


RREESSOOUURRCCEE LLIIMMIITTSS
       The first two resource limit parameters, ss__rrtt and hh__rrtt, are implemented
       by Grid Engine. They define the "real time" or also called "elapsed" or
       "wall clock" time which has passed since the start of the job. If  hh__rrtt
       is  exceeded  by  a  job  running  in  the queue, it is aborted via the
       SIGKILL signal (see _k_i_l_l(1)).  If ss__rrtt 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  con-
       figuration parameter nnoottiiffyy (see above) has passed.

       The  resource  limit parameters ss__ccppuu and hh__ccppuu are implemented by Grid
       Engine as job limits. They impose a limit on the amount of combined CPU
       time consumed by all the processes in the job.  If hh__ccppuu is exceeded by
       a job running in the queue, it is aborted via  a  SIGKILL  signal  (see
       _k_i_l_l(1)).  If ss__ccppuu 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
       ss__ccppuu limit to a lower value than hh__ccppuu.  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 ss__vvmmeemm and hh__vvmmeemm are 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  hh__vvmmeemm  is
       exceeded  by  a  job  running in the queue, it is aborted via a SIGKILL
       signal (see kill(1)).  If ss__vvmmeemm 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 ss__vvmmeemm limit to a lower value than hh__vvmmeemm.  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 _s_e_t_r_-
       _l_i_m_i_t(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 _s_e_t_r_l_i_m_i_t(2) manual page).  The
       value  type  for the CPU-time limits ss__ccppuu and hh__ccppuu is time. The value
       type for the other limits is memory.  NNoottee::  Not  all  systems  support
       _s_e_t_r_l_i_m_i_t(2).

       NNoottee  aallssoo::  s_vmem  and  h_vmem (virtual memory) are only available on
       systems supporting RLIMIT_VMEM (see _s_e_t_r_l_i_m_i_t(2) on your operating sys-
       tem).

       The  UNICOS  operating system supplied by SGI/Cray does not support the
       _s_e_t_r_l_i_m_i_t(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.


SSEEEE AALLSSOO
       _s_g_e___i_n_t_r_o(1),   _c_s_h(1),   _q_c_o_n_f(1),   _q_m_o_n(1),  _q_r_e_s_t_a_r_t(1),  _q_s_t_a_t(1),
       _q_s_u_b(1),   _s_h(1),   _n_i_c_e(2),   _s_e_t_r_l_i_m_i_t(2),   _a_c_c_e_s_s___l_i_s_t(5),   _c_a_l_e_n_-
       _d_a_r___c_o_n_f(5),   _s_g_e___c_o_n_f(5),  _c_o_m_p_l_e_x(5),  _h_o_s_t___c_o_n_f(5),  _s_c_h_e_d___c_o_n_f(5),
       _s_g_e___e_x_e_c_d(8), _s_g_e___q_m_a_s_t_e_r(8), _s_g_e___s_h_e_p_h_e_r_d(8).

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



GE 6.1                   $Date: 2008/02/22 10:45:35 $            QUEUE_CONF(5)
