GE_CONF(5)                 Grid Engine File Formats                 GE_CONF(5)



NNAAMMEE
       ge_conf - Grid Engine configuration files

DDEESSCCRRIIPPTTIIOONN
       _g_e___c_o_n_f defines the global and local Grid Engine configurations and can
       be shown/modified by _q_c_o_n_f(1) using  the  -sconf/-mconf  options.  Only
       root or the cluster administrator may modify _g_e___c_o_n_f_.

       At  its  initial  start-up, _g_e___q_m_a_s_t_e_r(8) checks to see if a valid Grid
       Engine configuration is available at a well known location in the  Grid
       Engine  internal  directory hierarchy.  If so, it loads that configura-
       tion information and proceeds.  If not, _g_e___q_m_a_s_t_e_r(8) writes a  generic
       configuration  containing  default  values  to that same location.  The
       Grid Engine execution daemons _g_e___e_x_e_c_d(8) upon start-up retrieve  their
       configuration from _g_e___q_m_a_s_t_e_r(8).

       The  actual  configuration  for both _g_e___q_m_a_s_t_e_r(8) and _g_e___e_x_e_c_d(8) is a
       superposition of a _g_l_o_b_a_l configuration and a _l_o_c_a_l configuration  per-
       tinent  for the host on which a master or execution daemon resides.  If
       a local configuration is available, its entries  overwrite  the  corre-
       sponding  entries of the global configuration. NNoottee:: The local configu-
       ration does not have to contain all valid  configuration  entries,  but
       only those which need to be modified against the global entries.

       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.

FFOORRMMAATT
       The paragraphs that follow provide brief descriptions of the individual
       parameters that compose the global and local configurations for a  Grid
       Engine cluster:

   eexxeeccdd__ssppooooll__ddiirr
       The  execution  daemon  spool  directory  path. Again, a feasible spool
       directory requires read/write access permission for root. The entry  in
       the  global configuration for this parameter can be overwritten by exe-
       cution host local configurations, i.e. each _g_e___e_x_e_c_d(8) may have a pri-
       vate  spool  directory with a different path, in which case it needs to
       provide read/write permission for the root account of the corresponding
       execution host only.

       Under  eexxeeccdd__ssppooooll__ddiirr  a directory named corresponding to the unquali-
       fied hostname of the execution host is opened and contains all informa-
       tion  spooled to disk. Thus, it is possible for the eexxeeccdd__ssppooooll__ddiirrs of
       all execution hosts to physically reference  the  same  directory  path
       (the root access restrictions mentioned above need to be met, however).

       Changing the global eexxeeccdd__ssppooooll__ddiirr parameter set at installation  time
       is  not  supported  in  a running system. If the change should still be
       done it is required to restart all affected execution daemons.   Please
       make sure running jobs have finished before doing so, otherwise running
       jobs will be lost.


       The default location  for  the  execution  daemon  spool  directory  is
       $GE_ROOT/$GE_CELL/spool.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

   mmaaiilleerr
       mmaaiilleerr is the absolute pathname to the electronic mail  delivery  agent
       on your system. It must accept the following syntax:

              mailer -s <subject-of-mail-message> <recipient>

       Each  _g_e___e_x_e_c_d(8)  may  use  a private mail agent. Changing mmaaiilleerr will
       take immediate effect.

       The default for mmaaiilleerr depends on the operating system of the  host  on
       which  the  Grid  Engine master installation was run. Common values are
       /bin/mail or /usr/bin/Mail.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

   xxtteerrmm
       xxtteerrmm  is  the absolute pathname to the X Window System terminal emula-
       tor, _x_t_e_r_m(1).

       Each _g_e___e_x_e_c_d(8) may use a private mail agent. Changing xxtteerrmm will take
       immediate effect.

       The default for xxtteerrmm is /usr/bin/X11/xterm.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

   llooaadd__sseennssoorr
       A comma separated list of executable shell script paths or programs  to
       be started by _g_e___e_x_e_c_d(8) and to be used in order to retrieve site con-
       figurable load information (e.g. free space on a  certain  disk  parti-
       tion).

       Each  _g_e___e_x_e_c_d(8)  may  use  a  set  of private llooaadd__sseennssoorr programs or
       scripts. Changing llooaadd__sseennssoorr will take effect after  two  load  report
       intervals (see llooaadd__rreeppoorrtt__ttiimmee)).. AA llooaadd sseennssoorr wwiillll bbee rreessttaarrtteedd aauuttoo--
       mmaattiiccaallllyy iiff tthhee ffiillee mmooddiiffiiccaattiioonn ttiimmee ooff tthhee llooaadd  sseennssoorr  eexxeeccuuttaabbllee
       cchhaannggeess..

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

       In addition to the load sensors configured via llooaadd__sseennssoorr,  _g_e___e_x_e_c(8)
       searches  for  an  executable  file  named _q_l_o_a_d_s_e_n_s_o_r in the execution
       host's Grid Engine binary directory path.  If such a file is found,  it
       is  treated  like the configurable load sensors defined in llooaadd__sseennssoorr.
       This facility is intended for pre-installing a default load sensor.

   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.  Each _g_e___e_x_e_c_d(8) may use a pri-
       vate prolog script.  Correspondingly, the execution host local configu-
       rations   is  can  be  overwritten  by  the  queue  configuration  (see
       _q_u_e_u_e___c_o_n_f(5) ).  Changing pprroolloogg will take immediate effect.

       The default for pprroolloogg is the special value NONE, which  prevents  from
       execution of a prolog script.

       The  following  special  variables  expanded  at  runtime  can  be used
       (besides any other strings which have to be interpreted by  the  proce-
       dure) to constitute a command line:

       _$_h_o_s_t  The  name  of  the host on which the prolog or epilog procedures
              are 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.

       _$_p_r_o_c_e_s_s_o_r_s
              The pprroocceessssoorrss string as contained in  the  queue  configuration
              (see  _q_u_e_u_e___c_o_n_f(5)) of the master queue (the queue in which the
              prolog and epilog procedures are started).

       _$_q_u_e_u_e The cluster queue name of the master queue  instance,  i.e.  the
              cluster  queue  in  which  the  prolog and epilog procedures are
              started.

       _$_s_t_d_i_n___p_a_t_h
              The pathname of the stdin file. This  is  always  /dev/null  for
              prolog,  pe_start, pe_stop and epilog. It is the pathname of the
              stdin file for the job in the job script.  When  delegated  file
              staging is enabled, this path is set to $fs_stdin_tmp_path. When
              delegated file staging is not enabled, it is the stdin  pathname
              given via DRMAA or qsub.

       _$_s_t_d_o_u_t___p_a_t_h

       _$_s_t_d_e_r_r___p_a_t_h
              The  pathname  of  the stdout/stderr file. This always points to
              the output/error file. When delegated file staging  is  enabled,
              this  path  is  set  to $fs_stdout_tmp_path/$fs_stderr_tmp_path.
              When delegated file staging is  not  enabled,  it  is  the  std-
              out/stderr pathname given via DRMAA or qsub.

       _$_m_e_r_g_e___s_t_d_e_r_r
              If  merging of stderr and stdout is requested, this flag is "1",
              otherwise it is "0".  If this flag is 1, stdout and  stderr  are
              merged in one file, the stdout file.  Merging of stderr and std-
              out can be  requested  via  the  DRMAA  job  template  attribute
              'drmaa_join_files' (see _d_r_m_a_a___a_t_t_r_i_b_u_t_e_s(3) ) or the qsub param-
              eter '-j y' (see _q_s_u_b(1) ).

       _$_f_s___s_t_d_i_n___h_o_s_t
              When delegated file staging is requested  for  the  stdin  file,
              this  is  the  name  of  the host where the stdin file has to be
              copied from before the job is started.

       _$_f_s___s_t_d_o_u_t___h_o_s_t

       _$_f_s___s_t_d_e_r_r___h_o_s_t
              When delegated file staging is requested for  the  stdout/stderr
              file,  this is the name of the host where the stdout/stderr file
              has to be copied to after the job has run.

       _$_f_s___s_t_d_i_n___p_a_t_h
              When delegated file staging is requested  for  the  stdin  file,
              this   is   the   pathname   of  the  stdin  file  on  the  host
              $fs_stdin_host.

       _$_f_s___s_t_d_o_u_t___p_a_t_h

       _$_f_s___s_t_d_e_r_r___p_a_t_h
              When delegated file staging is requested for  the  stdout/stderr
              file, this is the pathname of the stdout/stderr file on the host
              $fs_stdout_host/$fs_stderr_host.

       _$_f_s___s_t_d_i_n___t_m_p___p_a_t_h
              When delegated file staging is requested  for  the  stdin  file,
              this is the destination pathname of the stdin file on the execu-
              tion host. The prolog script  must  copy  the  stdin  file  from
              $fs_stdin_host:$fs_stdin_path to localhost:$fs_stdin_tmp_path to
              establish delegated file staging of the stdin file.

       _$_f_s___s_t_d_o_u_t___t_m_p___p_a_t_h

       _$_f_s___s_t_d_e_r_r___t_m_p___p_a_t_h
              When delegated file staging is requested for  the  stdout/stderr
              file,  this  is the source pathname of the stdout/stderr file on
              the execution host. The epilog script must copy the stdout  file
              from  localhost:$fs_stdout_tmp_path  to $fs_stdout_host:$fs_std-
              out_path (the stderr file from localhost:$fs_stderr_tmp_path  to
              $fs_stderr_host:$fs_stderr_path)  to  establish  delegated  file
              staging of the stdout/stderr file.

       _$_f_s___s_t_d_i_n___f_i_l_e___s_t_a_g_i_n_g

       _$_f_s___s_t_d_o_u_t___f_i_l_e___s_t_a_g_i_n_g

       _$_f_s___s_t_d_e_r_r___f_i_l_e___s_t_a_g_i_n_g
              When delegated file staging  is  requested  for  the  stdin/std-
              out/stderr  file, the flag is set to "1", otherwise it is set to
              "0" (see in ddeelleeggaatteedd__ffiillee__ssttaaggiinngg how to enable delegated  file
              staging).

              These three flags correspond to the DRMAA job template attribute
              'drmaa_transfer_files' (see _d_r_m_a_a___a_t_t_r_i_b_u_t_e_s(3) ).

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

       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.  Each _g_e___e_x_e_c_d(8) may use a pri-
       vate epilog script.  Correspondingly, the execution host local configu-
       rations   is  can  be  overwritten  by  the  queue  configuration  (see
       _q_u_e_u_e___c_o_n_f(5) ).  Changing eeppiilloogg will take immediate effect.

       The default for eeppiilloogg is the special value NONE, which  prevents  from
       execution of a epilog script.  The  same  special variables as for pprroo--
       lloogg can be used to constitute a command line.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

       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

   sshheellll__ssttaarrtt__mmooddee
       NNoottee:: Deprecated, may be removed in future release.
       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 significant. The POSIX standard for batch queu-
              ing systems (P1003.2d) therefore requires  a  compliant  queuing
              system to ignore such lines but to use user specified or config-
              ured   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 _q_u_e_u_e___c_o_n_f(5) for details).

       _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
              _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 epilog  and  prolog
              scripts  for  reading  into  STDIN  as  root (if _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
              _q_u_e_u_e___c_o_n_f(5) for details).
              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.

       Changes to sshheellll__ssttaarrtt__mmooddee will take immediate  effect.   The  default
       for sshheellll__ssttaarrtt__mmooddee is _p_o_s_i_x___c_o_m_p_l_i_a_n_t.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   llooggiinn__sshheellllss
       UNIX command interpreters like the Bourne-Shell (see _s_h(1)) or  the  C-
       Shell (see _c_s_h(1)) can be used by Grid Engine to start job scripts. The
       command interpreters can either be started as  login-shells  (i.e.  all
       system  and user default resource files like .login or .profile will be
       executed when the command interpreter is started  and  the  environment
       for  the  job will be set up as if the user has just logged in) or just
       for command execution (i.e. only shell  specific  resource  files  like
       .cshrc  will be executed and a minimal default environment is set up by
       Grid Engine - see _q_s_u_b(1)).   The  parameter  llooggiinn__sshheellllss  contains  a
       comma  separated  list  of  the  executable names of the command inter-
       preters to be started as login-shells.  Shells in this  list  are  only
       started  as  login shells if the parameter sshheellll__ssttaarrtt__mmooddee (see above)
       is set to _p_o_s_i_x___c_o_m_p_l_i_a_n_t.

       Changes to llooggiinn__sshheellllss will take immediate effect.   The  default  for
       llooggiinn__sshheellllss is sh,csh,tcsh,ksh.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   mmiinn__uuiidd
       mmiinn__uuiidd places a lower bound on user IDs  that  may  use  the  cluster.
       Users  whose  user ID (as returned by _g_e_t_p_w_n_a_m(3)) is less than mmiinn__uuiidd
       will not be allowed to run jobs on the cluster.

       Changes to mmiinn__uuiidd will take immediate effect.  The default for mmiinn__uuiidd
       is 0.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   mmiinn__ggiidd
       This parameter sets the lower bound on group IDs that may use the clus-
       ter.  Users whose default group ID (as returned by _g_e_t_p_w_n_a_m(3)) is less
       than mmiinn__ggiidd will not be allowed to run jobs on the cluster.

       Changes to mmiinn__ggiidd will take immediate effect.  The default for mmiinn__ggiidd
       is 0.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   uusseerr__lliissttss
       The uusseerr__lliissttss parameter contains a comma separated list of 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 enlisted access lists has access  to  the  cluster.  If  the
       uusseerr__lliissttss  parameter  is set to NONE (the default) any user has access
       not explicitly excluded via the xxuusseerr__lliissttss parameter described  below.
       If  a  user is contained both in an access list enlisted in xxuusseerr__lliissttss
       and uusseerr__lliissttss the user is denied access to the cluster.

       Changes to uusseerr__lliissttss will take immediate effect

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   xxuusseerr__lliissttss
       The  xxuusseerr__lliissttss  parameter  contains  a  comma  separated list of 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 enlisted access lists is denied access to the cluster.
       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 enlisted in
       xxuusseerr__lliissttss and uusseerr__lliissttss (see above) the user is denied access to the
       cluster.

       Changes to xxuusseerr__lliissttss will take immediate effect

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   aaddmmiinniissttrraattoorr__mmaaiill
       aaddmmiinniissttrraattoorr__mmaaiill specifies a comma separated list of  the  electronic
       mail  address(es)  of  the cluster administrator(s) to whom internally-
       generated problem reports are sent. The mail address format depends  on
       your electronic mail system and how it is configured; consult your sys-
       tem's configuration guide for more information.

       Changing aaddmmiinniissttrraattoorr__mmaaiill takes immediate effect.   The  default  for
       aaddmmiinniissttrraattoorr__mmaaiill is an empty mail list.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   pprroojjeeccttss
       The pprroojjeeccttss list contains all projects which  are  granted  access  to
       Grid  Engine.  User belonging to none of these projects cannot use Grid
       Engine. If users belong to projects in the pprroojjeeccttss list and the  xxpprroo--
       jjeeccttss list (see below), they also cannot use the system.

       Changing  pprroojjeeccttss takes immediate effect.  The default for pprroojjeeccttss is
       none.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   xxpprroojjeeccttss
       The xxpprroojjeeccttss list contains all projects that are denied access to Grid
       Engine. User belonging to one of these projects cannot use Grid Engine.
       If  users  belong  to projects in the pprroojjeeccttss list (see above) and the
       xxpprroojjeeccttss list, they also cannot use the system.

       Changing xxpprroojjeeccttss takes immediate effect.  The default  for  xxpprroojjeeccttss
       is none.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   llooaadd__rreeppoorrtt__ttiimmee
       System load is  reported  periodically  by  the  execution  daemons  to
       _g_e___q_m_a_s_t_e_r(8).   The parameter llooaadd__rreeppoorrtt__ttiimmee defines the time inter-
       val between load reports.

       Each _g_e___e_x_e_c_d(8)  may  use  a  different  load  report  time.  Changing
       llooaadd__rreeppoorrtt__ttiimmee will take immediate effect.

       NNoottee::  Be  careful  when modifying llooaadd__rreeppoorrtt__ttiimmee. Reporting load too
       frequently might block _g_e___q_m_a_s_t_e_r(8) especially if the number of execu-
       tion  hosts  is  large.  Moreover,  since  the  system  load  typically
       increases and decreases smoothly, frequent load  reports  hardly  offer
       any benefit.

       The default for llooaadd__rreeppoorrtt__ttiimmee is 40 seconds.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

   rreesscchheedduullee__uunnkknnoowwnn
       Determines whether jobs on hosts in unknown state are  rescheduled  and
       thus  sent  to  other hosts. Hosts are registered as unknown if _g_e___m_a_s_-
       _t_e_r(8) cannot establish contact to the _g_e___e_x_e_c_d(8) on those hosts  (see
       mmaaxx__uunnhheeaarrdd  ).  Likely reasons are a breakdown of the host or a break-
       down of the network connection in between, but also _g_e___e_x_e_c_d(8) may not
       be executing on such hosts.

       In  any  case, Grid Engine can reschedule jobs running on such hosts to
       another system.  rreesscchheedduullee__uunnkknnoowwnn controls the time which Grid Engine
       will  wait before jobs are rescheduled after a host became unknown. The
       time format specification is hh:mm:ss. If the special value 00:00:00 is
       set, then jobs will not be rescheduled from this host.

       Rescheduling  is only initiated for jobs which have activated the rerun
       flag (see  the  --rr  yy  option  of  _q_s_u_b(1)  and  the  rreerruunn  option  of
       _q_u_e_u_e___c_o_n_f(5)).   Parallel  jobs  are  only  rescheduled if the host on
       which their master task executes is in unknown state. The  behavior  of
       rreesscchheedduullee__uunnkknnoowwnn  for  parallel  jobs  and for jobs without the rerun
       flag  be  set  can  be  adjusted  using  the  qqmmaasstteerr__ppaarraammss   settings
       EENNAABBLLEE__RREESSCCHHEEDDUULLEE__KKIILLLL and EENNAABBLLEE__RREESSCCHHEEDDUULLEE__SSLLAAVVEE..

       Checkpointing jobs will only be rescheduled when the wwhheenn option of the
       corresponding checkpointing environment contains an  appropriate  flag.
       (see  _c_h_e_c_k_p_o_i_n_t(5)).  Interactive jobs (see _q_s_h(1), _q_r_s_h(1), _q_t_c_s_h(1))
       are not rescheduled.

       The default for rreesscchheedduullee__uunnkknnoowwnn is 00:00:00

       The global configuration entry for this value may be  over  written  by
       the execution host local configuration.

   mmaaxx__uunnhheeaarrdd
       If  _g_e___q_m_a_s_t_e_r(8)  could not contact or was not contacted by the execu-
       tion daemon of a host for mmaaxx__uunnhheeaarrdd seconds, all queues  residing  on
       that  particular  host  are  set  to status unknown.  _g_e___q_m_a_s_t_e_r(8), at
       least, should be contacted by the execution daemons in order to get the
       load   reports.   Thus,   mmaaxx__uunnhheeaarrdd   should   by  greater  than  the
       llooaadd__rreeppoorrtt__ttiimmee (see above).

       Changing  mmaaxx__uunnhheeaarrdd  takes  immediate  effect.    The   default   for
       mmaaxx__uunnhheeaarrdd is 5 minutes.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   lloogglleevveell
       This parameter specifies the level of detail that  Grid  Engine  compo-
       nents  such as _g_e___q_m_a_s_t_e_r(8) or _g_e___e_x_e_c_d(8) use to produce informative,
       warning or error messages which are logged to the _m_e_s_s_a_g_e_s files in the
       master  and  execution daemon spool directories (see the description of
       the eexxeeccdd__ssppooooll__ddiirr parameter above). The following message levels  are
       available:

       _l_o_g___e_r_r
              All error events being recognized are logged.

       _l_o_g___w_a_r_n_i_n_g
              All  error  events  being  recognized  and all detected signs of
              potentially erroneous behavior are logged.

       _l_o_g___i_n_f_o
              All error events being recognized, all detected signs of  poten-
              tially  erroneous behavior and a variety of informative messages
              are logged.

       Changing lloogglleevveell will take immediate effect.

       The default for lloogglleevveell is _l_o_g___w_a_r_n_i_n_g.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   mmaaxx__aajj__iinnssttaanncceess
       This parameter defines the maximum amount of array task to be scheduled
       to run simultaneously per array job.  An instance of an array task will
       be created within the master daemon when it gets a start order from the
       scheduler. The instance will be destroyed when the array task finishes.
       Thus  the parameter provides control mainly over the memory consumption
       of array jobs in the master and scheduler daemon. It is most useful for
       very  large  clusters  and very large array jobs.  The default for this
       parameter is 2000. The value 0 will  deactivate  this  limit  and  will
       allow  the  scheduler  to  start  as  many  array job tasks as suitable
       resources are available in the cluster.

       Changing mmaaxx__aajj__iinnssttaanncceess will take immediate effect.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   mmaaxx__aajj__ttaasskkss
       This  parameter defines the maximum number of array job tasks within an
       array job.  _g_e___q_m_a_s_t_e_r(8) will reject all array job  submissions  which
       request  more  than  mmaaxx__aajj__ttaasskkss array job tasks. The default for this
       parameter is 75000. The value 0 will deactivate this limit.

       Changing mmaaxx__aajj__ttaasskkss will take immediate effect.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   mmaaxx__uu__jjoobbss
       The  number  of  active (not finished) jobs which each Grid Engine user
       can have in the system simultaneously is controlled by this  parameter.
       A  value  greater  than  0 defines the limit. The default value 0 means
       "unlimited". If the mmaaxx__uu__jjoobbss limit is exceeded by  a  job  submission
       then  the submission command exits with exit status 25 and an appropri-
       ate error message.

       Changing mmaaxx__uu__jjoobbss will take immediate effect.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   mmaaxx__jjoobbss
       The number of active (not finished) jobs simultaneously allowed in Grid
       Engine is controlled by this parameter. A value greater than 0  defines
       the  limit.   The  default  value  0 means "unlimited". If the mmaaxx__jjoobbss
       limit is exceeded by a job submission then the submission command exits
       with exit status 25 and an appropriate error message.

       Changing mmaaxx__jjoobbss will take immediate effect.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   mmaaxx__aaddvvaannccee__rreesseerrvvaattiioonnss
       The number of active (not finished) Advance Reservations simultaneously
       allowed in Grid Engine is controlled by this parameter. A value greater
       than 0 defines the limit. The default value 0 means "unlimited". If the
       mmaaxx__aaddvvaannccee__rreesseerrvvaattiioonnss  limit  is  exceeded by an Advance Reservation
       request then the submission command exits with exit status  25  and  an
       appropriate error message.

       Changing mmaaxx__aaddvvaannccee__rreesseerrvvaattiioonnss will take immediate effect.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   eennffoorrccee__pprroojjeecctt
       If set to _t_r_u_e,, uusseerrss aarree rreeqquuiirreedd ttoo rreeqquueesstt aa pprroojjeecctt  wwhheenneevveerr  ssuubb--
       mmiittttiinngg aa jjoobb.. SSeeee tthhee --PP ooppttiioonn ttoo _q_s_u_b(1) for details.

       Changing  eennffoorrccee__pprroojjeecctt  will take immediate effect.  The default for
       eennffoorrccee__pprroojjeecctt is _f_a_l_s_e.


       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   eennffoorrccee__uusseerr
       If  set to _t_r_u_e,, aa _u_s_e_r(5) must exist to allow for job submission. Jobs
       are rejected if no corresponding user exists.

       If set to _a_u_t_o,, aa _u_s_e_r(5) object for the submitting user will automati-
       cally  be created during job submission, if one does not already exist.
       The aauuttoo__uusseerr__oottiicckkeett, aauuttoo__uusseerr__ffsshhaarree, aauuttoo__uusseerr__ddeeffaauulltt__pprroojjeecctt, and
       aauuttoo__uusseerr__ddeelleettee__ttiimmee  configuration parameters will be used as default
       attributes of the new _u_s_e_r(5) object.

       Changing eennffoorrccee__uusseerr will take  immediate  effect.   The  default  for
       eennffoorrccee__uusseerr is _a_u_t_o.


       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   aauuttoo__uusseerr__oottiicckkeett
       The number of override  tickets  to  assign  to  automatically  created
       _u_s_e_r(5)   objects.  User  objects  are  created  automatically  if  the
       eennffoorrccee__uusseerr attribute is set to _a_u_t_o.

       Changing aauuttoo__uusseerr__oottiicckkeett will affect any newly created user  objects,
       but will not change user objects created in the past.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   aauuttoo__uusseerr__ffsshhaarree
       The number of functional shares  to  assign  to  automatically  created
       _u_s_e_r(5)   objects.  User  objects  are  created  automatically  if  the
       eennffoorrccee__uusseerr attribute is set to _a_u_t_o.

       Changing aauuttoo__uusseerr__ffsshhaarree will affect any newly created  user  objects,
       but will not change user objects created in the past.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   aauuttoo__uusseerr__ddeeffaauulltt__pprroojjeecctt
       The default project to assign to automatically created _u_s_e_r(5) objects.
       User objects are created automatically if the eennffoorrccee__uusseerr attribute is
       set to _a_u_t_o.

       Changing aauuttoo__uusseerr__ddeeffaauulltt__pprroojjeecctt will affect any newly  created  user
       objects, but will not change user objects created in the past.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   aauuttoo__uusseerr__ddeelleettee__ttiimmee
       The number of seconds of inactivity after which  automatically  created
       _u_s_e_r(5) objects will be deleted. User objects are created automatically
       if the eennffoorrccee__uusseerr attribute is set to _a_u_t_o. If the user has no active
       or pending jobs for the specified amount of time, the object will auto-
       matically be deleted.  A value of 0 can be used to  indicate  that  the
       automatically  created user object is permanent and should not be auto-
       matically deleted.

       Changing aauuttoo__uusseerr__ddeelleettee__ttiimmee will affect the deletion  time  for  all
       users with active jobs.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   sseett__ttookkeenn__ccmmdd
       NNoottee:: Deprecated, may be removed in future release.
       This parameter is only present if your Grid Engine system  is  licensed
       to support AFS.

       SSeett__ttookkeenn__ccmmdd points to a command which sets and extends AFS tokens for
       Grid Engine jobs. In the standard Grid Engine AFS distribution,  it  is
       supplied  as  a  script  which  expects two command line parameters. It
       reads the token from STDIN, extends the  token's  expiration  time  and
       sets the token:

              <set_token_cmd> <user> <token_extend_after_seconds>

       As a shell script this command will call the programs:

              - SetToken
              - forge

       which are provided by your distributor as source code. The script looks
       as follows:

              --------------------------------
              #!/bin/sh
              # set_token_cmd
              forge -u $1 -t $2 | SetToken
              --------------------------------

       Since it is necessary for _f_o_r_g_e to read the secret AFS  server  key,  a
       site might wish to replace the sseett__ttookkeenn__ccmmdd script by a command, which
       connects to a custom daemon at the AFS server. The token must be forged
       at  the AFS server and returned to the local machine, where _S_e_t_T_o_k_e_n is
       executed.

       Changing sseett__ttookkeenn__ccmmdd will take immediate  effect.   The  default  for
       sseett__ttookkeenn__ccmmdd is none.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

   ppaagg__ccmmdd
       NNoottee:: Deprecated, may be removed in future release.
       This parameter is only present if your Grid Engine system  is  licensed
       to support AFS.

       The  path  to your _p_a_g_s_h iiss ssppeecciiffiieedd vviiaa tthhiiss ppaarraammeetteerr..  TThhee _g_e___s_h_e_p_-
       _h_e_r_d(8) process and the job run in a _p_a_g_s_h. Please ask your AFS  admin-
       istrator for details.

       Changing  ppaagg__ccmmdd  will take immediate effect.  The default for ppaagg__ccmmdd
       is none.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

   ttookkeenn__eexxtteenndd__ttiimmee
       NNoottee:: Deprecated, may be removed in future release.
       This  parameter  is only present if your Grid Engine system is licensed
       to support AFS.

       The ttookkeenn__eexxtteenndd__ttiimmee is the time period for which AFS tokens are peri-
       odically extended. Grid Engine will call the token extension 30 minutes
       before the tokens expire until jobs have finished and the corresponding
       tokens are no longer required.

       Changing ttookkeenn__eexxtteenndd__ttiimmee will take immediate effect.  The default for
       ttookkeenn__eexxtteenndd__ttiimmee is 24:0:0, i.e. 24 hours.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

   sshheepphheerrdd__ccmmdd
       Alternative path to the sshheepphheerrdd__ccmmdd binary. Typically used to call the
       shepherd binary by a wrapper script or command.

       Changing sshheepphheerrdd__ccmmdd will take immediate effect. The default for sshheepp--
       hheerrdd__ccmmdd is none.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

   ggiidd__rraannggee
       The ggiidd__rraannggee is a comma separated list of  range  expressions  of  the
       form  n-m (n as well as m are integer numbers greater than 99), where m
       is an abbreviation for m-m. These numbers are used  in  _g_e___e_x_e_c_d(8)  to
       identify processes belonging to the same job.

       Each  _g_e___e_x_e_c_d(8) may use a separate set up group ids for this purpose.
       All number in the group id range have to be unused supplementary  group
       ids on the system, where the _g_e___e_x_e_c_d(8) is started.

       Changing ggiidd__rraannggee will take immediate effect.  There is no default for
       ggiidd__rraannggee. The administrator will have to assign a value for  ggiidd__rraannggee
       during installation of Grid Engine.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

   qqmmaasstteerr__ppaarraammss
       A list of additional parameters can be passed to the Grid Engine  qmas-
       ter. The following values are recognized:

       _E_N_A_B_L_E___E_N_F_O_R_C_E___M_A_S_T_E_R___L_I_M_I_T
              If  this parameter is set then the ss__rrtt, hh__rrtt limit of a running
              job are tested  and  executed  by  the  _g_e___q_m_a_s_t_e_r(8)  when  the
              _g_e___e_x_e_c_d(8) where the job is in unknown state.

              After  ss__rrtt  oorr  hh__rrtt  lliimmiitt ooff aa jjoobb iiss eexxppiirreedd tthheenn tthhee mmaasstteerr
              ddaaeemmoonn wwiillll wwaaiitt aaddddiittiioonnaall ttiimmee ddeeffiinneedd bbyy DDUURRAATTIIOONN__OOFFFFSSEETT ((sseeee
              _s_c_h_e_d___c_o_n_f(5)).   If  the  execution daemon still cannot be con-
              tacted when this additional time is  elapsed,  then  the  master
              daemon will force the deletion of the job (see --ff of _q_d_e_l(1)).

              For  jobs  which  will  be deleted that way an accounting record
              will be created.  As usage the  record  will  contain  the  last
              reported  online  usage, when the execution daemon could contact
              qmaster. The ffaaiilleedd state in the record will be  set  to  37  to
              indicate  that  the job was terminated by a limit enforcement of
              master daemon.

              After the restart of _g_e___q_m_a_s_t_e_r(8) the limit enforcement will at
              first   be   triggered   after   the   double   of  the  biggest
              llooaadd__rreeppoorrtt__iinntteerrvvaall interval defined in  _s_g_e___c_o_n_f(5)  has  been
              elapsed.  This  will  give  the execution daemons enough time to
              reregister at master daemon.

       _E_N_A_B_L_E___F_O_R_C_E_D___Q_D_E_L___I_F___U_N_K_N_O_W_N
              If this parameter is set then a deletion request for  a  job  is
              automatically  interpreted  as a forced deletion request (see --ff
              of _q_d_e_l(1)) if the host, where the job is running is in  unknown
              state.

       _E_N_A_B_L_E___F_O_R_C_E_D___Q_D_E_L
              If  this  parameter  is  set, non-administrative users can force
              deletion of their own jobs via the _-_f option of _q_d_e_l(1).   With-
              out  this  parameter, forced deletion of jobs is only allowed by
              the Grid Engine manager or operator.

              NNoottee:: Forced deletion for jobs is executed differently depending
              on  whether users are Grid Engine administrators or not. In case
              of administrative users, the jobs are removed from the  internal
              database  of  Grid  Engine  immediately.  For regular users, the
              equivalent of a normal _q_d_e_l(1) is executed first,  and  deletion
              is forced only if the normal cancellation was unsuccessful.

       _F_O_R_B_I_D___R_E_S_C_H_E_D_U_L_E
              If this parameter is set, re-queuing of jobs cannot be initiated
              by the job script which is under control of  the  user.  Without
              this parameter jobs returning the value 99 are rescheduled. This
              can be used to cause the job to  be  restarted  at  a  different
              machine,  for  instance if there are not enough resources on the
              current one.


       _F_O_R_B_I_D___A_P_P_E_R_R_O_R
              If this parameter is set, the application cannot set  itself  to
              error  state.   Without  this parameter jobs returning the value
              100 are set to  error  state  (and  therefore  can  be  manually
              rescheduled  by  clearing the error state).  This can be used to
              set the job to error state when  a  starting  condition  of  the
              application  is  not fulfilled before the application itself has
              been started, or when a clean up procedure (e.g. in the  epilog)
              decides  that it is necessary to run the job again, by returning
              100 in the prolog,  pe_start,  job  script,  pe_stop  or  epilog
              script.


       _D_I_S_A_B_L_E___A_U_T_O___R_E_S_C_H_E_D_U_L_I_N_G
              NNoottee:: Deprecated, may be removed in future release.
              If set to "true" or "1", the _r_e_s_c_h_e_d_u_l_e___u_n_k_n_o_w_n parameter is not
              taken into account.


       _E_N_A_B_L_E___R_E_S_C_H_E_D_U_L_E___K_I_L_L
              If set  to  "true"  or  "1",  the  _r_e_s_c_h_e_d_u_l_e___u_n_k_n_o_w_n  parameter
              affects  also  jobs which have the rerun flag not activated (see
              the  --rr  yy  option  of  _q_s_u_b(1)  and   the   rreerruunn   option   of
              _q_u_e_u_e___c_o_n_f(5)),  but  they  are  just  finished as they can't be
              rescheduled.


       _E_N_A_B_L_E___R_E_S_C_H_E_D_U_L_E___S_L_A_V_E
              If set to "true" or "1" Grid Engine  triggers  job  rescheduling
              also  when the host where the slave tasks of a parallel job exe-
              cutes is in unknown state, if the  _r_e_s_c_h_e_d_u_l_e___u_n_k_n_o_w_n  parameter
              is activated.


       _M_A_X___D_Y_N___E_C
              Sets  the  max  number of dynamic event clients (as used by qsub
              -sync y and by Grid Engine  DRMAA  API  library  sessions).  The
              default  is  set  to  99.   The  number of dynamic event clients
              should not be bigger than half of the number of file descriptors
              the  system has. The number of file descriptors are shared among
              the connections to all exec hosts, all event clients,  and  file
              handles that the qmaster needs.


       _M_O_N_I_T_O_R___T_I_M_E
              Specifies  the  time  interval  when  the monitoring information
              should be printed. The monitoring is disabled by default and can
              be  enabled  by  specifying  an interval.  The monitoring is per
              thread and is written to the messages file or displayed  by  the
              "qping  -f" command line tool. Example: MONITOR_TIME=0:0:10 gen-
              erates and prints the monitoring information approximately every
              10  seconds.  The  specified  time is a guideline only and not a
              fixed interval. The interval that is actually used  is  printed.
              In  this  example, the interval could be anything between 9 sec-
              onds and 20 seconds.


       _L_O_G___M_O_N_I_T_O_R___M_E_S_S_A_G_E
              Monitoring information is logged  into  the  messages  files  by
              default.  This  information can be accessed via by _q_p_i_n_g(1).  If
              monitoring is always enabled,  the  messages  files  can  become
              quite  large.   This  switch  disables logging into the messages
              files, making _q_p_i_n_g _-_f the only source of monitoring data.


       _P_R_O_F___S_I_G_N_A_L
              Profiling provides the user with the possibility to  get  system
              measurements.   This can be useful for debugging or optimization
              of the system. The profiling output will be done within the mes-
              sages file.

              Enables   the   profiling  for  qmaster  signal  thread.   (e.g.
              PROF_SIGNAL=true)


       _P_R_O_F___W_O_R_K_E_R
              Enables  the  profiling  for  qmaster  worker  threads.    (e.g.
              PROF_WORKER=true)


       _P_R_O_F___L_I_S_T_E_N_E_R
              Enables  the  profiling  for  qmaster  listener  threads.  (e.g.
              PROF_LISTENER=true)


       _P_R_O_F___D_E_L_I_V_E_R
              Enables the profiling for qmaster event deliver  thread.   (e.g.
              PROF_DELIVER=true)


       _P_R_O_F___T_E_V_E_N_T
              Enables  the  profiling  for  qmaster timed event thread.  (e.g.
              PROF_TEVENT=true)

       Please note, that the cpu utime and stime values contained in the  pro-
       filing output are not per thread cpu times.  These cpu usage statistics
       are per process statistics.  So the printed profiling  values  for  cpu
       mean "cpu time consumed by sge_qmaster (all threads) while the reported
       profiling level was active".

       _S_T_R_E_E___S_P_O_O_L___I_N_T_E_R_V_A_L
              Sets the time interval for spooling  the  sharetree  usage.  The
              default  is set to 00:04:00. The setting accepts colon-separated
              string or seconds. There is no setting  to  turn  the  sharetree
              spooling off.  (e.g. STREE_SPOOL_INTERVAL=00:02:00)


       _M_A_X___J_O_B___D_E_L_E_T_I_O_N___T_I_M_E
              Sets the value of how long the qmaster will spend deleting jobs.
              After this time, the qmaster will continue with other tasks  and
              schedule  the  deletion  of  remaining jobs at a later time. The
              default value is 3 seconds, and will be  used  if  no  value  is
              entered.  The  range  of  valid  values  is > 0 and <= 5.  (e.g.
              MAX_JOB_DELETION_TIME=1)


       _g_d_i___t_i_m_e_o_u_t
              Sets how long the communication will wait for  gdi  send/receive
              operations.   The default value is set to 60 seconds. After this
              time, the communication library will retry, if "gdi_retries"  is
              configured, receiving the gdi request. In case of not configured
              "gdi_retries" the communication will return with a "gdi  receive
              failure"  (e.g. gdi_timeout=120 will set the timeout time to 120
              sec) Configuring no gdi_timeout value, the value defaults to  60
              sec.


       _g_d_i___r_e_t_r_i_e_s
              Sets  how  often the gdi receive call will be repeated until the
              gdi receive error appears. The default is set to 0. In this case
              the  call  will be done 1 time with no retry.  Setting the value
              to -1 the call will be done  permanently.  In  combination  with
              gdi_timeout  parameter it is possible to configure a system with
              eg. slow NFS, to make sure that  all  jobs  will  be  submitted.
              (e.g. gdi_retries=4)


       _c_l___p_i_n_g
              Turns  on/off  a communication library ping. This parameter will
              create additional debug output.  This output  shows  information
              about the error messages which are returned by communication and
              it will give information about the  application  status  of  the
              qmaster. eg, if it's unclear what's the reason for gdi timeouts,
              this may show you some useful messages.  The  default  value  is
              false (off) (e.g cl_ping=false)


       _S_C_H_E_D_U_L_E_R___T_I_M_E_O_U_T
              Setting  this  parameter allows the scheduler GDI event acknowl-
              edge timeout to be manually configured to a specific value. Cur-
              rently  the  default  value  is  set  to  10 minutes. The _S_C_H_E_D_-
              _U_L_E_R___T_I_M_E_O_U_T value is specified in seconds.

       Changing qqmmaasstteerr__ppaarraammss will take immediate effect, except gdi_timeout,
       gdi_retries,  cl_ping, these will take effect only for new connections.
       The default for qqmmaasstteerr__ppaarraammss is none.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   eexxeeccdd__ppaarraammss
       This  is used for passing additional parameters to the Grid Engine exe-
       cution daemon. The following values are recognized:

       _A_C_C_T___R_E_S_E_R_V_E_D___U_S_A_G_E
              If this parameter  is  set  to  true,  the   usage  of  reserved
              resources  is  used  for  the accounting entries ccppuu, mmeemm and iioo
              instead of the measured usage.


       _E_N_A_B_L_E___W_I_N_D_O_M_A_C_C
              If this parameter is set to true, Windows Domain accounts  (Win-
              DomAcc)  are  used  on Windows hosts. These accounts require the
              use of _s_g_e_p_a_s_s_w_d(1) (see also _s_g_e_p_a_s_s_w_d(5)).  If this  parameter
              is  set to false or is not set, local Windows accounts are used.
              On non-Windows hosts, this parameter is ignored.


       _K_E_E_P___A_C_T_I_V_E
              This value should only be set for debugging purposes. If set  to
              true,  the  execution daemon will not remove the spool directory
              maintained by _g_e___s_h_e_p_h_e_r_d(8) for a job.


       _P_T_F___M_I_N___P_R_I_O_R_I_T_Y, _P_T_F___M_A_X___P_R_I_O_R_I_T_Y
              The maximum/minimum priority which Grid Engine will assign to  a
              job.   Typically  this is a negative/positive value in the range
              of -20 (maximum) to 19 (minimum) for systems which allow setting
              of  priorities  with  the _n_i_c_e(2) system call. Other systems may
              provide different ranges.
              The default priority range (varies from  system  to  system)  is
              installed  either  by  removing  the  parameters or by setting a
              value of -999.
              See the "messages" file of the execution daemon for  the  prede-
              fined  default value on your hosts. The values are logged during
              the startup of the execution daemon.


       _P_R_O_F___E_X_E_C_D
              Enables  the  profiling  for  the   execution   daemon.    (e.g.
              PROF_EXECD=true)


       _N_O_T_I_F_Y___K_I_L_L
              The  parameter  allows you to change the notification signal for
              the signal SIGKILL (see _-_n_o_t_i_f_y option of _q_s_u_b(1)).  The parame-
              ter  either  accepts signal names (use the _-_l option of _k_i_l_l(1))
              or the special value _n_o_n_e. If set to _n_o_n_e, no notification  sig-
              nal will be sent. If it is set to _T_E_R_M, for instance, or another
              signal name then this signal will be sent as  notification  sig-
              nal.


       _N_O_T_I_F_Y___S_U_S_P
              With  this  parameter  it is possible to modify the notification
              signal  for  the  signal  SIGSTOP  (see  _-_n_o_t_i_f_y  parameter   of
              _q_s_u_b(1)).  The parameter either accepts signal names (use the _-_l
              option of _k_i_l_l(1)) or the special value _n_o_n_e. If set to _n_o_n_e, no
              notification  signal  will  be  sent.  If it is set to _T_S_T_P, for
              instance, or another signal name then this signal will  be  sent
              as notification signal.


       _S_H_A_R_E_T_R_E_E___R_E_S_E_R_V_E_D___U_S_A_G_E
              NNoottee:: Deprecated, may be removed in future release.
              If  this  parameter  is  set  to  true,  the  usage  of reserved
              resources is taken for the Grid Engine  share  tree  consumption
              instead of measured usage.


       _U_S_E___Q_S_U_B___G_I_D
              If  this  parameter is set to true, the primary group id  active
              when a job was submitted will be set to become the primary group
              id  for  job execution. If the parameter is not set, the primary
              group id as defined for the job  owner  in  the  execution  host
              _p_a_s_s_w_d(5) file is used.
              The  feature  is  only available for jobs submitted via _q_s_u_b(1),
              _q_r_s_h(1), _q_m_a_k_e(1) and _q_t_c_s_h(1).  Also, it only works for _q_r_s_h(1)
              jobs  (and  thus also for _q_t_c_s_h(1) and _q_m_a_k_e(1)) if rsh and rshd
              components are used which are provided with Grid  Engine  (i.e.,
              the  rrsshh__ddaaeemmoonn  and  rrsshh__ccoommmmaanndd  parameters may not be changed
              from the default).


       _S___D_E_S_C_R_I_P_T_O_R_S, _H___D_E_S_C_R_I_P_T_O_R_S, _S___M_A_X_P_R_O_C, _H___M_A_X_P_R_O_C,

       _S___M_E_M_O_R_Y_L_O_C_K_E_D, _H___M_E_M_O_R_Y_L_O_C_K_E_D, _S___L_O_C_K_S, _H___L_O_C_K_S
              Specifies 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. These parameters complete the list of lim-
              its set by the RESOURCE LIMITS parameter of the queue configura-
              tion as described in _q_u_e_u_e___c_o_n_f(5).  Unlike the resource  limits
              in  the  queue  configuration, these resource limits are set for
              every job on this execution host. If a value is  not  specified,
              the  resource  limit  is  inherited  from  the  execution daemon
              process. Because this would lead to unpredicted results, if only
              one limit of a resource is set (soft or hard), the corresponding
              other limit is set to the same value.
              _S___D_E_S_C_R_I_P_T_O_R_S and _H___D_E_S_C_R_I_P_T_O_R_S specify a value one greater than
              the  maximum  file  descriptor  number that can be opened by any
              process of a job.
              _S___M_A_X_P_R_O_C and _H___M_A_X_P_R_O_C specify the maximum number of  processes
              that can be created by the job user on this execution host
              _S___M_E_M_O_R_Y_L_O_C_K_E_D  and _H___M_E_M_O_R_Y_L_O_C_K_E_D specify the maximum number of
              bytes of virtual memory that may be locked into RAM.
              _S___L_O_C_K_S and _H___L_O_C_K_S specify the maximum number of file locks any
              process of a job may establish.
              All  of  these values can be specified using the multiplier let-
              ters k, K, m, M, g and G, see _s_g_e___t_y_p_e_s(1) for details.

       _I_N_H_E_R_I_T___E_N_V
              This parameter indicates whether the shepherd should  allow  the
              environment  inherited  by  the  execution daemon from the shell
              that started it to be inherited by the job it's starting.   When
              true,  any  environment  variable that is set in the shell which
              starts the execution daemon at the time the execution daemon  is
              started  will  be set in the environment of any jobs run by that
              execution daemon, unless the environment variable is  explicitly
              overridden,  such as PATH or LOGNAME.  If set to false, each job
              starts with only the environment variables that  are  explicitly
              passed  on  by  the  execution daemon, such as PATH and LOGNAME.
              The default value is true.


       _S_E_T___L_I_B___P_A_T_H
              This parameter tells the execution daemon  whether  to  add  the
              Grid Engine shared library directory to the library path of exe-
              cuted jobs.  If set to true, and  INHERIT_ENV  is  also  set  to
              true, the Grid Engine shared library directory will be prepended
              to the library path which is  inherited  from  the  shell  which
              started  the  execution daemon.  If INHERIT_ENV is set to false,
              the library path  will  contain  only  the  Grid  Engine  shared
              library  directory.   If set to false, and INHERIT_ENV is set to
              true, the library path exported to  the  job  will  be  the  one
              inherited from the shell which started the execution daemon.  If
              INHERIT_ENV is also set to  false,  the  library  path  will  be
              empty.   After the execution daemon has set the library path, it
              may be further altered by the shell in which  the  job  is  exe-
              cuted,  or  by  the  job  script  itself.  The default value for
              SET_LIB_PATH is false.


       _E_N_A_B_L_E___A_D_D_G_R_P___K_I_L_L
              If this parameter is set then Grid Engine uses the supplementary
              group ids (see _g_i_d___r_a_n_g_e) to identify all processes which are to
              be terminated when a job  is  deleted,  or  when  _g_e___s_h_e_p_h_e_r_d(8)
              cleans up after job termination.


       _P_D_C___I_N_T_E_R_V_A_L
              This  parameter defines the interval how often the PDC (Portable
              Data Collector) is executed by the execution daemon. The PDC  is
              responsible  for  enforcing  the  resource  limits s_cpu, h_cpu,
              s_vmem and h_vmem (see _q_u_e_u_e___c_o_n_f(5)) and job usage  collection.
              The  parameter can be set to a time_specifier (see _s_g_e___t_y_p_e_s(5))
              , to PPEERR__LLOOAADD__RREEPPOORRTT or to NNEEVVEERR.
              If this parameter is set to PPEERR__LLOOAADD__RREEPPOORRTT the PDC is triggered
              in  the  same  interval as llooaadd__rreeppoorrtt__ttiimmee (see above). If this
              parameter is set to NNEEVVEERR the PDC run is  never  triggered.  The
              default is 1 second.
              NNoottee::  A PDC run is quite compute extensive may degrade the per-
              formance of the running jobs. But if the PDC runs less often  or
              never the online usage can be incomplete or totally missing (for
              example online usage of very short running jobs might  be  miss-
              ing)  and  the  resource  limit  enforcement is less accurate or
              would not happen if PDC is turned of completely.

       Changing eexxeeccdd__ppaarraammss will take effect after it was propagated  to  the
       execution daemons. The propagation is done in one load report interval.
       The default for eexxeeccdd__ppaarraammss is none.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

   rreeppoorrttiinngg__ppaarraammss
       Used  to  define  the  behavior of reporting modules in the Grid Engine
       qmaster. Changes to the rreeppoorrttiinngg__ppaarraammss takes immediate  effect.   The
       following values are recognized:

       _a_c_c_o_u_n_t_i_n_g
              If  this  parameter is set to true, the accounting file is writ-
              ten.  The accounting file is prerequisite for  using  the  qqaacccctt
              command.


       _r_e_p_o_r_t_i_n_g
              If this parameter is set to true, the reporting file is written.
              The reporting file contains data that can be used for monitoring
              and  analysis,  like job accounting, job log, host load and con-
              sumables, queue status and consumables and sharetree  configura-
              tion  and  usage.   Attention: Depending on the size and load of
              the cluster, the reporting file can  become  quite  large.  Only
              activate  the  reporting file if you have a process running that
              will consume the reporting file!  See _r_e_p_o_r_t_i_n_g(5)  for  further
              information about format and contents of the reporting file.


       _f_l_u_s_h___t_i_m_e
              Contents  of  the reporting file are buffered in the Grid Engine
              qmaster and flushed at a fixed interval.  This interval  can  be
              configured  with the _f_l_u_s_h___t_i_m_e parameter.  It is specified as a
              time value in the format HH:MM:SS.  Sensible values range from a
              few  seconds to one minute. Setting it too low may slow down the
              qmaster. Setting it too high will make the qmaster consume large
              amounts of memory for buffering data.


       _a_c_c_o_u_n_t_i_n_g___f_l_u_s_h___t_i_m_e
              Contents  of the accounting file are buffered in the Grid Engine
              qmaster and flushed at a fixed interval.  This interval  can  be
              configured  with  the  _a_c_c_o_u_n_t_i_n_g___f_l_u_s_h___t_i_m_e  parameter.   It is
              specified as a time value in the format HH:MM:SS.  Sensible val-
              ues  range  from a few seconds to one minute. Setting it too low
              may slow down the qmaster. Setting it too  high  will  make  the
              qmaster  consume  large  amounts  of  memory for buffering data.
              Setting it to 00:00:00 will disable accounting  data  buffering;
              as soon as data is generated, it will be written to the account-
              ing file.  If this parameter is not  set,  the  accounting  data
              flush  interval  will  default  to  the  value of the _f_l_u_s_h___t_i_m_e
              parameter.


       _j_o_b_l_o_g If this parameter is set to true, the reporting file  will  con-
              tain job logging information. See _r_e_p_o_r_t_i_n_g(5) for more informa-
              tion about job logging.


       _s_h_a_r_e_l_o_g
              The Grid Engine qmaster can  dump  information  about  sharetree
              configuration  and  use  to  the  reporting file.  The parameter
              _s_h_a_r_e_l_o_g sets an interval in which sharetree information will be
              dumped.   It  is set in the format HH:MM:SS. A value of 00:00:00
              configures qmaster not to dump sharetree information.  Intervals
              of  several  minutes  up  to  hours are sensible values for this
              parameter.   See  _r_e_p_o_r_t_i_n_g(5)  for  further  information  about
              sharelog.


       _l_o_g___c_o_n_s_u_m_a_b_l_e_s
              This  parameter  controls writing of consumable resources to the
              reporting file.  When set to (lloogg__ccoonnssuummaabblleess==ttrruuee))  iinnffoorrmmaattiioonn
              aabboouutt  aallll  ccoonnssuummaabbllee  rreessoouurrcceess ((tthheeiirr ccuurrrreenntt uussaaggee aanndd tthheeiirr
              ccaappaacciittyy)) wwiillll bbee wwrriitttteenn ttoo tthhee rreeppoorrttiinngg ffiillee,, wwhheenneevveerr aa ccoonn--
              ssuummaabbllee  rreessoouurrccee  cchhaannggeess eeiitthheerr iinn ddeeffiinniittiioonn,, oorr iinn ccaappaacciittyy,,
              oorr wwhheenn tthhee  uussaaggee  ooff  aa  ccoonnssuummaabbllee  rreessoouurrccee  cchhaannggeess..   WWhheenn
              lloogg__ccoonnssuummaabblleess  iiss sseett ttoo ffaallssee ((ddeeffaauulltt)),, oonnllyy tthhoossee vvaarriiaabblleess
              wwiillll bbee wwrriitttteenn ttoo tthhee rreeppoorrttiinngg ffiillee,, tthhaatt  aarree  ccoonnffiigguurreedd  iinn
              tthhee   rreeppoorrtt__vvaarriiaabblleess  iinn  tthhee  eexxeecc  hhoosstt  ccoonnffiigguurraattiioonn,,  sseeee
              _h_o_s_t___c_o_n_f(5) for further information about rreeppoorrtt__vvaarriiaabblleess..


   ffiinniisshheedd__jjoobbss
       NNoottee:: Deprecated, may be removed in future release.
       Grid Engine stores a certain number of _j_u_s_t _f_i_n_i_s_h_e_d  jobs  to  provide
       post mortem status information. The ffiinniisshheedd__jjoobbss parameter defines the
       number of finished jobs stored. If this maximum number is reached,  the
       eldest  finished  job  will be discarded for every new job added to the
       finished job list.

       Changing ffiinniisshheedd__jjoobbss will take immediate  effect.   The  default  for
       ffiinniisshheedd__jjoobbss is 100.

       This value is a global configuration parameter only. It cannot be over-
       written by the execution host local configuration.

   qqllooggiinn__ddaaeemmoonn
       This parameter specifies the mechanism that is to  be  started  on  the
       server  side of a _q_l_o_g_i_n(1) request. Usually this is the builtin mecha-
       nism. It's also possible to configure an external executable by  speci-
       fying  the full qualified pathname, e.g. of the system's telnet daemon.

       Changing qqllooggiinn__ddaaeemmoonn will take immediate effect.  The  default  value
       for qqllooggiinn__ddaaeemmoonn is builtin.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

       Examples for the two allowed kinds of attributes are:
       qlogin_daemon    builtin
       or
       qlogin_daemon    /usr/sbin/in.telnetd

   qqllooggiinn__ccoommmmaanndd
       This is the command to be executed on the client side  of  a  _q_l_o_g_i_n(1)
       request.  Usually this is the builtin qlogin mechanism.  It's also pos-
       sible to configure an external mechanism, usually the absolute pathname
       of the system's telnet client program. It is automatically started with
       the target host and port number as parameters.

       Changing qqllooggiinn__ccoommmmaanndd will take immediate effect.  The default  value
       for qqllooggiinn__ccoommmmaanndd is builtin.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

       Examples for the two allowed kinds of attributes are:
       qlogin_command   builtin
       or
       qlogin_command   /usr/bin/telnetd

   rrllooggiinn__ddaaeemmoonn
       This parameter specifies the mechanism that is to  be  started  on  the
       server  side of a _q_r_s_h(1) request wwiitthhoouutt a command argument to be exe-
       cuted remotely.  Usually this is the builtin mechanism. It's also  pos-
       sible  to  configure  an external executable by specifying the absolute
       pathname, e.g. of the system's rlogin daemon.

       Changing rrllooggiinn__ddaaeemmoonn will take  immediate  effect.  The  default  for
       rrllooggiinn__ddaaeemmoonn is builtin.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

       The allowed values are similar to the ones  of  the  examples  of  qqlloo--
       ggiinn__ddaaeemmoonn..

   rrllooggiinn__ccoommmmaanndd
       This  is  the  mechanism to be executed on the client side of a _q_r_s_h(1)
       request wwiitthhoouutt a command argument to be  executed  remotely.   Usually
       this is the builtin mechanism. If no value is given, a specialized Grid
       Engine component is used.  The command is  automatically  started  with
       the  target host and port number as parameters.  The Grid Engine rlogin
       client has been extended to accept and use the  port  number  argument.
       You  can only use clients, such as _s_s_h, which also understand this syn-
       tax.

       Changing rrllooggiinn__ccoommmmaanndd will take immediate effect. The  default  value
       for rrllooggiinn__ccoommmmaanndd is builtin.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

       In addition to the examples of qqllooggiinn__ccoommmmaanndd , this value is allowed:
       rsh_daemon      none

   rrsshh__ddaaeemmoonn
       This parameter specifies the mechanism that is to  be  started  on  the
       server side of a _q_r_s_h(1) request wwiitthh a command argument to be executed
       remotely.  Usually this is the builtin mechanism. If no value is given,
       a specialized Grid Engine component is used.

       Changing  rrsshh__ddaaeemmoonn  will take immediate effect. The default value for
       rrsshh__ddaaeemmoonn is builtin.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

       In addition to the examples of qqllooggiinn__ddaaeemmoonn , this value is allowed:
       rsh_daemon      none

   rrsshh__ccoommmmaanndd
       This  is  the  mechanism to be executed on the client side of a _q_r_s_h(1)
       request wwiitthh a command argument to be executed remotely.  Usually  this
       is  the  builtin  mechanism.   If no value is given, a specialized Grid
       Engine component is used. The command is automatically started with the
       target  host  and port number as parameters like required for _t_e_l_n_e_t(1)
       plus the command with its arguments to be executed remotely.  The  Grid
       Engine  rsh  client has been extended to accept and use the port number
       argument. You can only use clients, such as _s_s_h, which also  understand
       this syntax.

       Changing  rrsshh__ccoommmmaanndd will take immediate effect. The default value for
       rrsshh__ccoommmmaanndd is builtin.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

       In addition to the examples of qqllooggiinn__ccoommmmaanndd , this value is allowed:
       rsh_command     none

   ddeelleeggaatteedd__ffiillee__ssttaaggiinngg
       This  flag  must  be set to "true" when the prolog and epilog are ready
       for delegated file staging, so that the DRMAA  attribute  'drmaa_trans-
       fer_files'  is  supported. To establish delegated file staging, use the
       variables beginning with "$fs_..." in prolog and  epilog  to  move  the
       input,  output  and  error files from one host to the other.  When this
       flag is set to "false", no file staging  is  available  for  the  DRMAA
       interface.  File  staging  is  currently implemented only via the DRMAA
       interface.  When an error occurs while moving  the  input,  output  and
       error files, return error code 100 so that the error handling mechanism
       can handle the error correctly. (See also FORBID_APPERROR).

   rreepprriioorriittiizzee
       NNoottee:: Deprecated, may be removed in future release.
       This flag enables or disables the reprioritization  of  jobs  based  on
       their  ticket  amount. The rreepprriioorriittiizzee__iinntteerrvvaall in _s_c_h_e_d___c_o_n_f(5) takes
       effect only if rreepprriioorriittiizzee is set to true. To turn off job reprioriti-
       zation,  the  rreepprriioorriittiizzee  flag must be set to false and the rreepprriioorrii--
       ttiizzee__iinntteerrvvaall to 0 which is the default.

       This value is a global configuration parameter only. It cannot be over-
       ridden by the execution host local configuration.

   jjssvv__uurrll
       This  setting  defines  a server JSV instance which will be started and
       triggered by the _s_g_e___q_m_a_s_t_e_r(8) process. This JSV instance will be used
       to  verify  job  specifications  of  jobs  before they are accepted and
       stored in the internal master database.  The global configuration entry
       for this value cannot be overwritten by execution host local configura-
       tions.

       Find more details concerning JSV in _j_s_v(1) and _s_g_e___r_e_q_u_e_s_t(1).

       The syntax of the jjssvv__uurrll is specified in _s_g_e___t_y_p_e_s(1).

   jjssvv__aalllloowweedd__mmoodd
       If there is a server JSV script defined with  jjssvv__uurrll  parameter,  then
       all _q_a_l_t_e_r(1) or _q_m_o_n(1) modification requests for jobs are rejected by
       qmaster. With the jjssvv__aalllloowweedd__mmoodd parameter an  administrator  has  the
       possibility  to  allow  a  set  of switches which can then be used with
       clients to modify certain job attributes. The value for this  parameter
       has to be a comma separated list of JSV job parameter names as they are
       documented in _q_s_u_b(1) or the value nnoonnee to indicate that  no  modifica-
       tion should be allowed.

   lliibbjjvvmm__ppaatthh
       lliibbjjvvmm__ppaatthh  is  usually  set during qmaster installation and points to
       the absolute path of libjvm.so.  (or the corresponding library  depend-
       ing  on  your  architecture  -  e.g. /usr/java/jre/lib/i386/server/lib-
       jvm.so) The referenced libjvm version must be  at  least  1.5.   It  is
       needed  by the jvm qmaster thread only. If the java vm needs additional
       starting parameters they can be set in aaddddiittiioonnaall__jjvvmm__aarrggss. If the  jvm
       thread  is  started  at all can be defined in the _b_o_o_t_s_t_r_a_p(5) file. If
       libjvm_path is empty or an incorrect  path  the  jvm  thread  fails  to
       start.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

   aaddddiittiioonnaall__jjvvmm__aarrggss
       aaddddiittiioonnaall__jjvvmm__aarrggss  is  usually  set  during   qmaster   installation.
       Details  about  possible values aaddddiittiioonnaall__jjvvmm__aarrggss can be found in the
       help output of the accompanying java command. This setting is  normally
       not needed.

       The global configuration entry for this value may be overwritten by the
       execution host local configuration.

SSEEEE AALLSSOO
       _g_e___i_n_t_r_o(1), _c_s_h(1), _q_c_o_n_f(1), _q_s_u_b(1), _j_s_v(1), _r_s_h(1),  _s_h(1),  _g_e_t_p_w_-
       _n_a_m(3),      _d_r_m_a_a___a_t_t_r_i_b_u_t_e_s(3),     _q_u_e_u_e___c_o_n_f(5),     _s_c_h_e_d___c_o_n_f(5),
       _s_g_e___t_y_p_e_s(1), _g_e___e_x_e_c_d(8), _g_e___q_m_a_s_t_e_r(8), _g_e___s_h_e_p_h_e_r_d(8), _c_r_o_n(8), _G_r_i_d
       _E_n_g_i_n_e _I_n_s_t_a_l_l_a_t_i_o_n _a_n_d _A_d_m_i_n_i_s_t_r_a_t_i_o_n _G_u_i_d_e_.

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



GE 6.2u2                 $Date: 2008/12/23 16:56:46 $               GE_CONF(5)
