    NAME
         host_conf - Grid Engine execution  host  configuration  file
         format

    DESCRIPTION
         Host_conf reflects the format of the template file  for  the
         execution  host  configuration.  Via the -ae and -me options
         of the qconf(1) command, you can  add  execution  hosts  and
         modify  the configuration of any execution host in the clus-
         ter. Default execution host entries are added  automatically
         as  soon  as  a sge_execd(8) registers to sge_qmaster(8) for
         the very first time from a certain host. The  qconf(1)  -sel
         switch can be used to display a list of execution host being
         currently configured in your Grid Engine system. Via the -se
         option  you  can print the execution host configuration of a
         specified host.

         The special hostname "global" can be used to define  cluster
         global characteristics.

    FORMAT
         The format of a host_conf file is defined as follows:

         hostname
              The name of the execution host.

         load_scaling
              A comma separated list of scaling values to be  applied
              to  each  or  part of the load values being reported by
              the sge_execd(8) on the host and being defined  in  the
              cluster  global  "host"  complex (see complex(5)).  The
              load scaling factors are intended to level hardware  or
              operating system specific differences between execution
              hosts.  If,  for  example,  the  load   average   value
              (load_avg in the "host" complex; see also uptime(1)) of
              a multiprocessor machine is to be compared with a  sin-
              gle  processor machine the load as reported by the sin-
              gle CPU host needs to be weighted up against  the  mul-
              tiprocessor  load  (given  the same CPU hardware) to be
              comparable. The load scaling factors are integers being
              multiplied with the reported load quantities to consti-
              tute weighted load values. Thus, following the  example
              given  above,  the  load  value of the single processor
              machine needs to be multiplied by the number of proces-
              sors  of the single processor machine to become compar-
              able.

              The syntax of a load factor specification  is  as  fol-
              lows:  First  the name of the load value (as defined in
              the "host" complex) is given and, separated by an equal
              sign, the load scaling value is provided. No blanks are
              allowed in between the load_scaling value string.
              The parameter load_scaling is not  meaningful  for  the
              definition of the "global" host.

         complex_values
              complex_values defines quotas for  resource  attributes
              managed  via  this host. Each complex attribute is fol-
              lowed by an "=" sign and the value  specification  com-
              pliant  with  the  complex  attribute  type  (see  com-
              plex(5)).  Quota specifications are separated  by  com-
              mas.

              The quotas are related to the resource  consumption  of
              all  jobs on a host in the case of consumable resources
              (see complex(5) for details on consumable resources) or
              they  are  interpreted  on  a per job slot basis in the
              case of non-consumable resources.  Consumable  resource
              attributes  are  commonly  used  to manage free memory,
              free disk space or available floating software licenses
              while non-consumable attributes usually define distinc-
              tive characteristics like type of hardware installed.

              For  consumable  resource   attributes   an   available
              resource   amount  is  determined  by  subtracting  the
              current resource consumption of all running jobs on the
              host  from  the  quota in the complex_values list. Jobs
              can only  be  dispatched  to  a  host  if  no  resource
              requests exceed any corresponding resource availability
              obtained by this scheme. The quota  definition  in  the
              complex_values  list  is  automatically replaced by the
              current load value reported for this attribute, if load
              is monitored for this resource and if the reported load
              value is more stringent than  the  quota.  This  effec-
              tively avoids oversubscription of resources.

              Note: Load values replacing  the  quota  specifications
              may  have  become more stringent because they have been
              scaled (see load_scaling above)  and/or  load  adjusted
              (see sched_conf(5)).  The -F option of qstat(1) and the
              load  display  in  the  qmon(1)  queue  control  dialog
              (activated  by  clicking  on  a  queue  icon  while the
              "Shift" key is pressed) provide detailed information on
              the  actual availability of consumable resources and on
              the origin of the values taken into account currently.

              Note also: The resource  consumption  of  running  jobs
              (used  for the availability calculation) as well as the
              resource requests of the jobs waiting to be  dispatched
              either  may be derived from explicit user requests dur-
              ing job submission (see the -l option  to  qsub(1))  or
              from  a  "default" value configured for an attribute by
              the administrator (see complex(5)).  The -r  option  to
              qstat(1)  can be used for retrieving full detail on the
              actual resource requests of all jobs in the system.

              For non-consumable resources Grid  Engine  simply  com-
              pares the job's attribute requests with the correspond-
              ing specification in complex_values taking the relation
              operator  of  the  complex  attribute  definition  into
              account (see complex(5)).  If the result  of  the  com-
              parison  is  "true",  the  host is suitable for the job
              with respect to the particular attribute. For  parallel
              jobs each job slot to be occupied by a parallel task is
              meant to provide the same resource attribute value.

              Note: Only numeric complex attributes can be defined as
              consumable  resources  and hence non-numeric attributes
              are always handled on a per job slot basis.

              The default value for this parameter is NONE,  i.e.  no
              administrator  defined  resource  attribute  quotas are
              associated with the host.

         load_values
              This entry cannot be configured but is  only  displayed
              in  case of a qconf(1) -se command. All load values are
              displayed as reported by the sge_execd(8) on the  host.
              The load values are enlisted in a comma separated list.
              Each load value start with its  name,  followed  by  an
              equal sign and the reported value.

         processors
              This entry cannot be configured but is  only  displayed
              in  case  of  a  qconf(1) -se command. Its value is the
              number  of  processors  which  has  been  detected   by
              sge_execd(8) on the corresponding host.

         usage_scaling
              The format is equivalent to load_scaling  (see  above),
              the  only valid attributes to be scaled however are cpu
              for CPU time consumption, mem  for  Memory  consumption
              aggregated  over  the life-time of jobs and io for data
              transferred via any I/O devices. The default NONE means
              "no scaling", i.e. all scaling factors are 1.

         user_lists
              The user_lists parameter  contains  a  comma  separated
              list  of  so  called  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 host. If
              the user_lists parameter is set to NONE  (the  default)
              any  user  has access being 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 host.

         xuser_lists
              The xuser_lists parameter contains  a  comma  separated
              list  of  so  called  user access lists as described in
              access_list(5).  Each user contained in at least one of
              the  enlisted access lists is not allowed to access the
              host. 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 the user is denied access to the host.

         projects
              The projects parameter contains a comma separated  list
              of  projects that have access to the host. Any projects
              not in this list are denied access to the host. If  set
              to  NONE  (the default), any project has access that is
              not specifically excluded via the  xprojects  parameter
              described  below.  If a project is in both the projects
              and xprojects parameters, the project is denied  access
              to the host.

         xprojects
              The xprojects parameter contains a comma separated list
              of  projects that are denied access to the host. If set
              to NONE (the default), no projects  are  denied  access
              other  than  those  denied access based on the projects
              parameter described above.  If a project is in both the
              projects  and  xprojects  parameters,  the  project  is
              denied access to the host.

         report_variables
              The  report_variables  parameter   contains   a   comma
              separated  list  of  variables that shall be written to
              the reporting file.  The variables listed here will  be
              written  to  the  reporting  file  when  a  load report
              arrives from an execution host.

              Default settings can be done in the global  host.  Host
              specific  settings  for report_variables will overwrite
              settings from the global host.

    SEE ALSO
         sge_intro(1),  qconf(1),  uptime(1),  access_list(5),   com-
         plex(5), sge_execd(8), sge_qmater(8).

    COPYRIGHT
         See sge_intro(1) for a full statement of rights and  permis-
         sions.