Provided by: gridengine-common_6.2u5-1ubuntu1_all bug

NAME

       sge_conf - Sun Grid Engine configuration files

DESCRIPTION

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

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

       The  actual configuration for both sge_qmaster(8) and sge_execd(8) is a
       superposition of a  global  configuration  and  a  local  configuration
       pertinent  for  the host on which a master or execution daemon resides.
       If a local  configuration  is  available,  its  entries  overwrite  the
       corresponding  entries  of  the  global  configuration. Note: The local
       configuration does not have to contain all valid configuration entries,
       but only those which need to be modified against the global entries.

       Note:  Sun 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.

FORMAT

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

   execd_spool_dir
       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
       execution host local configurations, i.e. each sge_execd(8) may have  a
       private  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   execd_spool_dir   a   directory   named  corresponding  to  the
       unqualified hostname of the execution host is opened and  contains  all
       information   spooled   to   disk.   Thus,   it  is  possible  for  the
       execd_spool_dirs 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 execd_spool_dir 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
       $SGE_ROOT/$SGE_CELL/spool.

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

   mailer
       mailer 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  sge_execd(8)  may  use a private mail agent. Changing mailer will
       take immediate effect.

       The default for mailer depends on the operating system of the  host  on
       which  the  Sun  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.

   xterm
       xterm  is  the  absolute  pathname  to  the  X  Window  System terminal
       emulator, xterm(1).

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

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

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

   load_sensor
       A comma separated list of executable shell script paths or programs  to
       be  started  by  sge_execd(8)  and to be used in order to retrieve site
       configurable load information  (e.g.  free  space  on  a  certain  disk
       partition).

       Each  sge_execd(8)  may  use  a  set of private load_sensor programs or
       scripts. Changing load_sensor will take effect after  two  load  report
       intervals  (see  load_report_time).  A  load  sensor  will be restarted
       automatically  if  the  file  modification  time  of  the  load  sensor
       executable changes.

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

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

   prolog
       The  executable path of a shell script that is started before execution
       of Sun Grid Engine jobs with the same environment setting as  that  for
       the  Sun 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 Sun 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 sge_execd(8) may  use  a
       private  prolog  script.   Correspondingly,  the  execution  host local
       configurations is can be overwritten by the  queue  configuration  (see
       queue_conf(5) ).  Changing prolog will take immediate effect.

       The  default  for prolog 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
       procedure) to constitute a command line:

       $host  The name of the host on which the prolog  or  epilog  procedures
              are started.

       $job_owner
              The user name of the job owner.

       $job_id
              Sun Grid Engine's unique job identification number.

       $job_name
              The name of the job.

       $processors
              The  processors  string  as contained in the queue configuration
              (see queue_conf(5)) of the master queue (the queue in which  the
              prolog and epilog procedures are started).

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

       $stdin_path
              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.

       $stdout_path

       $stderr_path
              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
              stdout/stderr pathname given via DRMAA or qsub.

       $merge_stderr
              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
              stdout  can  be  requested  via the DRMAA job template attribute
              'drmaa_join_files'  (see  drmaa_attributes(3)  )  or  the   qsub
              parameter '-j y' (see qsub(1) ).

       $fs_stdin_host
              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.

       $fs_stdout_host

       $fs_stderr_host
              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.

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

       $fs_stdout_path

       $fs_stderr_path
              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.

       $fs_stdin_tmp_path
              When  delegated  file  staging  is requested for the stdin file,
              this is the destination  pathname  of  the  stdin  file  on  the
              execution  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.

       $fs_stdout_tmp_path

       $fs_stderr_tmp_path
              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_stdout_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.

       $fs_stdin_file_staging

       $fs_stdout_file_staging

       $fs_stderr_file_staging
              When   delegated   file   staging   is   requested    for    the
              stdin/stdout/stderr  file,  the flag is set to "1", otherwise it
              is set to "0"  (see  in  delegated_file_staging  how  to  enable
              delegated file staging).

              These three flags correspond to the DRMAA job template attribute
              'drmaa_transfer_files' (see drmaa_attributes(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

   epilog
       The executable path of a shell script that is started  after  execution
       of  Sun  Grid Engine jobs with the same environment setting as that for
       the Sun 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  Sun  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 sge_execd(8) may use a
       private epilog  script.   Correspondingly,  the  execution  host  local
       configurations  is  can  be overwritten by the queue configuration (see
       queue_conf(5) ).  Changing epilog will take immediate effect.

       The default for epilog is the special value NONE, which  prevents  from
       execution  of  a  epilog  script.   The  same  special variables as for
       prolog 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

   shell_start_mode
       Note: 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
       recognized:

       unix_behavior
              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  Sun  Grid  Engine when starting jobs if
              unix_behavior is defined as shell_start_mode.

       posix_compliant
              POSIX does not  consider  first  script  line  comments  such  a
              `#!/bin/csh'  as  significant.  The  POSIX  standard  for  batch
              queuing  systems  (P1003.2d)  therefore  requires  a   compliant
              queuing system to ignore such lines but to use user specified or
              configured  default  command  interpreters  instead.  Thus,   if
              shell_start_mode  is set to posix_compliant Sun Grid Engine will
              either use the command interpreter indicated by the -S option of
              the  qsub(1)  command  or the shell parameter of the queue to be
              used (see queue_conf(5) for details).

       script_from_stdin
              Setting the shell_start_mode parameter either to posix_compliant
              or  unix_behavior  requires  you  to  set  the  umask in use for
              sge_execd(8) such  that  every  user  has  read  access  to  the
              active_jobs   directory   in   the   spool   directory   of  the
              corresponding execution daemon. In  case  you  have  prolog  and
              epilog  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  shell_start_mode  to script_from_stdin. This will force Sun
              Grid Engine to open the job script as well  as  the  epilog  and
              prolog  scripts  for reading into STDIN as root (if sge_execd(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 -S option  of  the  qsub(1)
              command  or  the  shell  parameter  of the queue to be used (see
              queue_conf(5) for details).
              Thus setting shell_start_mode to script_from_stdin also  implies
              posix_compliant  behavior.  Note,  however, that feeding scripts
              into the STDIN stream of a command interpreter may cause trouble
              if  commands like rsh(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
              channel of those commands to come from /dev/null (e.g. rsh  host
              date  <  /dev/null).  Note  also,  that any command-line options
              associated 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 shell_start_mode will take immediate  effect.   The  default
       for shell_start_mode is posix_compliant.

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

   login_shells
       UNIX command interpreters like the Bourne-Shell (see sh(1)) or  the  C-
       Shell (see csh(1)) can be used by Sun 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
       Sun Grid Engine - see qsub(1)).  The parameter login_shells contains  a
       comma   separated   list   of  the  executable  names  of  the  command
       interpreters to be started as login-shells.  Shells in  this  list  are
       only  started  as  login  shells if the parameter shell_start_mode (see
       above) is set to posix_compliant.

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

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

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

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

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

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

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

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

   user_lists
       The user_lists parameter contains a comma separated list of user access
       lists  as described in access_list(5).  Each user contained in at least
       one of the enlisted access lists has access  to  the  cluster.  If  the
       user_lists  parameter  is set to NONE (the default) any user has access
       not explicitly excluded via the xuser_lists parameter described  below.
       If  a  user is contained both in an access list enlisted in xuser_lists
       and user_lists the user is denied access to the cluster.

       Changes to user_lists will take immediate effect

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

   xuser_lists
       The  xuser_lists  parameter  contains  a  comma  separated list of user
       access lists as described in access_list(5).  Each user contained in at
       least one of the enlisted access lists is denied access to the cluster.
       If the xuser_lists parameter is set to NONE (the default) any user  has
       access.   If  a  user  is  contained both in an access list enlisted in
       xuser_lists and user_lists (see above) the user is denied access to the
       cluster.

       Changes to xuser_lists will take immediate effect

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

   administrator_mail
       administrator_mail 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
       system's configuration guide for more information.

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

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

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

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

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

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

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

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

   load_report_time
       System load is  reported  periodically  by  the  execution  daemons  to
       sge_qmaster(8).    The  parameter  load_report_time  defines  the  time
       interval between load reports.

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

       Note:  Be  careful  when modifying load_report_time. Reporting load too
       frequently might block  sge_qmaster(8)  especially  if  the  number  of
       execution  hosts  is  large.  Moreover, since the system load typically
       increases and decreases smoothly, frequent load  reports  hardly  offer
       any benefit.

       The default for load_report_time is 40 seconds.

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

   reschedule_unknown
       Determines whether jobs on hosts in unknown state are  rescheduled  and
       thus   sent  to  other  hosts.  Hosts  are  registered  as  unknown  if
       sge_master(8) cannot establish contact to  the  sge_execd(8)  on  those
       hosts (see max_unheard ). Likely reasons are a breakdown of the host or
       a breakdown of the network connection in between, but also sge_execd(8)
       may not be executing on such hosts.

       In  any case, Sun Grid Engine can reschedule jobs running on such hosts
       to another system.  reschedule_unknown controls the time which Sun 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  -r  y  option  of  qsub(1)  and  the  rerun  option of
       queue_conf(5)).  Parallel jobs are only  rescheduled  if  the  host  on
       which  their  master task executes is in unknown state. The behavior of
       reschedule_unknown for parallel jobs and for  jobs  without  the  rerun
       flag   be  set  can  be  adjusted  using  the  qmaster_params  settings
       ENABLE_RESCHEDULE_KILL and ENABLE_RESCHEDULE_SLAVE.

       Checkpointing jobs will only be rescheduled when the when option of the
       corresponding  checkpointing  environment contains an appropriate flag.
       (see checkpoint(5)).  Interactive jobs (see qsh(1), qrsh(1),  qtcsh(1))
       are not rescheduled.

       The default for reschedule_unknown is 00:00:00

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

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

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

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

   loglevel
       This  parameter  specifies  the  level  of  detail that Sun Grid Engine
       components such  as  sge_qmaster(8)  or  sge_execd(8)  use  to  produce
       informative, warning or error messages which are logged to the messages
       files in the master and execution daemon  spool  directories  (see  the
       description  of  the  execd_spool_dir  parameter  above). The following
       message levels are available:

       log_err
              All error events being recognized are logged.

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

       log_info
              All  error  events  being  recognized,  all  detected  signs  of
              potentially erroneous behavior  and  a  variety  of  informative
              messages are logged.

       Changing loglevel will take immediate effect.

       The default for loglevel is log_warning.

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

   max_aj_instances
       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 max_aj_instances will take immediate effect.

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

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

       Changing max_aj_tasks will take immediate effect.

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

   max_u_jobs
       The number of active (not finished) jobs which  each  Sun  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  max_u_jobs  limit is exceeded by a job
       submission then the submission command exits with exit status 25 and an
       appropriate error message.

       Changing max_u_jobs will take immediate effect.

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

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

       Changing max_jobs will take immediate effect.

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

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

       Changing max_advance_reservations will take immediate effect.

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

   enforce_project
       If  set  to  true,  users  are  required  to request a project whenever
       submitting a job. See the -P option to qsub(1) for details.

       Changing enforce_project will take immediate effect.  The  default  for
       enforce_project is false.

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

   enforce_user
       If set to true, a user(5) must exist to allow for job submission.  Jobs
       are rejected if no corresponding user exists.

       If  set  to  auto,  a  user(5)  object  for  the  submitting  user will
       automatically be created during job submission, if one does not already
       exist.         The         auto_user_oticket,         auto_user_fshare,
       auto_user_default_project,  and   auto_user_delete_time   configuration
       parameters  will  be  used  as  default  attributes  of the new user(5)
       object.

       Changing enforce_user will take  immediate  effect.   The  default  for
       enforce_user is auto.

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

   auto_user_oticket
       The number of override  tickets  to  assign  to  automatically  created
       user(5)   objects.  User  objects  are  created  automatically  if  the
       enforce_user attribute is set to auto.

       Changing auto_user_oticket 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
       overwritten by the execution host local configuration.

   auto_user_fshare
       The number of functional shares  to  assign  to  automatically  created
       user(5)   objects.  User  objects  are  created  automatically  if  the
       enforce_user attribute is set to auto.

       Changing auto_user_fshare 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
       overwritten by the execution host local configuration.

   auto_user_default_project
       The default project to assign to automatically created user(5) objects.
       User objects are created automatically if the enforce_user attribute is
       set to auto.

       Changing auto_user_default_project 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
       overwritten by the execution host local configuration.

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

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

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

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

       Set_token_cmd points to a command which sets and extends AFS tokens for
       Sun Grid Engine jobs. In the standard Sun 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 forge to read the secret AFS  server  key,  a
       site might wish to replace the set_token_cmd 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 SetToken is
       executed.

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

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

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

       The   path  to  your  pagsh  is  specified  via  this  parameter.   The
       sge_shepherd(8) process and the job run in a pagsh. Please ask your AFS
       administrator for details.

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

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

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

       The token_extend_time is the time  period  for  which  AFS  tokens  are
       periodically extended. Sun 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 token_extend_time will take immediate effect.  The default for
       token_extend_time is 24:0:0, i.e. 24 hours.

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

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

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

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

   gid_range
       The gid_range 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  sge_execd(8)  to
       identify processes belonging to the same job.

       Each sge_execd(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 sge_execd(8) is started.

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

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

   qmaster_params
       A list of additional parameters can be passed to the  Sun  Grid  Engine
       qmaster. The following values are recognized:

       ENABLE_ENFORCE_MASTER_LIMIT
              If  this parameter is set then the s_rt, h_rt limit of a running
              job are tested and  executed  by  the  sge_qmaster(8)  when  the
              sge_execd(8) where the job is in unknown state.

              After  s_rt  or  h_rt  limit of a job is expired then the master
              daemon will wait additional time defined by DURATION_OFFSET (see
              sched_conf(5)).    If  the  execution  daemon  still  cannot  be
              contacted when this additional time is elapsed, then the  master
              daemon will force the deletion of the job (see -f of qdel(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 failed 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 sge_qmaster(8) the limit  enforcement  will
              at   first   be  triggered  after  the  double  of  the  biggest
              load_report_interval interval defined in  sge_conf(5)  has  been
              elapsed.  This  will  give  the execution daemons enough time to
              reregister at master daemon.

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

       ENABLE_FORCED_QDEL
              If  this  parameter  is  set, non-administrative users can force
              deletion of their  own  jobs  via  the  -f  option  of  qdel(1).
              Without  this parameter, forced deletion of jobs is only allowed
              by the Sun Grid Engine manager or operator.

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

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

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

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

       ENABLE_RESCHEDULE_KILL
              If  set  to  "true"  or  "1",  the  reschedule_unknown parameter
              affects also jobs which have the rerun flag not  activated  (see
              the   -r   y   option   of  qsub(1)  and  the  rerun  option  of
              queue_conf(5)), but they are just  finished  as  they  can't  be
              rescheduled.

       ENABLE_RESCHEDULE_SLAVE
              If   set   to  "true"  or  "1"  Sun  Grid  Engine  triggers  job
              rescheduling also when the host  where  the  slave  tasks  of  a
              parallel   job   executes   is   in   unknown   state,   if  the
              reschedule_unknown parameter is activated.

       MAX_DYN_EC
              Sets the max number of dynamic event clients (as  used  by  qsub
              -sync  y and by Sun 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.

       MONITOR_TIME
              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
              generates  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
              seconds and 20 seconds.

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

       PROF_SIGNAL
              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
              messages file.

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

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

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

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

       PROF_TEVENT
              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
       profiling 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".

       STREE_SPOOL_INTERVAL
              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)

       MAX_JOB_DELETION_TIME
              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)

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

       gdi_retries
              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)

       cl_ping
              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)

       SCHEDULER_TIMEOUT
              Setting  this  parameter  allows   the   scheduler   GDI   event
              acknowledge  timeout  to  be  manually  configured to a specific
              value. Currently the  default  value  is  10  minutes  with  the
              default scheduler configuration and limited between 600 and 1200
              seconds. Value is limited only in case  of  default  value.  The
              default  value  depends  on the current scheduler configuration.
              The SCHEDULER_TIMEOUT value is specified in seconds.

       jsv_timeout
              This parameter measures the response time of the server JSV.  In
              the  event  that the response time of the JSV is longer than the
              timeout value specified, this will  cause  the  JSV  to  be  re-
              started.  The default value for the timeout is 10 seconds and if
              modified, must be greater than 0. If the timeout has been reach,
              the  JSV  will  only  try  to  re-start  once, if the timeout is
              reached again an error will occur.

       jsv_threshold
              The threshold of a JSV is measured  as  the  time  it  takes  to
              perform a server job verification. If this value is greater than
              the user defined value, it will cause logging to appear  in  the
              qmaster  messages  file at the INFO level. By setting this value
              to 0, all jobs will be logged in the qmaster messages file. This
              value  is  specified  in milliseconds and has a default value of
              5000.

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

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

   execd_params
       This  is  used for passing additional parameters to the Sun Grid Engine
       execution daemon. The following values are recognized:

       ACCT_RESERVED_USAGE
              If this parameter  is  set  to  true,  the   usage  of  reserved
              resources  is  used  for  the accounting entries cpu, mem and io
              instead of the measured usage.

       ENABLE_WINDOMACC
              If this parameter  is  set  to  true,  Windows  Domain  accounts
              (WinDomAcc)  are  used  on Windows hosts. These accounts require
              the use  of  sgepasswd(1)  (see  also  sgepasswd(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.

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

       PTF_MIN_PRIORITY, PTF_MAX_PRIORITY
              The maximum/minimum priority which Sun 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  nice(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
              predefined  default  value  on your hosts. The values are logged
              during the startup of the execution daemon.

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

       NOTIFY_KILL
              The  parameter  allows you to change the notification signal for
              the  signal  SIGKILL  (see  -notify  option  of  qsub(1)).   The
              parameter  either  accepts  signal  names  (use the -l option of
              kill(1))  or  the  special  value  none.  If  set  to  none,  no
              notification  signal  will  be  sent.  If it is set to TERM, for
              instance, or another signal name then this signal will  be  sent
              as notification signal.

       NOTIFY_SUSP
              With  this  parameter  it is possible to modify the notification
              signal  for  the  signal  SIGSTOP  (see  -notify  parameter   of
              qsub(1)).  The parameter either accepts signal names (use the -l
              option of kill(1)) or the special value none. If set to none, no
              notification  signal  will  be  sent.  If it is set to TSTP, for
              instance, or another signal name then this signal will  be  sent
              as notification signal.

       SHARETREE_RESERVED_USAGE
              Note: Deprecated, may be removed in future release.
              If  this  parameter  is  set  to  true,  the  usage  of reserved
              resources  is  taken  for  the  Sun  Grid  Engine   share   tree
              consumption instead of measured usage.
              Note:    When    running    tightly    integrated    jobs   with
              SHARETREE_RESERVED_USAGE set, and with having accounting_summary
              enabled in the parallel environment, reserved usage will only be
              reported by the  master  task  of  the  parallel  job.   No  per
              parallel  task usage records will be sent from execd to qmaster,
              which can significantly reduce  load  on  qmaster  when  running
              large tightly integrated parallel jobs.

       USE_QSUB_GID
              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
              passwd(5) file is used.
              The  feature  is  only available for jobs submitted via qsub(1),
              qrsh(1), qmake(1) and qtcsh(1).  Also, it only works for qrsh(1)
              jobs  (and  thus also for qtcsh(1) and qmake(1)) if rsh and rshd
              components are used which are  provided  with  Sun  Grid  Engine
              (i.e.,  the  rsh_daemon  and  rsh_command  parameters may not be
              changed from the default).

       S_DESCRIPTORS, H_DESCRIPTORS, S_MAXPROC, H_MAXPROC,

       S_MEMORYLOCKED, H_MEMORYLOCKED, S_LOCKS, H_LOCKS
              Specifies soft and hard resource limits as  implemented  by  the
              setrlimit(2)  system  call.  See this manual page on your system
              for more information. These  parameters  complete  the  list  of
              limits  set  by  the  RESOURCE  LIMITS  parameter  of  the queue
              configuration  as  described  in  queue_conf(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_DESCRIPTORS and H_DESCRIPTORS specify a value one greater than
              the  maximum  file  descriptor  number that can be opened by any
              process of a job.
              S_MAXPROC and H_MAXPROC specify the maximum number of  processes
              that can be created by the job user on this execution host
              S_MEMORYLOCKED  and H_MEMORYLOCKED specify the maximum number of
              bytes of virtual memory that may be locked into RAM.
              S_LOCKS and H_LOCKS specify the maximum number of file locks any
              process of a job may establish.
              All  of  these  values  can  be  specified  using the multiplier
              letters k, K, m, M, g and G, see sge_types(1) for details.

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

       SET_LIB_PATH
              This parameter tells the execution daemon whether to add the Sun
              Grid  Engine  shared  library  directory  to the library path of
              executed jobs.  If set to true, and INHERIT_ENV is also  set  to
              true,  the  Sun  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  Sun  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
              executed,  or  by  the job script itself.  The default value for
              SET_LIB_PATH is false.

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

       PDC_INTERVAL
              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 queue_conf(5)) and job usage  collection.
              The  parameter can be set to a time_specifier (see sge_types(5))
              , to PER_LOAD_REPORT or to NEVER.

       ENABLE_BINDING
              If this parameter is set then Sun Grid Engine enables  the  core
              binding  module  within  the  execution  daemon to apply binding
              parameters that are specified during submission time of  a  job.
              This  parameter is not set per default and therefore all binding
              related information will be ignored.  Find more information  for
              job to core binding in the section -binding of qsub(1).

       If this parameter is set to PER_LOAD_REPORT the PDC is triggered in the
       same interval as load_report_time (see above). If this parameter is set
       to NEVER the PDC run is never triggered. The default is 1 second.
       Note:  A PDC run is quite compute extensive may degrade the performance
       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  missing)  and  the  resource  limit
       enforcement  is  less  accurate or would not happen if PDC is turned of
       completely.

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

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

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

       accounting
              If  this  parameter  is  set  to  true,  the  accounting file is
              written.  The accounting file  is  prerequisite  for  using  the
              qacct command.

       reporting
              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
              consumables,  queue  status  and   consumables   and   sharetree
              configuration  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  reporting(5)  for
              further  information  about format and contents of the reporting
              file.

       flush_time
              Contents of the reporting file are  buffered  in  the  Sun  Grid
              Engine  qmaster  and flushed at a fixed interval.  This interval
              can  be  configured  with  the  flush_time  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.

       accounting_flush_time
              Contents of the accounting file are buffered  in  the  Sun  Grid
              Engine  qmaster  and flushed at a fixed interval.  This interval
              can be configured with the accounting_flush_time 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.
              Setting  it  to 00:00:00 will disable accounting data buffering;
              as soon as  data  is  generated,  it  will  be  written  to  the
              accounting  file.   If this parameter is not set, the accounting
              data flush interval will default to the value of the  flush_time
              parameter.

       joblog If  this  parameter  is  set  to  true,  the reporting file will
              contain job  logging  information.  See  reporting(5)  for  more
              information about job logging.

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

       log_consumables
              This parameter controls writing of consumable resources  to  the
              reporting  file.  When set to (log_consumables=true) information
              about all consumable resources (their current  usage  and  their
              capacity)  will  be  written  to  the reporting file, whenever a
              consumable  resource  changes  either  in  definition,   or   in
              capacity,  or  when  the usage of a consumable resource changes.
              When log_consumables is  set  to  false  (default),  only  those
              variables  will  be  written  to  the  reporting  file, that are
              configured  in   the   report_variables   in   the   exec   host
              configuration,  see  host_conf(5)  for further information about
              report_variables.

   finished_jobs
       Note: Deprecated, may be removed in future release.
       Sun Grid Engine stores a  certain  number  of  just  finished  jobs  to
       provide  post  mortem  status  information. The finished_jobs 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 finished_jobs will take immediate  effect.   The  default  for
       finished_jobs is 100.

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

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

       Changing qlogin_daemon will take immediate effect.  The  default  value
       for qlogin_daemon 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

   qlogin_command
       This is the command to be executed on the client side  of  a  qlogin(1)
       request.   Usually  this  is  the  builtin qlogin mechanism.  It's also
       possible 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 qlogin_command will take immediate effect.  The default  value
       for qlogin_command 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

   rlogin_daemon
       This parameter specifies the mechanism that is to  be  started  on  the
       server  side  of  a  qrsh(1)  request  without a command argument to be
       executed remotely.  Usually this is the builtin  mechanism.  It's  also
       possible to configure an external executable by specifying the absolute
       pathname, e.g. of the system's rlogin daemon.

       Changing rlogin_daemon will take  immediate  effect.  The  default  for
       rlogin_daemon 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
       qlogin_daemon.

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

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

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

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

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

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

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

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

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

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

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

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

   delegated_file_staging
       This  flag  must  be set to "true" when the prolog and epilog are ready
       for   delegated   file   staging,   so   that   the   DRMAA   attribute
       'drmaa_transfer_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).

   reprioritize
       Note: Deprecated, may be removed in future release.
       This  flag  enables  or  disables the reprioritization of jobs based on
       their ticket amount. The reprioritize_interval in  sched_conf(5)  takes
       effect   only  if  reprioritize  is  set  to  true.  To  turn  off  job
       reprioritization, the reprioritize flag must be set to  false  and  the
       reprioritize_interval to 0 which is the default.

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

   jsv_url
       This setting defines a server JSV instance which will  be  started  and
       triggered by the sge_qmaster(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
       configurations.

       Find more details concerning JSV in jsv(1) and sge_request(1).

       The syntax of the jsv_url is specified in sge_types(1).

   jsv_allowed_mod
       If  there  is  a server JSV script defined with jsv_url parameter, then
       all qalter(1) or qmon(1) modification requests for jobs are rejected by
       qmaster.  With  the  jsv_allowed_mod 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   qsub(1)  or  the  value  none  to  indicate  that  no
       modification should be allowed.  Please  note  that  even  if  none  is
       specified the switches -w and -t are allowed for qalter.

   libjvm_path
       libjvm_path  is  usually  set during qmaster installation and points to
       the  absolute  path  of  libjvm.so.   (or  the  corresponding   library
       depending        on        your        architecture        -       e.g.
       /usr/java/jre/lib/i386/server/libjvm.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
       additional_jvm_args. If the jvm thread is started at all can be defined
       in the bootstrap(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.

   additional_jvm_args
       additional_jvm_args  is  usually  set  during   qmaster   installation.
       Details  about  possible values additional_jvm_args 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.

SEE ALSO

       sge_intro(1),  csh(1),  qconf(1),  qsub(1),  jsv(1),   rsh(1),   sh(1),
       getpwnam(3),    drmaa_attributes(3),    queue_conf(5),   sched_conf(5),
       sge_types(1), sge_execd(8), sge_qmaster(8),  sge_shepherd(8),  cron(8),
       Sun Grid Engine Installation and Administration Guide.

COPYRIGHT

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