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



[1mNAME[0m
       ge_conf - Grid Engine configuration files

[1mDESCRIPTION[0m
       [4mge_conf[24m defines the global and local Grid Engine configurations and can
       be shown/modified by [4mqconf[24m(1) using  the  -sconf/-mconf  options.  Only
       root or the cluster administrator may modify [4mge_conf.[0m

       At  its  initial  start-up, [4mge_qmaster[24m(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, [4mge_qmaster[24m(8) writes a  generic
       configuration  containing  default  values  to that same location.  The
       Grid Engine execution daemons [4mge_execd[24m(8) upon start-up retrieve  their
       configuration from [4mge_qmaster[24m(8).

       The  actual  configuration  for both [4mge_qmaster[24m(8) and [4mge_execd[24m(8) is a
       superposition of a [4mglobal[24m configuration and a [4mlocal[24m 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. [1mNote: [22mThe 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.

[1mFORMAT[0m
       The paragraphs that follow provide brief descriptions of the individual
       parameters that compose the global and local configurations for a  Grid
       Engine cluster:

   [1mexecd_spool_dir[0m
       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 [4mge_execd[24m(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  [1mexecd_spool_dir  [22ma 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 [1mexecd_spool_dir[22ms 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 [1mexecd_spool_dir [22mparameter 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.

   [1mmailer[0m
       [1mmailer [22mis 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  [4mge_execd[24m(8)  may  use  a private mail agent. Changing [1mmailer [22mwill
       take immediate effect.

       The default for [1mmailer [22mdepends 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.

   [1mxterm[0m
       [1mxterm  [22mis  the absolute pathname to the X Window System terminal emula-
       tor, [4mxterm[24m(1).

       Each [4mge_execd[24m(8) may use a private mail agent. Changing [1mxterm [22mwill take
       immediate effect.

       The default for [1mxterm [22mis /usr/bin/X11/xterm.

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

   [1mload_sensor[0m
       A comma separated list of executable shell script paths or programs  to
       be started by [4mge_execd[24m(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  [4mge_execd[24m(8)  may  use  a  set  of private [1mload_sensor [22mprograms or
       scripts. Changing [1mload_sensor [22mwill take effect after  two  load  report
       intervals (see [1mload_report_time). A load sensor will be restarted auto-[0m
       [1mmatically if the file modification time of the load  sensor  executable[0m
       [1mchanges.[0m

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

       In addition to the load sensors configured via [1mload_sensor[22m,  [4mge_exec[24m(8)
       searches  for  an  executable  file  named [4mqloadsensor[24m 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 [1mload_sensor[22m.
       This facility is intended for pre-installing a default load sensor.

   [1mprolog[0m
       The executable path of a shell script that is started before  execution
       of  Grid  Engine jobs with the same environment setting as that for the
       Grid Engine jobs to be started afterwards.  An optional prefix  "user@"
       specifies  the  user  under  which this procedure is to be started. The
       procedures standard output and the error output stream are  written  to
       the  same  file  used  also for the standard output and error output of
       each job.  This procedure is intended as a means for  the  Grid  Engine
       administrator  to automate the execution of general site specific tasks
       like the preparation of temporary file systems with the  need  for  the
       same  context  information as the job.  Each [4mge_execd[24m(8) may use a pri-
       vate prolog script.  Correspondingly, the execution host local configu-
       rations   is  can  be  overwritten  by  the  queue  configuration  (see
       [4mqueue_conf[24m(5) ).  Changing [1mprolog [22mwill take immediate effect.

       The default for [1mprolog [22mis 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:

       [4m$host[24m  The  name  of  the host on which the prolog or epilog procedures
              are started.

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

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

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

       [4m$processors[0m
              The [1mprocessors [22mstring as contained in  the  queue  configuration
              (see  [4mqueue_conf[24m(5)) of the master queue (the queue in which the
              prolog and epilog procedures are started).

       [4m$queue[24m The cluster queue name of the master queue  instance,  i.e.  the
              cluster  queue  in  which  the  prolog and epilog procedures are
              started.

       [4m$stdin_path[0m
              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.

       [4m$stdout_path[0m

       [4m$stderr_path[0m
              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.

       [4m$merge_stderr[0m
              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 [4mdrmaa_attributes[24m(3) ) or the qsub param-
              eter '-j y' (see [4mqsub[24m(1) ).

       [4m$fs_stdin_host[0m
              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.

       [4m$fs_stdout_host[0m

       [4m$fs_stderr_host[0m
              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.

       [4m$fs_stdin_path[0m
              When delegated file staging is requested  for  the  stdin  file,
              this   is   the   pathname   of  the  stdin  file  on  the  host
              $fs_stdin_host.

       [4m$fs_stdout_path[0m

       [4m$fs_stderr_path[0m
              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.

       [4m$fs_stdin_tmp_path[0m
              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.

       [4m$fs_stdout_tmp_path[0m

       [4m$fs_stderr_tmp_path[0m
              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.

       [4m$fs_stdin_file_staging[0m

       [4m$fs_stdout_file_staging[0m

       [4m$fs_stderr_file_staging[0m
              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 [1mdelegated_file_staging [22mhow to enable delegated  file
              staging).

              These three flags correspond to the DRMAA job template attribute
              'drmaa_transfer_files' (see [4mdrmaa_attributes[24m(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

   [1mepilog[0m
       The executable path of a shell script that is started  after  execution
       of  Grid  Engine jobs with the same environment setting as that for the
       Grid Engine jobs that has just completed. An  optional  prefix  "user@"
       specifies  the  user  under  which this procedure is to be started. The
       procedures standard output and the error output stream are  written  to
       the  same  file  used  also for the standard output and error output of
       each job.  This procedure is intended as a means for  the  Grid  Engine
       administrator  to automate the execution of general site specific tasks
       like the cleaning up of temporary file systems with the  need  for  the
       same  context  information as the job.  Each [4mge_execd[24m(8) may use a pri-
       vate epilog script.  Correspondingly, the execution host local configu-
       rations   is  can  be  overwritten  by  the  queue  configuration  (see
       [4mqueue_conf[24m(5) ).  Changing [1mepilog [22mwill take immediate effect.

       The default for [1mepilog [22mis the special value NONE, which  prevents  from
       execution of a epilog script.  The  same  special variables as for [1mpro-[0m
       [1mlog [22mcan 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

   [1mshell_start_mode[0m
       [1mNote: [22mDeprecated, 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:

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

       [4mposix_compliant[0m
              POSIX does not  consider  first  script  line  comments  such  a
              `#!/bin/csh'  as 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
              [1mshell_start_mode  [22mis  set  to  [4mposix_compliant[24m  Grid Engine will
              either use the command interpreter indicated by the [1m-S [22moption of
              the  [4mqsub[24m(1)  command  or the [1mshell [22mparameter of the queue to be
              used (see [4mqueue_conf[24m(5) for details).

       [4mscript_from_stdin[0m
              Setting the [1mshell_start_mode [22mparameter either to [4mposix_compliant[0m
              or  [4munix_behavior[24m  requires  you  to  set  the  umask in use for
              [4mge_execd[24m(8)  such  that  every  user  has  read  access  to  the
              active_jobs  directory in the spool directory of the correspond-
              ing execution daemon. In case you have [1mprolog [22mand [1mepilog [22mscripts
              configured,  they  also  need to be readable by any user who may
              execute jobs.
              If this violates your site's security policies you may  want  to
              set  [1mshell_start_mode [22mto [4mscript_from_stdin[24m. This will force Grid
              Engine to open the job script as well as the epilog  and  prolog
              scripts  for  reading  into  STDIN  as  root (if [4mge_execd[24m(8) was
              started as  root)  before  changing  to  the  job  owner's  user
              account.   The  script  is then fed into the STDIN stream of the
              command interpreter indicated by the [1m-S [22moption  of  the  [4mqsub[24m(1)
              command  or  the  [1mshell  [22mparameter  of the queue to be used (see
              [4mqueue_conf[24m(5) for details).
              Thus setting [1mshell_start_mode [22mto [4mscript_from_stdin[24m also  implies
              [4mposix_compliant[24m  behavior.  [1mNote[22m,  however, that feeding scripts
              into the STDIN stream of a command interpreter may cause trouble
              if  commands like [4mrsh[24m(1) are invoked inside a job script as they
              also process the STDIN stream of the command interpreter.  These
              problems  can usually be resolved by redirecting the STDIN chan-
              nel of those commands to come from /dev/null (e.g. rsh host date
              <  /dev/null).  [1mNote also[22m, that any command-line options associ-
              ated with the job are passed to the executing shell.  The  shell
              will  only forward them to the job if they are not recognized as
              valid shell options.

       Changes to [1mshell_start_mode [22mwill take immediate  effect.   The  default
       for [1mshell_start_mode [22mis [4mposix_compliant[24m.

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

   [1mlogin_shells[0m
       UNIX command interpreters like the Bourne-Shell (see [4msh[24m(1)) or  the  C-
       Shell (see [4mcsh[24m(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 [4mqsub[24m(1)).   The  parameter  [1mlogin_shells  [22mcontains  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 [1mshell_start_mode [22m(see above)
       is set to [4mposix_compliant[24m.

       Changes to [1mlogin_shells [22mwill take immediate effect.   The  default  for
       [1mlogin_shells [22mis sh,csh,tcsh,ksh.

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

   [1mmin_uid[0m
       [1mmin_uid [22mplaces a lower bound on user IDs  that  may  use  the  cluster.
       Users  whose  user ID (as returned by [4mgetpwnam[24m(3)) is less than [1mmin_uid[0m
       will not be allowed to run jobs on the cluster.

       Changes to [1mmin_uid [22mwill take immediate effect.  The default for [1mmin_uid[0m
       is 0.

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

   [1mmin_gid[0m
       This parameter sets the lower bound on group IDs that may use the clus-
       ter.  Users whose default group ID (as returned by [4mgetpwnam[24m(3)) is less
       than [1mmin_gid [22mwill not be allowed to run jobs on the cluster.

       Changes to [1mmin_gid [22mwill take immediate effect.  The default for [1mmin_gid[0m
       is 0.

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

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

       Changes to [1muser_lists [22mwill take immediate effect

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

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

       Changes to [1mxuser_lists [22mwill take immediate effect

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

   [1madministrator_mail[0m
       [1madministrator_mail [22mspecifies 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 [1madministrator_mail [22mtakes immediate effect.   The  default  for
       [1madministrator_mail [22mis an empty mail list.

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

   [1mprojects[0m
       The [1mprojects [22mlist 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 [1mprojects [22mlist and the  [1mxpro-[0m
       [1mjects [22mlist (see below), they also cannot use the system.

       Changing  [1mprojects [22mtakes immediate effect.  The default for [1mprojects [22mis
       none.

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

   [1mxprojects[0m
       The [1mxprojects [22mlist 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 [1mprojects [22mlist (see above) and the
       [1mxprojects [22mlist, they also cannot use the system.

       Changing [1mxprojects [22mtakes immediate effect.  The default  for  [1mxprojects[0m
       is none.

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

   [1mload_report_time[0m
       System load is  reported  periodically  by  the  execution  daemons  to
       [4mge_qmaster[24m(8).   The parameter [1mload_report_time [22mdefines the time inter-
       val between load reports.

       Each [4mge_execd[24m(8)  may  use  a  different  load  report  time.  Changing
       [1mload_report_time [22mwill take immediate effect.

       [1mNote:  [22mBe  careful  when modifying [1mload_report_time[22m. Reporting load too
       frequently might block [4mge_qmaster[24m(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 [1mload_report_time [22mis 40 seconds.

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

   [1mreschedule_unknown[0m
       Determines whether jobs on hosts in unknown state are  rescheduled  and
       thus  sent  to  other hosts. Hosts are registered as unknown if [4mge_mas-[0m
       [4mter[24m(8) cannot establish contact to the [4mge_execd[24m(8) on those hosts  (see
       [1mmax_unheard  [22m).  Likely reasons are a breakdown of the host or a break-
       down of the network connection in between, but also [4mge_execd[24m(8) may not
       be executing on such hosts.

       In  any  case, Grid Engine can reschedule jobs running on such hosts to
       another system.  [1mreschedule_unknown [22mcontrols 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  [1m-r  y  [22moption  of  [4mqsub[24m(1)  and  the  [1mrerun  [22moption  of
       [4mqueue_conf[24m(5)).   Parallel  jobs  are  only  rescheduled if the host on
       which their master task executes is in unknown state. The  behavior  of
       [1mreschedule_unknown  [22mfor  parallel  jobs  and for jobs without the rerun
       flag  be  set  can  be  adjusted  using  the  [1mqmaster_params   [22msettings
       [1mENABLE_RESCHEDULE_KILL [22mand [1mENABLE_RESCHEDULE_SLAVE.[0m

       Checkpointing jobs will only be rescheduled when the [1mwhen [22moption of the
       corresponding checkpointing environment contains an  appropriate  flag.
       (see  [4mcheckpoint[24m(5)).  Interactive jobs (see [4mqsh[24m(1), [4mqrsh[24m(1), [4mqtcsh[24m(1))
       are not rescheduled.

       The default for [1mreschedule_unknown [22mis 00:00:00

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

   [1mmax_unheard[0m
       If  [4mge_qmaster[24m(8)  could not contact or was not contacted by the execu-
       tion daemon of a host for [1mmax_unheard [22mseconds, all queues  residing  on
       that  particular  host  are  set  to status unknown.  [4mge_qmaster[24m(8), at
       least, should be contacted by the execution daemons in order to get the
       load   reports.   Thus,   [1mmax_unheard   [22mshould   by  greater  than  the
       [1mload_report_time [22m(see above).

       Changing  [1mmax_unheard  [22mtakes  immediate  effect.    The   default   for
       [1mmax_unheard [22mis 5 minutes.

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

   [1mloglevel[0m
       This parameter specifies the level of detail that  Grid  Engine  compo-
       nents  such as [4mge_qmaster[24m(8) or [4mge_execd[24m(8) use to produce informative,
       warning or error messages which are logged to the [4mmessages[24m files in the
       master  and  execution daemon spool directories (see the description of
       the [1mexecd_spool_dir [22mparameter above). The following message levels  are
       available:

       [4mlog_err[0m
              All error events being recognized are logged.

       [4mlog_warning[0m
              All  error  events  being  recognized  and all detected signs of
              potentially erroneous behavior are logged.

       [4mlog_info[0m
              All error events being recognized, all detected signs of  poten-
              tially  erroneous behavior and a variety of informative messages
              are logged.

       Changing [1mloglevel [22mwill take immediate effect.

       The default for [1mloglevel [22mis [4mlog_warning[24m.

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

   [1mmax_aj_instances[0m
       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 [1mmax_aj_instances [22mwill take immediate effect.

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

   [1mmax_aj_tasks[0m
       This  parameter defines the maximum number of array job tasks within an
       array job.  [4mge_qmaster[24m(8) will reject all array job  submissions  which
       request  more  than  [1mmax_aj_tasks [22marray job tasks. The default for this
       parameter is 75000. The value 0 will deactivate this limit.

       Changing [1mmax_aj_tasks [22mwill take immediate effect.

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

   [1mmax_u_jobs[0m
       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 [1mmax_u_jobs [22mlimit is exceeded by  a  job  submission
       then  the submission command exits with exit status 25 and an appropri-
       ate error message.

       Changing [1mmax_u_jobs [22mwill take immediate effect.

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

   [1mmax_jobs[0m
       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 [1mmax_jobs[0m
       limit is exceeded by a job submission then the submission command exits
       with exit status 25 and an appropriate error message.

       Changing [1mmax_jobs [22mwill take immediate effect.

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

   [1mmax_advance_reservations[0m
       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
       [1mmax_advance_reservations  [22mlimit  is  exceeded by an Advance Reservation
       request then the submission command exits with exit status  25  and  an
       appropriate error message.

       Changing [1mmax_advance_reservations [22mwill take immediate effect.

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

   [1menforce_project[0m
       If set to [4mtrue[24m[1m, users are required to request a project  whenever  sub-[0m
       [1mmitting a job. See the -P option to [4m[22mqsub[24m(1) for details.

       Changing  [1menforce_project  [22mwill take immediate effect.  The default for
       [1menforce_project [22mis [4mfalse[24m.


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

   [1menforce_user[0m
       If  set to [4mtrue[24m[1m, a [4m[22muser[24m(5) must exist to allow for job submission. Jobs
       are rejected if no corresponding user exists.

       If set to [4mauto[24m[1m, a [4m[22muser[24m(5) object for the submitting user will automati-
       cally  be created during job submission, if one does not already exist.
       The [1mauto_user_oticket[22m, [1mauto_user_fshare[22m, [1mauto_user_default_project[22m, and
       [1mauto_user_delete_time  [22mconfiguration parameters will be used as default
       attributes of the new [4muser[24m(5) object.

       Changing [1menforce_user [22mwill take  immediate  effect.   The  default  for
       [1menforce_user [22mis [4mauto[24m.


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

   [1mauto_user_oticket[0m
       The number of override  tickets  to  assign  to  automatically  created
       [4muser[24m(5)   objects.  User  objects  are  created  automatically  if  the
       [1menforce_user [22mattribute is set to [4mauto[24m.

       Changing [1mauto_user_oticket [22mwill 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.

   [1mauto_user_fshare[0m
       The number of functional shares  to  assign  to  automatically  created
       [4muser[24m(5)   objects.  User  objects  are  created  automatically  if  the
       [1menforce_user [22mattribute is set to [4mauto[24m.

       Changing [1mauto_user_fshare [22mwill 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.

   [1mauto_user_default_project[0m
       The default project to assign to automatically created [4muser[24m(5) objects.
       User objects are created automatically if the [1menforce_user [22mattribute is
       set to [4mauto[24m.

       Changing [1mauto_user_default_project [22mwill 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.

   [1mauto_user_delete_time[0m
       The number of seconds of inactivity after which  automatically  created
       [4muser[24m(5) objects will be deleted. User objects are created automatically
       if the [1menforce_user [22mattribute is set to [4mauto[24m. 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 [1mauto_user_delete_time [22mwill 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.

   [1mset_token_cmd[0m
       [1mNote: [22mDeprecated, may be removed in future release.
       This parameter is only present if your Grid Engine system  is  licensed
       to support AFS.

       [1mSet_token_cmd [22mpoints 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 [4mforge[24m to read the secret AFS  server  key,  a
       site might wish to replace the [1mset_token_cmd [22mscript 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 [4mSetToken[24m is
       executed.

       Changing [1mset_token_cmd [22mwill take immediate  effect.   The  default  for
       [1mset_token_cmd [22mis none.

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

   [1mpag_cmd[0m
       [1mNote: [22mDeprecated, 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 [4mpagsh[24m [1mis specified via this parameter.  The [4m[22mge_shep-[0m
       [4mherd[24m(8) process and the job run in a [4mpagsh[24m. Please ask your AFS  admin-
       istrator for details.

       Changing  [1mpag_cmd  [22mwill take immediate effect.  The default for [1mpag_cmd[0m
       is none.

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

   [1mtoken_extend_time[0m
       [1mNote: [22mDeprecated, may be removed in future release.
       This  parameter  is only present if your Grid Engine system is licensed
       to support AFS.

       The [1mtoken_extend_time [22mis 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 [1mtoken_extend_time [22mwill take immediate effect.  The default for
       [1mtoken_extend_time [22mis 24:0:0, i.e. 24 hours.

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

   [1mshepherd_cmd[0m
       Alternative path to the [1mshepherd_cmd [22mbinary. Typically used to call the
       shepherd binary by a wrapper script or command.

       Changing [1mshepherd_cmd [22mwill take immediate effect. The default for [1mshep-[0m
       [1mherd_cmd [22mis none.

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

   [1mgid_range[0m
       The [1mgid_range [22mis 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  [4mge_execd[24m(8)  to
       identify processes belonging to the same job.

       Each  [4mge_execd[24m(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 [4mge_execd[24m(8) is started.

       Changing [1mgid_range [22mwill take immediate effect.  There is no default for
       [1mgid_range[22m. The administrator will have to assign a value for  [1mgid_range[0m
       during installation of Grid Engine.

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

   [1mqmaster_params[0m
       A list of additional parameters can be passed to the Grid Engine  qmas-
       ter. The following values are recognized:

       [4mENABLE_ENFORCE_MASTER_LIMIT[0m
              If  this parameter is set then the [1ms_rt[22m, [1mh_rt [22mlimit of a running
              job are tested  and  executed  by  the  [4mge_qmaster[24m(8)  when  the
              [4mge_execd[24m(8) where the job is in unknown state.

              After  [1ms_rt  or  h_rt  limit of a job is expired then the master[0m
              [1mdaemon will wait additional time defined by DURATION_OFFSET (see[0m
              [4msched_conf[24m(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 [1m-f [22mof [4mqdel[24m(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 [1mfailed [22mstate 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 [4mge_qmaster[24m(8) the limit enforcement will at
              first   be   triggered   after   the   double   of  the  biggest
              [1mload_report_interval [22minterval defined in  [4msge_conf[24m(5)  has  been
              elapsed.  This  will  give  the execution daemons enough time to
              reregister at master daemon.

       [4mENABLE_FORCED_QDEL_IF_UNKNOWN[0m
              If this parameter is set then a deletion request for  a  job  is
              automatically  interpreted  as a forced deletion request (see [1m-f[0m
              of [4mqdel[24m(1)) if the host, where the job is running is in  unknown
              state.

       [4mENABLE_FORCED_QDEL[0m
              If  this  parameter  is  set, non-administrative users can force
              deletion of their own jobs via the [4m-f[24m option of [4mqdel[24m(1).   With-
              out  this  parameter, forced deletion of jobs is only allowed by
              the Grid Engine manager or operator.

              [1mNote: [22mForced 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 [4mqdel[24m(1) is executed first,  and  deletion
              is forced only if the normal cancellation was unsuccessful.

       [4mFORBID_RESCHEDULE[0m
              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.


       [4mFORBID_APPERROR[0m
              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.


       [4mDISABLE_AUTO_RESCHEDULING[0m
              [1mNote: [22mDeprecated, may be removed in future release.
              If set to "true" or "1", the [4mreschedule_unknown[24m parameter is not
              taken into account.


       [4mENABLE_RESCHEDULE_KILL[0m
              If set  to  "true"  or  "1",  the  [4mreschedule_unknown[24m  parameter
              affects  also  jobs which have the rerun flag not activated (see
              the  [1m-r  y  [22moption  of  [4mqsub[24m(1)  and   the   [1mrerun   [22moption   of
              [4mqueue_conf[24m(5)),  but  they  are  just  finished as they can't be
              rescheduled.


       [4mENABLE_RESCHEDULE_SLAVE[0m
              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  [4mreschedule_unknown[24m  parameter
              is activated.


       [4mMAX_DYN_EC[0m
              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.


       [4mMONITOR_TIME[0m
              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.


       [4mLOG_MONITOR_MESSAGE[0m
              Monitoring information is logged  into  the  messages  files  by
              default.  This  information can be accessed via by [4mqping[24m(1).  If
              monitoring is always enabled,  the  messages  files  can  become
              quite  large.   This  switch  disables logging into the messages
              files, making [4mqping[24m [4m-f[24m the only source of monitoring data.


       [4mPROF_SIGNAL[0m
              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)


       [4mPROF_WORKER[0m
              Enables  the  profiling  for  qmaster  worker  threads.    (e.g.
              PROF_WORKER=true)


       [4mPROF_LISTENER[0m
              Enables  the  profiling  for  qmaster  listener  threads.  (e.g.
              PROF_LISTENER=true)


       [4mPROF_DELIVER[0m
              Enables the profiling for qmaster event deliver  thread.   (e.g.
              PROF_DELIVER=true)


       [4mPROF_TEVENT[0m
              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".

       [4mSTREE_SPOOL_INTERVAL[0m
              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)


       [4mMAX_JOB_DELETION_TIME[0m
              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)


       [4mgdi_timeout[0m
              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.


       [4mgdi_retries[0m
              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)


       [4mcl_ping[0m
              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)


       [4mSCHEDULER_TIMEOUT[0m
              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 [4mSCHED-[0m
              [4mULER_TIMEOUT[24m value is specified in seconds.

       Changing [1mqmaster_params [22mwill take immediate effect, except gdi_timeout,
       gdi_retries,  cl_ping, these will take effect only for new connections.
       The default for [1mqmaster_params [22mis none.

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

   [1mexecd_params[0m
       This  is used for passing additional parameters to the Grid Engine exe-
       cution daemon. The following values are recognized:

       [4mACCT_RESERVED_USAGE[0m
              If this parameter  is  set  to  true,  the   usage  of  reserved
              resources  is  used  for  the accounting entries [1mcpu[22m, [1mmem [22mand [1mio[0m
              instead of the measured usage.


       [4mENABLE_WINDOMACC[0m
              If this parameter is set to true, Windows Domain accounts  (Win-
              DomAcc)  are  used  on Windows hosts. These accounts require the
              use of [4msgepasswd[24m(1) (see also [4msgepasswd[24m(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.


       [4mKEEP_ACTIVE[0m
              This value should only be set for debugging purposes. If set  to
              true,  the  execution daemon will not remove the spool directory
              maintained by [4mge_shepherd[24m(8) for a job.


       [4mPTF_MIN_PRIORITY[24m, [4mPTF_MAX_PRIORITY[0m
              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 [4mnice[24m(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.


       [4mPROF_EXECD[0m
              Enables  the  profiling  for  the   execution   daemon.    (e.g.
              PROF_EXECD=true)


       [4mNOTIFY_KILL[0m
              The  parameter  allows you to change the notification signal for
              the signal SIGKILL (see [4m-notify[24m option of [4mqsub[24m(1)).  The parame-
              ter  either  accepts signal names (use the [4m-l[24m option of [4mkill[24m(1))
              or the special value [4mnone[24m. If set to [4mnone[24m, no notification  sig-
              nal will be sent. If it is set to [4mTERM[24m, for instance, or another
              signal name then this signal will be sent as  notification  sig-
              nal.


       [4mNOTIFY_SUSP[0m
              With  this  parameter  it is possible to modify the notification
              signal  for  the  signal  SIGSTOP  (see  [4m-notify[24m  parameter   of
              [4mqsub[24m(1)).  The parameter either accepts signal names (use the [4m-l[0m
              option of [4mkill[24m(1)) or the special value [4mnone[24m. If set to [4mnone[24m, no
              notification  signal  will  be  sent.  If it is set to [4mTSTP[24m, for
              instance, or another signal name then this signal will  be  sent
              as notification signal.


       [4mSHARETREE_RESERVED_USAGE[0m
              [1mNote: [22mDeprecated, 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.


       [4mUSE_QSUB_GID[0m
              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
              [4mpasswd[24m(5) file is used.
              The  feature  is  only available for jobs submitted via [4mqsub[24m(1),
              [4mqrsh[24m(1), [4mqmake[24m(1) and [4mqtcsh[24m(1).  Also, it only works for [4mqrsh[24m(1)
              jobs  (and  thus also for [4mqtcsh[24m(1) and [4mqmake[24m(1)) if rsh and rshd
              components are used which are provided with Grid  Engine  (i.e.,
              the  [1mrsh_daemon  [22mand  [1mrsh_command  [22mparameters may not be changed
              from the default).


       [4mS_DESCRIPTORS[24m, [4mH_DESCRIPTORS[24m, [4mS_MAXPROC[24m, [4mH_MAXPROC[24m,

       [4mS_MEMORYLOCKED[24m, [4mH_MEMORYLOCKED[24m, [4mS_LOCKS[24m, [4mH_LOCKS[0m
              Specifies soft and hard resource limits as  implemented  by  the
              [4msetrlimit[24m(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 [4mqueue_conf[24m(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.
              [4mS_DESCRIPTORS[24m and [4mH_DESCRIPTORS[24m specify a value one greater than
              the  maximum  file  descriptor  number that can be opened by any
              process of a job.
              [4mS_MAXPROC[24m and [4mH_MAXPROC[24m specify the maximum number of  processes
              that can be created by the job user on this execution host
              [4mS_MEMORYLOCKED[24m  and [4mH_MEMORYLOCKED[24m specify the maximum number of
              bytes of virtual memory that may be locked into RAM.
              [4mS_LOCKS[24m and [4mH_LOCKS[24m 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 [4msge_types[24m(1) for details.

       [4mINHERIT_ENV[0m
              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.


       [4mSET_LIB_PATH[0m
              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.


       [4mENABLE_ADDGRP_KILL[0m
              If this parameter is set then Grid Engine uses the supplementary
              group ids (see [4mgid_range[24m) to identify all processes which are to
              be terminated when a job  is  deleted,  or  when  [4mge_shepherd[24m(8)
              cleans up after job termination.


       [4mPDC_INTERVAL[0m
              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 [4mqueue_conf[24m(5)) and job usage  collection.
              The  parameter can be set to a time_specifier (see [4msge_types[24m(5))
              , to [1mPER_LOAD_REPORT [22mor to [1mNEVER[22m.
              If this parameter is set to [1mPER_LOAD_REPORT [22mthe PDC is triggered
              in  the  same  interval as [1mload_report_time [22m(see above). If this
              parameter is set to [1mNEVER [22mthe PDC run is  never  triggered.  The
              default is 1 second.
              [1mNote:  [22mA 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 [1mexecd_params [22mwill take effect after it was propagated  to  the
       execution daemons. The propagation is done in one load report interval.
       The default for [1mexecd_params [22mis none.

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

   [1mreporting_params[0m
       Used  to  define  the  behavior of reporting modules in the Grid Engine
       qmaster. Changes to the [1mreporting_params [22mtakes immediate  effect.   The
       following values are recognized:

       [4maccounting[0m
              If  this  parameter is set to true, the accounting file is writ-
              ten.  The accounting file is prerequisite for  using  the  [1mqacct[0m
              command.


       [4mreporting[0m
              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 [4mreporting[24m(5)  for  further
              information about format and contents of the reporting file.


       [4mflush_time[0m
              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 [4mflush_time[24m 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.


       [4maccounting_flush_time[0m
              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  [4maccounting_flush_time[24m  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 [4mflush_time[0m
              parameter.


       [4mjoblog[24m If this parameter is set to true, the reporting file  will  con-
              tain job logging information. See [4mreporting[24m(5) for more informa-
              tion about job logging.


       [4msharelog[0m
              The Grid Engine qmaster can  dump  information  about  sharetree
              configuration  and  use  to  the  reporting file.  The parameter
              [4msharelog[24m 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  [4mreporting[24m(5)  for  further  information  about
              sharelog.


       [4mlog_consumables[0m
              This  parameter  controls writing of consumable resources to the
              reporting file.  When set to ([1mlog_consumables=true)  information[0m
              [1mabout  all  consumable  resources (their current usage and their[0m
              [1mcapacity) will be written to the reporting file, whenever a con-[0m
              [1msumable  resource  changes either in definition, or in capacity,[0m
              [1mor when the  usage  of  a  consumable  resource  changes.   When[0m
              [1mlog_consumables  is set to false (default), only those variables[0m
              [1mwill be written to the reporting file, that  are  configured  in[0m
              [1mthe   report_variables  in  the  exec  host  configuration,  see[0m
              [4mhost_conf[24m(5) for further information about [1mreport_variables.[0m


   [1mfinished_jobs[0m
       [1mNote: [22mDeprecated, may be removed in future release.
       Grid Engine stores a certain number of [4mjust[24m [4mfinished[24m  jobs  to  provide
       post mortem status information. The [1mfinished_jobs [22mparameter 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 [1mfinished_jobs [22mwill take immediate  effect.   The  default  for
       [1mfinished_jobs [22mis 100.

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

   [1mqlogin_daemon[0m
       This parameter specifies the mechanism that is to  be  started  on  the
       server  side of a [4mqlogin[24m(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 [1mqlogin_daemon [22mwill take immediate effect.  The  default  value
       for [1mqlogin_daemon [22mis 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

   [1mqlogin_command[0m
       This is the command to be executed on the client side  of  a  [4mqlogin[24m(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 [1mqlogin_command [22mwill take immediate effect.  The default  value
       for [1mqlogin_command [22mis 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

   [1mrlogin_daemon[0m
       This parameter specifies the mechanism that is to  be  started  on  the
       server  side of a [4mqrsh[24m(1) request [1mwithout [22ma 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 [1mrlogin_daemon [22mwill take  immediate  effect.  The  default  for
       [1mrlogin_daemon [22mis 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  [1mqlo-[0m
       [1mgin_daemon.[0m

   [1mrlogin_command[0m
       This  is  the  mechanism to be executed on the client side of a [4mqrsh[24m(1)
       request [1mwithout [22ma 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 [4mssh[24m, which also understand this syn-
       tax.

       Changing [1mrlogin_command [22mwill take immediate effect. The  default  value
       for [1mrlogin_command [22mis builtin.

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

       In addition to the examples of [1mqlogin_command [22m, this value is allowed:
       rsh_daemon      none

   [1mrsh_daemon[0m
       This parameter specifies the mechanism that is to  be  started  on  the
       server side of a [4mqrsh[24m(1) request [1mwith [22ma 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  [1mrsh_daemon  [22mwill take immediate effect. The default value for
       [1mrsh_daemon [22mis builtin.

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

       In addition to the examples of [1mqlogin_daemon [22m, this value is allowed:
       rsh_daemon      none

   [1mrsh_command[0m
       This  is  the  mechanism to be executed on the client side of a [4mqrsh[24m(1)
       request [1mwith [22ma 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 [4mtelnet[24m(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 [4mssh[24m, which also  understand
       this syntax.

       Changing  [1mrsh_command [22mwill take immediate effect. The default value for
       [1mrsh_command [22mis builtin.

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

       In addition to the examples of [1mqlogin_command [22m, this value is allowed:
       rsh_command     none

   [1mdelegated_file_staging[0m
       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).

   [1mreprioritize[0m
       [1mNote: [22mDeprecated, may be removed in future release.
       This flag enables or disables the reprioritization  of  jobs  based  on
       their  ticket  amount. The [1mreprioritize_interval [22min [4msched_conf[24m(5) takes
       effect only if [1mreprioritize [22mis set to true. To turn off job reprioriti-
       zation,  the  [1mreprioritize  [22mflag must be set to false and the [1mrepriori-[0m
       [1mtize_interval [22mto 0 which is the default.

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

   [1mjsv_url[0m
       This  setting  defines  a server JSV instance which will be started and
       triggered by the [4msge_qmaster[24m(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 [4mjsv[24m(1) and [4msge_request[24m(1).

       The syntax of the [1mjsv_url [22mis specified in [4msge_types[24m(1).

   [1mjsv_allowed_mod[0m
       If there is a server JSV script defined with  [1mjsv_url  [22mparameter,  then
       all [4mqalter[24m(1) or [4mqmon[24m(1) modification requests for jobs are rejected by
       qmaster. With the [1mjsv_allowed_mod [22mparameter 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 [4mqsub[24m(1) or the value [1mnone [22mto indicate that  no  modifica-
       tion should be allowed.

   [1mlibjvm_path[0m
       [1mlibjvm_path  [22mis  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 [1madditional_jvm_args[22m. If the  jvm
       thread  is  started  at all can be defined in the [4mbootstrap[24m(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.

   [1madditional_jvm_args[0m
       [1madditional_jvm_args  [22mis  usually  set  during   qmaster   installation.
       Details  about  possible values [1madditional_jvm_args [22mcan 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.

[1mSEE ALSO[0m
       [4mge_intro[24m(1), [4mcsh[24m(1), [4mqconf[24m(1), [4mqsub[24m(1), [4mjsv[24m(1), [4mrsh[24m(1),  [4msh[24m(1),  [4mgetpw-[0m
       [4mnam[24m(3),      [4mdrmaa_attributes[24m(3),     [4mqueue_conf[24m(5),     [4msched_conf[24m(5),
       [4msge_types[24m(1), [4mge_execd[24m(8), [4mge_qmaster[24m(8), [4mge_shepherd[24m(8), [4mcron[24m(8), [4mGrid[0m
       [4mEngine[24m [4mInstallation[24m [4mand[24m [4mAdministration[24m [4mGuide.[0m

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



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