File: submit.html

package info (click to toggle)
gridengine 6.2u5-7.1
links: PTS, VCS
area: main
in suites: wheezy
size: 57,216 kB
sloc: ansic: 438,030; java: 66,252; sh: 36,399; jsp: 7,757; xml: 5,850; makefile: 5,520; csh: 4,571; cpp: 2,848; perl: 2,401; tcl: 692; lisp: 669; yacc: 668; ruby: 642; lex: 344
file content (2147 lines) | stat: -rw-r--r-- 110,041 bytes
parent folder | download | duplicates (14)
<HTML>
<BODY BGCOLOR=white>
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->
NAME
     qsub   -  submit a batch job to Sun Grid Engine.

     qsh    -  submit an interactive  X-windows  session  to  Sun
               Grid Engine.

     qlogin -  submit an interactive login session  to  Sun  Grid
               Engine.

     qrsh   -  submit an interactive  rsh  session  to  Sun  Grid
               Engine.

     qalter -  modify a pending or running batch job of Sun  Grid
               Engine.

     qresub -  submit a copy of an existing Sun Grid Engine job.

SYNTAX
     qsub [ options ] [ command | -- [ command_args ]]

     qsh [ options ] [ -- xterm_args ]

     qlogin [ options ]

     qrsh [ options ] [ command [ command_args ]]

     qalter [ options ] wc_job_range_list [ -- [ command_args ]]

     qalter [ options ] -u user_list | -uall [ -- [  command_args
     ]]

     qresub [ options ] job_id_list

DESCRIPTION
     <I>Qsub</I> submits batch jobs to the Sun Grid Engine queuing  sys-
     tem.  Sun  Grid  Engine  supports  single- and multiple-node
     jobs. Command can be a path to a binary or a script (see  -b
     below)  which  contains  the  commands  to be run by the job
     using a shell (for example, <B><A HREF="../htmlman1/sh.html?pathrev=V62u5_TAG">sh(1)</A></B> or <B><A HREF="../htmlman1/csh.html?pathrev=V62u5_TAG">csh(1)</A></B>).  Arguments  to
     the  command  are given as command_args to <I>qsub</I> . If command
     is handled as a script then it is possible to embed flags in
     the  script.   If  the first two characters of a script line
     either match '#$' or are equal to the prefix string  defined
     with  the  -C option described below, the line is parsed for
     embedded command flags.

     <I>Qsh</I> submits an interactive X-windows  session  to  Sun  Grid
     Engine. An <B><A HREF="../htmlman1/xterm.html?pathrev=V62u5_TAG">xterm(1)</A></B> is brought up from the executing machine
     with the display directed either to the  X-server  indicated
     by the DISPLAY environment variable or as specified with the
     -<I>display</I> <I>qsh</I> option. Interactive jobs are not spooled if  no
     resource  is  available  to  execute  them.  They are either
     dispatched to a suitable machine for  execution  immediately
     or  the  user  submitting  the  job  is notified by <I>qsh</I> that
     appropriate resources to execute the job are not  available.
     xterm_args  are  passed  to  the <B><A HREF="../htmlman1/xterm.html?pathrev=V62u5_TAG">xterm(1)</A></B> executable.  Note,
     however, that the -<I>e</I> and -<I>ls</I> xterm options do not work  with
     <I>qsh</I> .

     <I>Qlogin</I> is similar to <I>qsh</I> in that it submits  an  interactive
     job to the queuing system. It does not open an <B><A HREF="../htmlman1/xterm.html?pathrev=V62u5_TAG">xterm(1)</A></B> win-
     dow on the X display, but uses the current terminal for user
     I/O. Usually, <I>qlogin</I> establishes a <B><A HREF="../htmlman1/telnet.html?pathrev=V62u5_TAG">telnet(1)</A></B> connection with
     the remote host, using standard client- and server-side com-
     mands.   These   commands   can   be   configured  with  the
     qlogin_daemon (server-side, Sun Grid Engine <I>telnetd</I>  if  not
     set,  otherwise  something  like  /usr/sbin/in.telnetd)  and
     qlogin_command (client-side, Sun Grid Engine <I>telnet</I>  if  not
     set, otherwise something like /usr/bin/telnet) parameters in
     the global and local configuration settings of  <B><A HREF="../htmlman5/sge_conf.html?pathrev=V62u5_TAG">sge_conf(5)</A></B>.
     The  client side command is automatically parameterized with
     the remote host name and port number to  which  to  connect,
     resulting in an invocation like

          /usr/bin/telnet my_exec_host 2442

     for example.  <I>Qlogin</I> is invoked exactly  like  <I>qsh</I>  and  its
     jobs  can  only  run on INTERACTIVE queues.  <I>Qlogin</I> jobs can
     only be used if the <B><A HREF="../htmlman8/sge_execd.html?pathrev=V62u5_TAG">sge_execd(8)</A></B> is running under  the  root
     account.

     <I>Qrsh</I> is similar to <I>qlogin</I> in that it submits an  interactive
     job  to the queuing system. It uses the current terminal for
     user I/O. Usually, <I>qrsh</I> establishes a <B><A HREF="../htmlman1/rsh.html?pathrev=V62u5_TAG">rsh(1)</A></B> connection with
     the  remote  host.  If  no command is given to <I>qrsh</I>, an <I>rlo-</I>
     <B><A HREF="../htmlman1/gin.html?pathrev=V62u5_TAG">gin(1)</A></B> session is  established.   The  server-side  commands
     used can be configured with the rsh_daemon and rlogin_daemon
     parameters in the global and local configuration settings of
     <B><A HREF="../htmlman5/sge_conf.html?pathrev=V62u5_TAG">sge_conf(5)</A></B>.   An Sun Grid Engine <I>rshd</I> or <I>rlogind</I> is used if
     the parameters are not set. If the parameters are set,  they
     should   be  set  to  something  like  /usr/sbin/in.rshd  or
     /usr/sbin/in.rlogind.  On the client-side,  the  rsh_command
     and  rlogin_command  parameters can be set in the global and
     local configuration settings of <B><A HREF="../htmlman5/sge_conf.html?pathrev=V62u5_TAG">sge_conf(5)</A></B>.   If  they  are
     not  set,  special  Sun  Grid  Engine  <B><A HREF="../htmlman1/rsh.html?pathrev=V62u5_TAG">rsh(1)</A></B>  and <B><A HREF="../htmlman1/rlogin.html?pathrev=V62u5_TAG">rlogin(1)</A></B>
     binaries delivered with Sun Grid Engine are used.   Use  the
     cluster  configuration  parameters  to  integrate mechanisms
     like <I>ssh</I> or the <B><A HREF="../htmlman1/rsh.html?pathrev=V62u5_TAG">rsh(1)</A></B>  and  <B><A HREF="../htmlman1/rlogin.html?pathrev=V62u5_TAG">rlogin(1)</A></B>  facilities  supplied
     with the operating system.

     <I>Qrsh</I> jobs can only run  in  INTERACTIVE  queues  unless  the
     option  -now  no is used (see below).  They can also only be
     run, if the <B><A HREF="../htmlman8/sge_execd.html?pathrev=V62u5_TAG">sge_execd(8)</A></B> is running under the root account.

     <I>Qrsh</I> provides an additional useful feature  for  integrating
     with  interactive  tools providing a specific command shell.
     If the environment variable QRSH_WRAPPER is set when <I>qrsh</I> is
     invoked,  the command interpreter pointed to by QRSH_WRAPPER
     will be executed to run <I>qrsh</I> commands instead of  the  users
     login shell or any shell specified in the <I>qrsh</I> command-line.
     The options -cwd,  -v,  -V,   and  -display  only  apply  to
     batch jobs.

     <I>Qalter</I> can be used to change the attributes of pending jobs.
     For  array jobs with a mix of running and pending tasks (see
     the -t option below), modification with <I>qalter</I> only  affects
     the  pending  tasks.   <I>Qalter</I> can change most of the charac-
     teristics of a job (see the corresponding statements in  the
     OPTIONS  section  below), including those which were defined
     as embedded flags in the script file (see above).  Some sub-
     mit  options, such as the job script, cannot be changed with
     I. qalter.

     <I>Qresub</I> allows the user to create jobs as copies of  existing
     pending  or  running jobs. The copied jobs will have exactly
     the same attributes as the ones from which they were copied,
     except  with a new job ID and with a cleared hold state. The
     only modification to the copied jobs supported by <I>qresub</I>  is
     assignment  of  a  new  hold  state with the -h option. This
     option can be used to first copy a job and then  change  its
     attributes via <I>qalter</I>.

     Only a manager can use <I>qresub</I> on jobs submitted  by  another
     user.  Regular users can only use <I>qresub</I> on their own jobs.

     For <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, and <I>qlogin</I> the  administrator  and  the
     user  may  define default request files (see <B><A HREF="../htmlman5/sge_request.html?pathrev=V62u5_TAG">sge_request(5)</A></B>)
     which can contain any of the options described below.  If an
     option  in  a default request file is understood by <I>qsub</I> and
     <I>qlogin</I> but not by <I>qsh</I> the option is silently ignored if  <I>qsh</I>
     is  invoked.  Thus  you  can maintain shared default request
     files for both <I>qsub</I> and <I>qsh</I>.

     A cluster wide default request  file  may  be  placed  under
     $SGE_ROOT/$SGE_CELL/common/sge_request.      User    private
     default request files  are  processed  under  the  locations
     $HOME/.sge_request and $cwd/.sge_request. The working direc-
     tory local default request file has the highest  precedence,
     then  the  home  directory located file and then the cluster
     global file.  The  option  arguments,  the  embedded  script
     flags  and the options in the default request files are pro-
     cessed in the following order:

          left to right in the script line,
          left to right in the default request files,
          from top to bottom of the script file (<I>qsub</I> only),
          from top to bottom of default request files,
          from left to right of the command line.

     In other words, the command line can be used to override the
     embedded flags and the default request settings.  The embed-
     ded flags, however, will override the default settings.

     Note, that the -<I>clear</I> option can be used to discard any pre-
     vious settings at any time in a default request file, in the
     embedded script flags, or in a command-line option.  It  is,
     however, not available with <I>qalter</I>.

     The options described below can be requested either hard  or
     soft.   By  default,  all requests are considered hard until
     the -soft option (see below) is encountered.  The  hard/soft
     status  remains  in  effect until its counterpart is encoun-
     tered again.  If all the hard requests for a job  cannot  be
     met,  the  job  will not be scheduled.  Jobs which cannot be
     run at the present time remain spooled.

OPTIONS
     -@ optionfile
          Forces <I>qsub</I>, <I>qrsh</I>, <I>qsh</I>, or <I>qlogin</I> to  use  the  options
          contained in optionfile. The indicated file may contain
          all valid options. Comment lines must start with a  "#"
          sign.

     -a date_time
          Available for <I>qsub</I> and <I>qalter</I> only.

          Defines or redefines the time and date at which  a  job
          is   eligible  for  execution.  Date_time  conforms  to
          [[CC]]YY]MMDDhhmm[.SS], for  the  details,  please  see
          Date_time in:  <B><A HREF="../htmlman1/sge_types.html?pathrev=V62u5_TAG">sge_types(1)</A></B>.

          If this option is used with <I>qsub</I> or if a  corresponding
          value is specified in <I>qmon</I> then a parameter named a and
          the value in the format CCYYMMDDhhmm.SS will be  passed
          to  the defined JSV instances (see -jsv option below or
          find more information concerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -ac variable[=value],...
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          Adds the given name/value pair(s) to the job's context.
          Value may be omitted. Sun Grid Engine appends the given
          argument to the list of context variables for the  job.
          Multiple  -ac,  -dc, and -sc options may be given.  The
          order is important here.

          The outcome of the evaluation of all -ac, -dc, and  -sc
          options  or  corresponding  values in <I>qmon</I> is passed to
          defined JSV instances as parameter with  the  name  ac.
          (see  -jsv  option  below or find more information con-
          cerning JSV in  <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)  <I>QALTER</I>  allows  changing  this
          option even while the job executes.

     -ar ar_id
          Available for <I>qsub</I>, <I>qalter</I>, <I>qrsh</I>, <I>qsh</I>, or <I>qlogin</I> only.

          Assigns the submitted job to be a part of  an  existing
          Advance  Reservation.  The  complete  list  of existing
          Advance  Reservations  can  be   obtained   using   the
          <B><A HREF="../htmlman1/qrstat.html?pathrev=V62u5_TAG">qrstat(1)</A></B> command.

          Note that the -ar  option  adds  implicitly  the  -w  e
          option if not otherwise requested.

          <I>Qalter</I> allows changing this option even while  the  job
          executes. The modified parameter will only be in effect
          after a restart or migration of the job however.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified then this value will be passed to defined JSV
          instances as parameter with  the  name  ar.  (see  -jsv
          option below or find more information concerning JSV in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -A account_string
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          Identifies the account to which the  resource  consump-
          tion  of  the job should be charged. The account_string
          should conform to the name definition in M sge_types  1
          .   In  the  absence  of this parameter Sun Grid Engine
          will place the default  account  string  "sge"  in  the
          accounting record of the job.

          <I>Qalter</I> allows changing this option even while  the  job
          executes.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified then this value will be passed to defined JSV
          instances as parameter with  the  name  A.   (see  -jsv
          option below or find more information concerning JSV in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -binding [ binding_instance ] binding_strategy
          A job can request a  specific  processor  core  binding
          (processor  affinity) with this parameter. This request
          is neither a hard nor a soft request, it is a hint  for
          the execution host to do this if possible.  Please note
          that the requested binding strategy  is  not  used  for
          resource   selection   within   Sun  Grid Engine.  As a
          result an execution host might be  selected  where  Sun
          Grid  Engine  does  not even know the hardware topology
          and therefore is not able to apply the requested  bind-
          ing.

          To enforce Sun Grid Engine to select hardware on  which
          the  binding can be applied please use the -l switch in
          combination with the complex attribute m_topology.

          binding_instance is an  optional  parameter.  It  might
          either  be  env,  pe or set depending on which instance
          should accomplish the job to core binding. If the value
          for  binding_instance is not specified then set will be
          used.

          env means that  the  environment  variable  SGE_BINDING
          will  be  exported  to  the job environment of the job.
          This variable contains the  selected  operating  system
          internal  processor  numbers.   They might be more than
          selected cores in presence of SMT or CMT  because  each
          core  could  be represented by multiple processor iden-
          tifiers.  The processor numbers are space separated.

          pe means that the information about the selected  cores
          appears  in  the fourth column of the pe_hostfile. Here
          the logical core and socket numbers are  printed  (they
          start  at 0 and have no holes) in colon separated pairs
          (i.e. 0,0:1,0 which means core 0 on socket 0 and core 0
          on   socket   1).    For  more  information  about  the
          $pe_hostfile check <B><A HREF="../htmlman5/sge_pe.html?pathrev=V62u5_TAG">sge_pe(5)</A></B>

          set (default if nothing else is specified). The binding
          strategy  is  applied  by  Sun Grid Engine. How this is
          achieved depends on the underlying  hardware  architec-
          ture of the execution host where the submitted job will
          be started.

          On Solaris 10 hosts a processor  set  will  be  created
          where  the  job  can  exclusively  run  in.  Because of
          operating system limitations at  least  one  core  must
          remain  unbound.  This resource could of course used by
          an unbound job.

          On Linux hosts a processor affinity mask will be set to
          restrict   the  job  to run exclusively on the selected
          cores.   The  operating  system  allows  other  unbound
          processes  to  use  these  cores.   Please note that on
          Linux the binding requires a Linux  kernel  version  of
          2.6.16  or  greater. It might be even possible to use a
          kernel with lower version number but in that case addi-
          tional kernel patches have to be applied. The loadcheck
          tool in the utilbin directory can be used to  check  if
          the  hosts  capabilities.  You can also use the -sep in
          combination with -cb of <B><A HREF="../htmlman5/qconf.html?pathrev=V62u5_TAG">qconf(5)</A></B> command to identify if
          Sun  Grid  Engine  is  able  to  recognize the hardware
          topology.

          Possible values for binding_strategy are as follows:

              linear:&lt;amount&gt;[:&lt;socket&gt;,&lt;core&gt;]
              striding:&lt;amount&gt;:&lt;n&gt;[:&lt;socket&gt;,&lt;core&gt;]
              explicit:[&lt;socket&gt;,&lt;core&gt;;...]&lt;socket&gt;,&lt;core&gt;

          For the binding strategy linear and striding  there  is
          an  optional  socket  and  core  pair  attached.  These
          denotes the mandatory starting point for the first core
          to bind on.

          linear means that Sun Grid Engine tries to bind the job
          on amount successive cores. If socket and core is omit-
          ted then Sun Grid  Engine  first  allocates  successive
          cores  on  the  first  empty socket found.  Empty means
          that there are no jobs bound to the socket by Sun  Grid
          Engine.   If this is not  possible or is not sufficient
          Sun Grid Engine tries to find (further)  cores  on  the
          socket  with  the most unbound cores and so on.  If the
          amount of  allocated  cores  is  lower  than  requested
          cores,  no  binding  is done for the job. If socket and
          core is specified then Sun Grid Engine  tries  to  find
          amount  of  empty  cores  beginning  with this starting
          point. If this is not  possible  then  binding  is  not
          done.

          striding means that Sun Grid Engine tries to find cores
          with  a certain offset.  It will select amount of empty
          cores with a offset of n -1  cores  in  between.  Start
          point  for  the search algorithm is socket 0 core 0. As
          soon as amount cores are found they will be used to  do
          the  job  binding.  If there are not enough empty cores
          or if correct offset cannot be achieved then there will
          be no binding done.

          explicit binds the specified sockets and cores that are
          mentioned   in  the  provided  socket/core  list.  Each
          socket/core pair has to be specified only  once.  If  a
          socket/core  pair  is already in use by a different job
          the whole binding request will be ignored.

          Qalter allows changing this option even while  the  job
          executes. The modified parameter will only be in effect
          after a restart or migration of the job, however.

          If this option or a  corresponding  value  in  qmon  is
          specified  then  these values will be passed to defined
          JSV   instances   as   parameters   with   the    names
          binding_strategy,     binding_type,     binding_amount,
          binding_step,       binding_socket,       binding_core,
          binding_exp_n,                  binding_exp_socket&lt;id&gt;,
          binding_exp_core&lt;id&gt;.

          Please note that the length of  the  socket/core  value
          list   of   the   explicit   binding   is  reported  as
          binding_exp_n. &lt;id&gt; will be replaced by the position of
          the  socket/core pair within the explicit list (0 &lt;= id
          &lt; binding_exp_n). The first  socket/core  pair  of  the
          explicit  binding  will  be reported with the parameter
          names binding_exp_socket0 and binding_exp_core0.

          Values that do not apply for the specified binding will
          not be reported to JSV.  E.g. binding_step will only be
          reported for the striding binding and all binding_exp_*
          values  will  passed  to  JSV  if  explicit binding was
          specified. (see -jsv  option  below or find more infor-
          mation concerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -b y[es]|n[o]
          Available for <I>qsub</I>, <I>qrsh</I> only. <I>Qalter</I>  does  not  allow
          changing this option. This option cannot be embedded in
          the script file itself.

          Gives the user the possibility to  indicate  explicitly
          whether  command should be treated as binary or script.
          If the value of -b is  'y',  then  command   may  be  a
          binary  or script.  The command might not be accessible
          from the submission host.  Nothing except the  path  of
          the  command  will  be  transferred from the submission
          host to the  execution  host.  Path  aliasing  will  be
          applied  to  the path of command before command will be
          executed.

          If the value of -b is 'n' then command needs  to  be  a
          script  and  it  will  be handled as script. The script
          file has to be accessible by the  submission  host.  It
          will  be  transferred  to the execution host. <I>qsub</I>/<I>qrsh</I>
          will search directive prefixes within script.

          <I>qsub</I> will implicitly use -b n whereas <I>qrsh</I>  will  apply
          the -b y option if nothing else is specified.

          The value specified with this option or the correspond-
          ing  value  specified  in  <I>qmon</I>  will only be passed to
          defined JSV instances if the value is <I>yes</I>.  The name of
          the  parameter will be b. The value will be y also when
          then long form yes  was  specified  during  submission.
          (see  -jsv  option  below or find more information con-
          cerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)
          Please note that submission of command as script (-b n)
          can  have  a significant performance impact, especially
          for short running jobs and  big  job  scripts.   Script
          submission  adds  a number of operations to the submis-
          sion process:  The job script needs to be
          - parsed at client side (for special comments)
          - transferred from submit client to qmaster
          - spooled in qmaster
          - transferred to execd at job execution
          - spooled in execd
          - removed from spooling both in execd and qmaster once the job is done
          If job scripts are available on  the  execution  nodes,
          e.g.  via  NFS,  binary  submission  can  be the better
          choice.

     -c occasion_specifier
          Available for <I>qsub</I> and <I>qalter</I> only.

          Defines or redefines whether the job should  be  check-
          pointed,  and  if  so,  under  what  circumstances. The
          specification of the checkpointing occasions with  this
          option overwrites the definitions of the <I>when</I> parameter
          in the checkpointing  environment  (see  <B><A HREF="../htmlman5/checkpoint.html?pathrev=V62u5_TAG">checkpoint(5)</A></B>)
          referenced  by  the <I>qsub</I> -<I>ckpt</I> switch.  Possible values
          for occasion_specifier are

          n           no checkpoint is performed.
          s           checkpoint when batch server is shut down.
          m           checkpoint at minimum CPU interval.
          x           checkpoint when job gets suspended.
          &lt;interval&gt;  checkpoint in the specified time interval.

          The minimum CPU interval is defined in the queue confi-
          guration  (see  <B><A HREF="../htmlman5/queue_conf.html?pathrev=V62u5_TAG">queue_conf(5)</A></B> for details).  &lt;interval&gt;
          has to be specified in the format hh:mm:ss.   The  max-
          imum of &lt;interval&gt; and the queue's minimum CPU interval
          is used if &lt;interval&gt; is specified.  This  is  done  to
          ensure  that a machine is not overloaded by checkpoints
          being generated too frequently.

          The value specified with this option or the correspond-
          ing  value  specified in <I>qmon</I> will be passed to defined
          JSV instances.  The &lt;interval&gt;  will  be  available  as
          parameter  with  the  name  c_interval.   The character
          sequence specified will be available as parameter  with
          the  name  c_occasion.  Please  note that if you change
          c_occasion via JSV then the last setting of  c_interval
          will  be  overwritten and vice versa.  (see -jsv option
          below  or  find  more  information  concerning  JSV  in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)


     -ckpt ckpt_name
          Available for <I>qsub</I> and <I>qalter</I> only.

          Selects  the  checkpointing  environment  (see   <I>check-</I>
          <B><A HREF="../htmlman5/point.html?pathrev=V62u5_TAG">point(5)</A></B>)  to  be  used for checkpointing the job. Also
          declares the job to be a checkpointing job.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified then this value will be passed to defined JSV
          instances as parameter with the name ckpt.   (see  -jsv
          option below or find more information concerning JSV in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -clear
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, and <I>qlogin</I> only.

          Causes all elements of the job to be reset to the  ini-
          tial default status prior to applying any modifications
          (if any) appearing in this specific command.

     -cwd Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I> and <I>qalter</I> only.

          Execute the job from  the  current  working  directory.
          This switch will activate Sun Grid Engine's path alias-
          ing facility, if the corresponding configuration  files
          are present (see <B><A HREF="../htmlman5/sge_aliases.html?pathrev=V62u5_TAG">sge_aliases(5)</A></B>).

          In the case of <I>qalter</I>, the previous definition  of  the
          current working directory will be overwritten if <I>qalter</I>
          is executed from a different directory than the preced-
          ing <I>qsub</I> or <I>qalter</I>.

          <I>Qalter</I> allows changing this option even while  the  job
          executes. The modified parameter will only be in effect
          after a restart or migration of the job, however.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified then this value will be passed to defined JSV
          instances as parameter with the name cwd. The value  of
          this parameter will be the absolute path to the current
          working directory. JSV scripts can remove the path from
          jobs  during  the  verification  process by setting the
          value of this parameter to an empty string. As a result
          the job behaves as if -cwd was not specified during job
          submission.  (see -jsv option below or find more infor-
          mation concerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)


     -C prefix_string
          Available for <I>qsub</I> and <I>qrsh</I> with script submission  (-b
          n).

          <I>Prefix</I>_<I>string</I> defines the prefix that declares a direc-
          tive  in  the  job's  command.  The prefix is not a job
          attribute, but affects the behavior of <I>qsub</I>  and  <I>qrsh</I>.
          If  prefix  is  a  null string, the command will not be
          scanned for embedded directives.
          The directive prefix consists of two  ASCII  characters
          which,  when  appearing  in  the  first  two bytes of a
          script line, indicate that what follows is an Sun  Grid
          Engine command.  The default is "#$".
          The user should be aware that changing the first delim-
          iting character can produce unforeseen side effects. If
          the script file contains  anything  other  than  a  "#"
          character  in  the first byte position of the line, the
          shell processor for the job will reject  the  line  and
          may exit the job prematurely.
          If the -C option is present in the script file,  it  is
          ignored.

     -dc variable,...
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          Removes the given variable(s) from the  job's  context.
          Multiple  -ac,  -dc, and -sc options may be given.  The
          order is important.

          <I>Qalter</I> allows changing this option even while  the  job
          executes.

          The outcome of the evaluation of all -ac, -dc, and  -sc
          options  or  corresponding  values in <I>qmon</I> is passed to
          defined JSV instances as parameter with  the  name  ac.
          (see  -jsv  option  below or find more information con-
          cerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -display display_specifier
          Available for <I>qsh</I> and <I>qrsh</I>.

          Directs <B><A HREF="../htmlman1/xterm.html?pathrev=V62u5_TAG">xterm(1)</A></B> to use display_specifier in  order  to
          contact  the  X  server.   The display_specifier has to
          contain the hostname part of  the  display  name  (e.g.
          myhost:1). Local display names (e.g. :0) cannot be used
          in grid environments.  Values  set  with  the  -display
          option  overwrite settings from the submission environ-
          ment and from -v command line options.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified then this value will be passed to defined JSV
          instances as parameter  with  the  name  display.  This
          value  will  also  be  available in the job environment
          which might optionally be passed to  JSV  scripts.  The
          variable  name will be DISPLAY.  (see -jsv option below
          or find more information concerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -dl date_time
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          Specifies   the    deadline    initiation    time    in
          [[CC]YY]MMDDhhmm[.SS] format (see -a option above). The
          deadline initiation time is the time at which  a  dead-
          line  job  has to reach top priority to be able to com-
          plete within a given deadline. Before the deadline ini-
          tiation  time  the  priority  of a deadline job will be
          raised steadily until it reaches the maximum as config-
          ured by the Sun Grid Engine administrator.

          This option is applicable only  for  users  allowed  to
          submit deadline jobs.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified then this value will be passed to defined JSV
          instances as parameter with the name dl. The format for
          the date_time value is CCYYMMDDhhmm.SS (see -jsv option
          below  or  find  more  information  concerning  JSV  in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)


     -e [[hostname]:]path,...
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          Defines or redefines the path  used  for  the  standard
          error  stream of the job. For <I>qsh</I>, <I>qrsh</I> and <I>qlogin</I> only
          the standard error  stream  of  prolog  and  epilog  is
          redirected.   If  the path constitutes an absolute path
          name, the error-path attribute of the  job  is  set  to
          path, including the hostname. If the path name is rela-
          tive, Sun Grid Engine  expands  path  either  with  the
          current working directory path (if the -cwd switch (see
          above) is also specified) or with  the  home  directory
          path. If hostname is present, the standard error stream
          will be placed in the corresponding  location  only  if
          the  job  runs  on the specified host. If the path con-
          tains a ":" without a hostname, a leading ":" has to be
          specified.

          By default  the  file  name  for  interactive  jobs  is
          /<I>dev</I>/<I>null</I>. For batch jobs the default file name has the
          form <I>job</I>_<I>name</I>.e<I>job</I>_<I>id</I> and <I>job</I>_<I>name</I>.e<I>job</I>_<I>id</I>.task_id  for
          array job tasks (see -t option below).

          If path is a directory, the standard  error  stream  of
          the job will be put in this directory under the default
          file name.  If the  pathname  contains  certain  pseudo
          environment  variables, their value will be expanded at
          runtime of the job and will be used to  constitute  the
          standard  error  stream path name. The following pseudo
          environment variables are supported currently:

          $HOME       home directory on execution machine
          $USER       user ID of job owner
          $JOB_ID     current job ID
          $JOB_NAME   current job name (see -N option)
          $HOSTNAME   name of the execution host
          $TASK_ID    array job task index number

          Alternatively to $HOME the tilde sign "~" can  be  used
          as common in <B><A HREF="../htmlman1/csh.html?pathrev=V62u5_TAG">csh(1)</A></B> or <B><A HREF="../htmlman1/ksh.html?pathrev=V62u5_TAG">ksh(1)</A></B>.  Note, that the "~" sign
          also works in combination  with  user  names,  so  that
          "~&lt;user&gt;"  expands  to  the  home  directory of &lt;user&gt;.
          Using another user  ID  than  that  of  the  job  owner
          requires corresponding permissions, of course.

          <I>Qalter</I> allows changing this option even while  the  job
          executes. The modified parameter will only be in effect
          after a restart or migration of the job, however.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified then this value will be passed to defined JSV
          instances as parameter with  the  name  e.   (see  -jsv
          option below or find more information concerning JSV in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -hard
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          Signifies that all -q and -l resource requirements fol-
          lowing  in  the  command line will be hard requirements
          and must be satisfied in  full  before  a  job  can  be
          scheduled.
          As Sun Grid Engine scans the command  line  and  script
          file  for  Sun  Grid  Engine  options and parameters it
          builds a list of resources required by a job. All  such
          resource  requests  are considered as absolutely essen-
          tial for the job to commence. If the -soft option  (see
          below)  is encountered during the scan then all follow-
          ing resources are designated as "soft requirements" for
          execution, or "nice-to-have, but not essential". If the
          -hard flag is encountered at a later stage of the scan,
          all  resource  requests  following it once again become
          "essential". The -hard and -soft options in effect  act
          as "toggles" during the scan.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified  then  the  corresponding  -q and -l resource
          requirements will be passed to defined JSV instances as
          parameter  with  the  names q_hard and l_hard. Find for
          information in the sections describing -q and -l.  (see
          -jsv  option  below or find more information concerning
          JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -h | -h {u|s|o|n|U|O|S}...
          Available for <I>qsub</I> (only -h), <I>qrsh</I>, <I>qalter</I>  and  <I>qresub</I>
          (hold state is removed when not set explicitly).

          List of holds to place on a job, a task or  some  tasks
          of a job.

          `u'  denotes a user hold.
          `s'  denotes a system hold.
          `o'  denotes a operator hold.
          `n'  denotes no hold (requires manager privileges).

          As long as any hold other than `n' is assigned  to  the
          job the job is not eligible for execution. Holds can be
          released via <I>qalter</I> and <B><A HREF="../htmlman1/qrls.html?pathrev=V62u5_TAG">qrls(1)</A></B>.   In  case  of  <I>qalter</I>
          this  is  supported  by the following additional option
          specifiers for the -h switch:

          `U'  removes a user hold.
          `S'  removes a system hold.
          `O'  removes a operator hold.

          Sun Grid Engine managers can assign and remove all hold
          types,  Sun Grid Engine operators can assign and remove
          user and operator holds, and users can only  assign  or
          remove user holds.

          In the case of <I>qsub</I> only user holds can be placed on  a
          job and thus only the first form of the option with the
          -h switch alone is allowed.  As opposed to this, <I>qalter</I>
          requires the second form described above.

          An alternate means to assign hold is  provided  by  the
          <B><A HREF="../htmlman1/qhold.html?pathrev=V62u5_TAG">qhold(1)</A></B> facility.

          If the job is a array job (see the  -t  option  below),
          all  tasks  specified  via  -t  are  affected by the -h
          operation simultaneously.

          <I>Qalter</I> allows changing this option even while  the  job
          executes. The modified parameter will only be in effect
          after a restart or migration of the job, however.

          If this option is specified with  <I>qsub</I>  or  during  the
          submission  of  a job in <I>qmon</I> then the parameter h with
          the value u will be passed to the defined JSV instances
          indicating  that the job will be in user hold after the
          submission finishes. (see -jsv  option  below  or  find
          more information concerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -help
          Prints  a listing of all options.

     -hold_jid wc_job_list
          Available  for  <I>qsub</I>,  <I>qrsh</I>,  and  <I>qalter</I>   only.   See
          <B><A HREF="../htmlman1/sge_types.html?pathrev=V62u5_TAG">sge_types(1)</A></B>.  for wc_job_list definition.

          Defines or redefines the job  dependency  list  of  the
          submitted  job.  A  reference by job name or pattern is
          only accepted if the referenced job  is  owned  by  the
          same  user  as  the referring job. The submitted job is
          not eligible for execution unless all  jobs  referenced
          in the comma-separated job id and/or job name list have
          completed.  If any of the referenced  jobs  exits  with
          exit code 100, the submitted job will remain ineligible
          for execution.

          With the help of job names or regular pattern  one  can
          specify  a  job  dependency on multiple jobs satisfying
          the regular pattern or on all jobs with  the  requested
          name. The name dependencies are resolved at submit time
          and can only be changed via qalter. New  jobs  or  name
          changes of other jobs will not be taken into account.

          <I>Qalter</I> allows changing this option even while  the  job
          executes. The modified parameter will only be in effect
          after a restart or migration of the job, however.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified then this value will be passed to defined JSV
          instances as parameter with the  name  hold_jid.   (see
          -jsv  option  below or find more information concerning
          JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -hold_jid_ad wc_job_list
          Available  for  <I>qsub</I>,  <I>qrsh</I>,  and  <I>qalter</I>   only.   See
          <B><A HREF="../htmlman1/sge_types.html?pathrev=V62u5_TAG">sge_types(1)</A></B>.  for wc_job_list definition.

          Defines or redefines the job array dependency  list  of
          the  submitted  job. A reference by job name or pattern
          is only accepted if the referenced job is owned by  the
          same  user  as  the referring job. Each sub-task of the
          submitted job is not eligible for execution unless  the
          corresponding  sub-tasks  of all jobs referenced in the
          comma-separated job id and/or job name list  have  com-
          pleted.  If any array task of the referenced jobs exits
          with exit code 100, the dependent tasks of the  submit-
          ted job will remain ineligible for execution.

          With the help of job names or regular pattern  one  can
          specify  a  job  dependency on multiple jobs satisfying
          the regular pattern or on all jobs with  the  requested
          name. The name dependencies are resolved at submit time
          and can only be changed via qalter. New  jobs  or  name
          changes of other jobs will not be taken into account.

          If either the submitted job or any job  in  wc_job_list
          are  not  array  jobs  with the same range of sub-tasks
          (see  -t  option  below),  the  request  list  will  be
          rejected  and  the  job create or modify operation will
          error.

          <I>qalter</I> allows changing this option even while  the  job
          executes. The modified parameter will only be in effect
          after a restart or migration of the job, however.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified then this value will be passed to defined JSV
          instances as parameter with the name hold_jid_ad.  (see
          -jsv  option  below or find more information concerning
          JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -i [[hostname]:]file,...
          Available for <I>qsub</I>, and <I>qalter</I> only.

          Defines or redefines the file  used  for  the  standard
          input  stream  of  the  job. If the <I>file</I> constitutes an
          absolute filename, the input-path attribute of the  job
          is  set  to  path,  including the hostname. If the path
          name is relative, Sun Grid Engine expands  path  either
          with  the  current  working directory path (if the -cwd
          switch (see above) is also specified) or with the  home
          directory  path.  If  hostname is present, the standard
          input stream will be placed in the corresponding  loca-
          tion only if the job runs on the specified host. If the
          path contains a ":" without a hostname, a  leading  ":"
          has to be specified.

          By default /dev/null is the input stream for the job.

          It is possible to use certain pseudo  variables,  whose
          values  will be expanded at runtime of the job and will
          be  used  to  express  the  standard  input  stream  as
          described  in  the  -<I>e</I>  option  for  the standard error
          stream.

          <I>Qalter</I> allows changing this option even while  the  job
          executes. The modified parameter will only be in effect
          after a restart or migration of the job, however.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified then this value will be passed to defined JSV
          instances as parameter with  the  name  i.   (see  -jsv
          option below or find more information concerning JSV in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -inherit
          Available only for <I>qrsh</I> and <B><A HREF="../htmlman1/qmake.html?pathrev=V62u5_TAG">qmake(1)</A></B>.

          <I>qrsh</I> allows the user to start  a  task  in  an  already
          scheduled parallel job.  The option -inherit tells <I>qrsh</I>
          to read a job id from the environment  variable  JOB_ID
          and  start the specified command as a task in this job.
          Please note that in this case, the hostname of the host
          where  the  command  will  be executed must precede the
          command to execute; the syntax changes to

          qrsh -inherit [ other  options  ]  hostname  command  [
          command_args ]

          Note also, that  in  combination  with  -inherit,  most
          other  command  line options will be ignored.  Only the
          options -verbose, -v and -V will be interpreted.  As  a
          replacement to option -cwd please use -v PWD.

          Usually  a  task  should  have  the  same   environment
          (including   the  current  working  directory)  as  the
          corresponding job, so specifying the option  -V  should
          be suitable for most applications.

          <I>Note</I>: If in your system the qmaster  tcp  port  is  not
          configured as a service, but rather via the environment
          variable SGE_QMASTER_PORT, make sure that this variable
          is  set  in  the environment when calling <I>qrsh</I> or <I>qmake</I>
          with the -inherit option. If you  call  <I>qrsh</I>  or  <I>qmake</I>
          with  the  -inherit  option  from  within a job script,
          export   SGE_QMASTER_PORT   with   the    option    "-v
          SGE_QMASTER_PORT"  either  as  a command argument or an
          embedded directive.

          This parameter is not available  in  the  JSV  context.
          (see  -jsv  option  below or find more information con-
          cerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)


     -j y[es]|n[o]
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          Specifies whether or not the standard error  stream  of
          the job is merged into the standard output stream.
          If both the -j y and the -e options  are  present,  Sun
          Grid Engine sets but ignores the error-path attribute.

          <I>Qalter</I> allows changing this option even while  the  job
          executes. The modified parameter will only be in effect
          after a restart or migration of the job, however.
          The value specified with this option or the correspond-
          ing  value  specified  in  <I>qmon</I>  will only be passed to
          defined JSV instances if the value is <I>yes</I>.  The name of
          the  parameter will be j. The value will be y also when
          then long form yes  was  specified  during  submission.
          (see  -jsv  option  below or find more information con-
          cerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -js job_share
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          Defines or redefines the job share of the job  relative
          to other jobs.  Job share is an unsigned integer value.
          The default job share value for jobs is 0.

          The job share influences the Share Tree Policy and  the
          Functional  Policy. It has no effect on the Urgency and
          Override Policies (see <B><A HREF="../htmlman5/share_tree.html?pathrev=V62u5_TAG">share_tree(5)</A></B>, <B><A HREF="../htmlman5/sched_conf.html?pathrev=V62u5_TAG">sched_conf(5)</A></B> and
          the  <I>Sun</I>  <I>Grid</I>  <I>Engine</I>  <I>Installation</I> <I>and</I> <I>Administration</I>
          <I>Guide</I> for further information on the  resource  manage-
          ment policies supported by Sun Grid Engine).

          In case of the Share Tree Policy, users can  distribute
          the  tickets to which they are currently entitled among
          their jobs using different shares assigned via -js.  If
          all jobs have the same job share value, the tickets are
          distributed evenly.  Otherwise,  jobs  receive  tickets
          relative  to  the  different job shares. Job shares are
          treated like an additional level in the share  tree  in
          the latter case.

          In connection with the Functional Policy, the job share
          can  be  used  to weight jobs within the functional job
          category.  Tickets  are  distributed  relative  to  any
          uneven  job  share  distribution  treated  as a virtual
          share distribution level underneath the functional  job
          category.

          If both the Share Tree and the  Functional  Policy  are
          active, the job shares will have an effect in both pol-
          icies, and the tickets independently derived in each of
          them  are added to the total number of tickets for each
          job.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified then this value will be passed to defined JSV
          instances as parameter with the  name  js.   (see  -jsv
          option below or find more information concerning JSV in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -jsv jsv_url
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I> and <I>qlogin</I> only.
          Defines a client JSV instance which will be executed to
          verify  the job specification before the job is sent to
          qmaster.

          In contrast to other options this switch  will  not  be
          overwritten  if  it  is also used in sge_request files.
          Instead all specified JSV instances will be executed to
          verify the job to be submitted.

          The JSV instance which is directly passed with the com-
          mandline of a client is executed as first to verify the
          job specification. After that the  JSV  instance  which
          might  have  been  defined in various sge_request files
          will be triggered to check the job. Find  more  details
          in man page <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B> and <B><A HREF="../htmlman5/sge_request.html?pathrev=V62u5_TAG">sge_request(5)</A></B>.

          The   syntax   of   the   jsv_url   is   specified   in
          <B><A HREF="../htmlman1/sge_types.html?pathrev=V62u5_TAG">sge_types(1)</A></B>.()

     -l resource=value,...
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          Launch the job in a Sun Grid Engine queue  meeting  the
          given  resource  request  list.   In case of <I>qalter</I> the
          previous definition is replaced by the specified one.

          <B><A HREF="../htmlman5/complex.html?pathrev=V62u5_TAG">complex(5)</A></B> describes how a list of available  resources
          and  their  associated  valid  value  specifiers can be
          obtained.

          There may be multiple -l switches in a single  command.
          You  may request multiple -l options to be soft or hard
          both in the same command line. In case of a serial  job
          multiple  -l  switches  refine  the  definition for the
          sought queue.

          <I>Qalter</I> allows changing the value of  this  option  even
          while  the job is running, but only if the initial list
          of resources does not contain a resource that is marked
          as  consumable.  However  the modification will only be
          effective after a restart or migration of the job.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified the these hard and soft resource requirements
          will be passed to defined JSV  instances  as  parameter
          with  the  names  l_hard and l_soft. If regular expres-
          sions will be used for resource  requests,  then  these
          expressions  will  be passed as they are. Also shortcut
          names will not be expanded.  (see -jsv option above  or
          find more information concerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -m b|e|a|s|n,...
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          Defines or redefines under which circumstances mail  is
          to  be  sent  to  the job owner or to the users defined
          with the -M option described below.  The  option  argu-
          ments have the following meaning:

          `b'     Mail is sent at the beginning of the job.
          `e'     Mail is sent at the end of the job.
          `a'     Mail is sent when the job is aborted or
                  rescheduled.
          `s'     Mail is sent when the job is suspended.
          `n'     No mail is sent.

          Currently no mail is sent when a job is suspended.

          <I>Qalter</I> allows changing the b, e, and a option arguments
          even  while the job executes. The modification of the b
          option argument will only be in effect after a  restart
          or migration of the job, however.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified then this value will be passed to defined JSV
          instances as parameter with  the  name  m.   (see  -jsv
          option above or find more information concerning JSV in

     -M user[@host],...
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          Defines or redefines the list of  users  to  which  the
          server  that  executes the job has to send mail, if the
          server sends mail about the job.  Default  is  the  job
          owner at the originating host.

          <I>Qalter</I> allows changing this option even while  the  job
          executes.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified then this value will be passed to defined JSV
          instances as parameter with  the  name  M.   (see  -jsv
          option above or find more information concerning JSV in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -masterq wc_queue_list
          Available for <I>qsub</I>, <I>qrsh</I>, <I>qsh</I>, <I>qlogin</I> and <I>qalter</I>.  Only
          meaningful  for  parallel  jobs, i.e. together with the
          -pe option.

          Defines or redefines a list of  cluster  queues,  queue
          domains and queue instances which may be used to become
          the so called <I>master</I> <I>queue</I> of this parallel job. A more
          detailed  description  of <I>wc</I>_<I>queue</I>_<I>list</I> can be found in
          <B><A HREF="../htmlman1/sge_types.html?pathrev=V62u5_TAG">sge_types(1)</A></B>.  The <I>master</I> <I>queue</I> is defined as the queue
          where  the parallel job is started. The other queues to
          which the parallel job spawns tasks  are  called  <I>slave</I>
          <I>queues</I>.  A parallel job only has one <I>master</I> <I>queue</I>.

          This parameter has all the  properties  of  a  resource
          request  and  will  be merged with requirements derived
          from the -l option described above.

          <I>Qalter</I> allows changing this option even while  the  job
          executes. The modified parameter will only be in effect
          after a restart or migration of the job, however.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified  the  this  hard resource requirement will be
          passed to defined JSV instances as parameter  with  the
          name  masterq.  (see  -jsv  option  above  or find more
          information concerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -notify
          Available for <I>qsub</I>,  <I>qrsh</I>  (with  command)  and  <I>qalter</I>
          only.

          This flag, when set causes  Sun  Grid  Engine  to  send
          "warning" signals to a running job prior to sending the
          signals themselves. If a SIGSTOP is  pending,  the  job
          will  receive a SIGUSR1 several seconds before the SIG-
          STOP. If a SIGKILL is pending, the job will  receive  a
          SIGUSR2  several  seconds  before  the  SIGKILL.   This
          option provides the running job, before  receiving  the
          SIGSTOP  or  SIGKILL,  a configured time interval to do
          e.g. cleanup operations. The amount of  time  delay  is
          controlled by the notify parameter in each queue confi-
          guration (see <B><A HREF="../htmlman5/queue_conf.html?pathrev=V62u5_TAG">queue_conf(5)</A></B>).

          Note that the Linux operating system "misused" the user
          signals  SIGUSR1 and SIGUSR2 in some early Posix thread
          implementations. You might not want to use the  -notify
          option  if  you are running multi-threaded applications
          in your jobs under Linux, particularly on 2.0  or  ear-
          lier kernels.

          <I>Qalter</I> allows changing this option even while  the  job
          executes.

          Only if this option is used the parameter named  notify
          with  the  value  y  will  be  passed  to  defined  JSV
          instances. (see -jsv option above or find more informa-
          tion concerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -now y[es]|n[o]
          Available for <I>qsub</I>, <I>qsh</I>, <I>qlogin</I> and <I>qrsh</I>.
          -now y tries to start the job  immediately  or  not  at
          all.  The command returns 0 on success, or 1 on failure
          (also if the job could not be  scheduled  immediately).
          For  array  jobs submitted with the -now option, if all
          tasks cannot be immediately  scheduled,  no  tasks  are
          scheduled.  -now y is default for <I>qsh</I>, <I>qlogin</I> and <I>qrsh</I>

          With the -now n option, the job will be  put  into  the
          pending  queue  if  it  cannot be executed immediately.
          -now n is default for <I>qsub</I>.

          The value specified with this option or the correspond-
          ing  value  specified  in  <I>qmon</I>  will only be passed to
          defined JSV instances if the value is <I>yes</I>.  The name of
          the  parameter  will  be  now. The value will be y also
          when then long form yes was  specified  during  submis-
          sion.   (see -jsv option above or find more information
          concerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -N name
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          The name of the job. The name should follow the  "name"
          definition  in <B><A HREF="../htmlman1/sge_types.html?pathrev=V62u5_TAG">sge_types(1)</A></B>.  Invalid job names will be
          denied at submit time.

          If the -N  option  is  not  present,  Sun  Grid  Engine
          assigns the name of the job script to the job after any
          directory pathname has been removed  from  the  script-
          name.  If  the  script is read from standard input, the
          job name defaults to STDIN.

          In the case of <I>qsh</I> or <I>qlogin</I>  with  the  -N  option  is
          absent, the string `INTERACT' is assigned to the job.

          In the case of <I>qrsh</I> if the -N  option  is  absent,  the
          resulting  job name is determined from the qrsh command
          line by using the  argument  string  up  to  the  first
          occurrence  of  a  semicolon or whitespace and removing
          the directory pathname.

          <I>Qalter</I> allows changing this option even while  the  job
          executes.

          The value specified with this option or the correspond-
          ing  value  specified in <I>qmon</I> will be passed to defined
          JSV instances as parameter with the name <I>N</I>.  (see  -jsv
          option above or find more information concerning JSV in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -noshell
          Available only for <I>qrsh</I> with a command line.
          Do not start the command line given to <I>qrsh</I> in a user's
          login  shell,  i.e.   execute  it  without the wrapping
          shell.

          This option can be used to speed up execution  as  some
          overhead, like the shell startup and sourcing the shell
          resource files, is avoided.

          This option can only be used if no shell-specific  com-
          mand line parsing is required. If the command line con-
          tains shell syntax like environment variable  substitu-
          tion  or  (back)  quoting, a shell must be started.  In
          this case, either do not use  the  -noshell  option  or
          include the shell call in the command line.

          Example:
          qrsh echo '$HOSTNAME'
          Alternative call with the -noshell option
          qrsh -noshell /bin/tcsh -f -c 'echo $HOSTNAME'

     -nostdin
          Available only for <I>qrsh</I>.

          Suppress the input stream STDIN - <I>qrsh</I>  will  pass  the
          option  -n  to  the  <B><A HREF="../htmlman1/rsh.html?pathrev=V62u5_TAG">rsh(1)</A></B> command. This is especially
          useful, if multiple  tasks  are  executed  in  parallel
          using  <I>qrsh</I>,  e.g.  in  a <B><A HREF="../htmlman1/make.html?pathrev=V62u5_TAG">make(1)</A></B> process - it would be
          undefined, which process would get the input.

     -o [[hostname]:]path,...
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          The path used for the standard  output  stream  of  the
          job.  The path is handled as described in the -e option
          for the standard error stream.

          By default the file name for standard  output  has  the
          form  <I>job</I>_<I>name</I>.o<I>job</I>_<I>id</I> and <I>job</I>_<I>name</I>.o<I>job</I>_<I>id</I>.task_id for
          array job tasks (see -t option below).

          <I>Qalter</I> allows changing this option even while  the  job
          executes. The modified parameter will only be in effect
          after a restart or migration of the job, however.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified then this value will be passed to defined JSV
          instances as parameter with  the  name  o.   (see  -jsv
          option above or find more information concerning JSV in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -ot override_tickets
          Available for <I>qalter</I> only.
          Changes the number of override tickets for  the  speci-
          fied job.  Requires manager/operator privileges.

     -P project_name
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          Specifies the project to which this  job  is  assigned.
          The  administrator  needs to give permission to indivi-
          dual users to submit jobs to a specific  project.  (see
          -aprj option to <B><A HREF="../htmlman1/qconf.html?pathrev=V62u5_TAG">qconf(1)</A></B>).

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified then this value will be passed to defined JSV
          instances as parameter with the  name  ot.   (see  -jsv
          option above or find more information concerning JSV in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -p priority
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          Defines or redefines the priority of the  job  relative
          to  other  jobs.   Priority  is an integer in the range
          -1023 to 1024.  The default priority value for jobs  is
          0.

          Users may only decrease the  priority  of  their  jobs.
          Sun  Grid  Engine  managers and administrators may also
          increase the priority associated with jobs. If a  pend-
          ing job has higher priority, it is earlier eligible for
          being dispatched by the Sun Grid Engine scheduler.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified  and  the  priority  is not 0 then this value
          will be passed to defined JSV  instances  as  parameter
          with  the  name p.  (see -jsv option above or find more
          information concerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -pe parallel_environment n[-[m]]|[-]m,...
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          Parallel programming environment (PE)  to  instantiate.
          For more detail about PEs, please see the <B><A HREF="../htmlman1/sge_types.html?pathrev=V62u5_TAG">sge_types(1)</A></B>.

          <I>Qalter</I> allows changing this option even while  the  job
          executes. The modified parameter will only be in effect
          after a restart or migration of the job, however.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified  then  the  parameters  pe_name,  pe_min  and
          pe_max will be passed to configured JSV instances where
          pe_name  will  be  the name of the parallel environment
          and the values pe_min and pe_max represent the values n
          and  m  which have been provided with the -pe option. A
          missing specification of m will be  expanded  as  value
          9999999  in  JSV  scripts  and  it represents the value
          infinity.  (see -jsv option above or find more informa-
          tion concerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -pty y[es]|n[o]
          Available for <I>qrsh</I> and <I>qlogin</I> only.

          -pty yes enforces the job to be  started  in  a  pseudo
          terminal  (pty).  If no pty is available, the job start
          fails.  -pty no enforces the job to be started  without
          a  pty.   By default, <I>qrsh</I> <I>without</I> <I>a</I> <I>command</I> and <I>qlogin</I>
          start the job in a pty, <I>qrsh</I> <I>with</I> <I>a</I> <I>command</I> starts  the
          job without a pty.

          This parameter is not available  in  the  JSV  context.
          (see  -jsv  option  above or find more information con-
          cerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -q wc_queue_list
          Available for <I>qsub</I>, <I>qrsh</I>, <I>qsh</I>, <I>qlogin</I> and <I>qalter</I>.

          Defines or redefines a list of  cluster  queues,  queue
          domains or queue instances which may be used to execute
          this job. Please find a description of <I>wc</I>_<I>queue</I>_<I>list</I> in
          <B><A HREF="../htmlman1/sge_types.html?pathrev=V62u5_TAG">sge_types(1)</A></B>.  This parameter has all the properties of
          a resource request and will be merged with requirements
          derived from the -l option described above.

          <I>Qalter</I> allows changing this option even while  the  job
          executes. The modified parameter will only be in effect
          after a restart or migration of the job, however.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified the these hard and soft resource requirements
          will be passed to defined JSV instances  as  parameters
          with  the  names  q_hard and q_soft. If regular expres-
          sions will be used for resource  requests,  then  these
          expressions  will  be passed as they are. Also shortcut
          names will not be expanded.  (see -jsv option above  or
          find more information concerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -R y[es]|n[o]
          Available for <I>qsub</I>, <I>qrsh</I>, <I>qsh</I>, <I>qlogin</I> and <I>qalter</I>.

          Indicates whether a reservation for this job should  be
          done.  Reservation  is  never  done for immediate jobs,
          i.e. jobs submitted using the -now yes option.   Please
          note  that  regardless  of the reservation request, job
          reservation might be disabled using max_reservation  in
          <B><A HREF="../htmlman5/sched_conf.html?pathrev=V62u5_TAG">sched_conf(5)</A></B>  and  might  be limited only to a certain
          number of high priority jobs.

          By default jobs are submitted with the -R n option.

          The value specified with this option or the correspond-
          ing  value  specified  in  <I>qmon</I>  will only be passed to
          defined JSV instances if the value is <I>yes</I>.  The name of
          the  parameter will be R. The value will be y also when
          then long form yes  was  specified  during  submission.
          (see  -jsv  option  above or find more information con-
          cerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -r y[es]|n[o]
          Available for <I>qsub</I> and <I>qalter</I> only.

          Identifies the ability of a job to be rerun or not.  If
          the  value of -r is 'yes', the job will be rerun if the
          job was  aborted  without  leaving  a  consistent  exit
          state.   (This  is  typically  the  case if the node on
          which the job is running crashes).  If -r is 'no',  the
          job will not be rerun under any circumstances.
          Interactive jobs submitted with <I>qsh</I>, <I>qrsh</I> or <I>qlogin</I> are
          not rerunnable.

          <I>Qalter</I> allows changing this option even while  the  job
          executes.

          The value specified with this option or the correspond-
          ing  value  specified  in  <I>qmon</I>  will only be passed to
          defined JSV instances if the value is <I>yes</I>.  The name of
          the  parameter will be r. The value will be y also when
          then long form yes  was  specified  during  submission.
          (see  -jsv  option  above or find more information con-
          cerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -sc variable[=value],...
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          Sets the given name/value pairs as the  job's  context.
          Value  may  be  omitted.  Sun  Grid Engine replaces the
          job's previously defined context with the one given  as
          the  argument.   Multiple -ac, -dc, and -sc options may
          be given.  The order is important.

          Contexts provide a way to dynamically attach and remove
          meta-information  to  and from a job. The context vari-
          ables are not passed to the job's execution context  in
          its environment.

          <I>Qalter</I> allows changing this option even while  the  job
          executes.

          The outcome of the evaluation of all -ac, -dc, and  -sc
          options  or  corresponding  values in <I>qmon</I> is passed to
          defined JSV instances as parameter with  the  name  ac.
          (see  -jsv  option  above or find more information con-
          cerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -shell y[es]|n[o]
          Available only for <I>qsub</I>.

          -shell n  causes  qsub  to  execute  the  command  line
          directly,  as  if by <B><A HREF="../htmlman2/exec.html?pathrev=V62u5_TAG">exec(2)</A></B>.  No command shell will be
          executed for the job.  This option only applies when -b
          y is also used.  Without -b y, -shell n has no effect.

          This option can be used to speed up execution  as  some
          overhead, like the shell startup and sourcing the shell
          resource files is avoided.

          This option can only be used if no shell-specific  com-
          mand line parsing is required. If the command line con-
          tains shell syntax, like environment variable substitu-
          tion  or  (back)  quoting, a shell must be started.  In
          this case either do not use the -shell n option or exe-
          cute the shell as the command line and pass the path to
          the executable as a parameter.

          If a job executed with the -shell n option fails due to
          a  user  error,  such as an invalid path to the execut-
          able, the job will enter the error state.

          -shell y cancels the effect of  a  previous  -shell  n.
          Otherwise, it has no effect.

          See -b and -noshell for more information.

          The value specified with this option or the correspond-
          ing  value  specified  in  <I>qmon</I>  will only be passed to
          defined JSV instances if the value is <I>yes</I>.  The name of
          the  parameter  will be shell. The value will be y also
          when then long form yes was  specified  during  submis-
          sion.   (see -jsv option above or find more information
          concerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -soft
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I> only.

          Signifies that all resource requirements  following  in
          the  command  line will be soft requirements and are to
          be filled on an "as available" basis.
          As Sun Grid Engine scans the command  line  and  script
          file  for  Sun  Grid  Engine options and parameters, it
          builds a list of resources required  by  the  job.  All
          such  resource  requests  are  considered as absolutely
          essential for the job to commence. If the -soft  option
          is  encountered  during  the  scan  then  all following
          resources are designated  as  "soft  requirements"  for
          execution, or "nice-to-have, but not essential". If the
          -hard flag (see above) is encountered at a later  stage
          of  the  scan,  all resource requests following it once
          again become "essential". The -hard and  -soft  options
          in effect act as "toggles" during the scan.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified  then  the  corresponding  -q and -l resource
          requirements will be passed to defined JSV instances as
          parameter  with  the  names q_soft and l_soft. Find for
          information in the sections describing -q and -l.  (see
          -jsv  option  above or find more information concerning
          JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -sync y[es]|n[o]
          Available for <I>qsub</I>.

          -sync y causes <I>qsub</I> to wait for  the  job  to  complete
          before  exiting.   If  the  job completes successfully,
          <I>qsub</I>'<I>s</I> exit code will be that of the completed job.  If
          the job fails to complete successfully, <I>qsub</I> will print
          out a error message indicating why the job  failed  and
          will  have  an exit code of 1.  If <I>qsub</I> is interrupted,
          e.g. with CTRL-C, before the  job  completes,  the  job
          will be canceled.
          With the -sync n option, <I>qsub</I> will exit  with  an  exit
          code of 0 as soon as the job is submitted successfully.
          -sync n is default for <I>qsub</I>.
          If -sync y is used in conjunction  with  -now  y,  <I>qsub</I>
          will  behave as though only -now y were given until the
          job has been successfully scheduled, after  which  time
          <I>qsub</I> will behave as though only -sync y were given.
          If -sync y is used in conjunction  with  -t  n[-m[:i]],
          <I>qsub</I>  will  wait  for  all  the job's tasks to complete
          before exiting.  If all the job's tasks  complete  suc-
          cessfully,  <I>qsub</I>'<I>s</I>  exit code will be that of the first
          completed job tasks with a non-zero exit code, or 0  if
          all job tasks exited with an exit code of 0.  If any of
          the job's tasks fail  to  complete  successfully,  <I>qsub</I>
          will  print out an error message indicating why the job
          task(s) failed and will have an exit  code  of  1.   If
          <I>qsub</I>  is  interrupted, e.g. with CTRL-C, before the job
          completes, all of the job's tasks will be canceled.

          Information that this switch was specified during  sub-
          mission is not available in the JSV context.  (see -jsv
          option above or find more information concerning JSV in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -S [[hostname]:]pathname,...
          Available for <I>qsub</I>, <I>qsh</I> and <I>qalter</I>.

          Specifies the interpreting shell for the job. Only  one
          pathname  component  without  a host specifier is valid
          and only one path name for a  given  host  is  allowed.
          Shell paths with host assignments define the interpret-
          ing shell for the job if  the  host  is  the  execution
          host. The shell path without host specification is used
          if the execution host matches none of the hosts in  the
          list.

          Furthermore,  the  pathname  can  be  constructed  with
          pseudo  environment  variables  as described for the -e
          option above.

          In the case of <I>qsh</I> the specified shell path is used  to
          execute  the  corresponding  command interpreter in the
          <B><A HREF="../htmlman1/xterm.html?pathrev=V62u5_TAG">xterm(1)</A></B> (via its -<I>e</I> option) started on behalf  of  the
          interactive  job.  <I>Qalter</I>  allows  changing this option
          even while the job  executes.  The  modified  parameter
          will  only be in effect after a restart or migration of
          the job, however.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified then this value will be passed to defined JSV
          instances as parameter with  the  name  S.   (see  -jsv
          option above or find more information concerning JSV in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -t n[-m[:s]]
          Available for <I>qsub</I> and <I>qalter</I> only.

          Submits a so called <I>Array</I> <I>Job</I>, i.e. an array of identi-
          cal  tasks being differentiated only by an index number
          and being treated by Sun  Grid  Engine  almost  like  a
          series of jobs. The option argument to -t specifies the
          number of array job tasks and the  index  number  which
          will  be  associated  with the tasks. The index numbers
          will be exported to the job tasks via  the  environment
          variable  SGE_TASK_ID.  The option arguments n, m and s
          will be available  through  the  environment  variables
          SGE_TASK_FIRST, SGE_TASK_LAST and  SGE_TASK_STEPSIZE.

          Following restrictions apply to the values n and m:

               1 &lt;= n &lt;= MIN(2^31-1, max_aj_tasks)
               1 &lt;= m &lt;= MIN(2^31-1, max_aj_tasks)
               n &lt;= m

          <I>max</I>_<I>aj</I>_<I>tasks</I> is defined in  the  cluster  configuration
          (see <B><A HREF="../htmlman5/sge_conf.html?pathrev=V62u5_TAG">sge_conf(5)</A></B>)
          The task id range specified in the option argument  may
          be a single number, a simple range of the form n-m or a
          range with a step size. Hence, the task id range speci-
          fied  by  2-10:2 would result in the task id indexes 2,
          4, 6, 8, and 10, for a total of 5 identical tasks, each
          with  the  environment  variable SGE_TASK_ID containing
          one of the 5 index numbers.

          All array job tasks inherit the same resource  requests
          and  attribute  definitions as specified in the <I>qsub</I> or
          <I>qalter</I> command line, except  for  the  -t  option.  The
          tasks  are scheduled independently and, provided enough
          resources exist, concurrently, very much like  separate
          jobs.   However,  an  array job or a sub-array there of
          can be accessed as  a  single  unit  by  commands  like
          <B><A HREF="../htmlman1/qmod.html?pathrev=V62u5_TAG">qmod(1)</A></B> or <B><A HREF="../htmlman1/qdel.html?pathrev=V62u5_TAG">qdel(1)</A></B>.  See the corresponding manual pages
          for further detail.

          Array jobs are commonly used to execute the  same  type
          of operation on varying input data sets correlated with
          the task index number. The number of tasks in  a  array
          job is unlimited.

          STDOUT and STDERR of array job tasks  will  be  written
          into different files with the default location

          &lt;jobname&gt;.['e'|'o']&lt;job_id&gt;'.'&lt;task_id&gt;

          In order to change this default, the -e and -o  options
          (see  above)  can  be  used  together  with  the pseudo
          environment variables $HOME, $USER, $JOB_ID, $JOB_NAME,
          $HOSTNAME, and $SGE_TASK_ID.

          Note, that you can use the output redirection to divert
          the  output  of  all  tasks into the same file, but the
          result of this is undefined.

          If this option or a  corresponding  value  in  <I>qmon</I>  is
          specified then this value will be passed to defined JSV
          instances as parameters with the name t_min, t_max  and
          t_step  (see -jsv option above or find more information
          concerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)


     -tc max_running_tasks
          -allow users to limit concurrent array job task  execu-
          tion.  Parameter  max_running_tasks  specifies  maximum
          number of simultaneously running tasks.  For example we
          have  running  SGE  with 10 free slots. We call qsub -t
          1-100 -tc 2  jobscript.  Then  only  2  tasks  will  be
          scheduled to run even when 8 slots are free.

     -terse
          Available for <I>qsub</I> only.

          -terse causes the <I>qsub</I> to display only  the  job-id  of
          the  job  being submitted rather than the regular "Your
          job ..." string.  In case of  an  error  the  error  is
          reported on stderr as usual.
          This can be helpful for scripts  which  need  to  parse
          <I>qsub</I> output to get the job-id.

          Information that this switch was specified during  sub-
          mission is not available in the JSV context.  (see -jsv
          option above or find more information concerning JSV in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -u username,...
          Available for <I>qalter</I> only. Changes  are  only  made  on
          those  jobs  which were submitted by users specified in
          the list of usernames.  For managers it is possible  to
          use the qalter -u '*' command to modify all jobs of all
          users.

          If you use the -u switch it is not permitted to specify
          an additional <I>wc</I>_<I>job</I>_<I>range</I>_<I>list</I>.

     -v variable[=value],...
          Available for <I>qsub</I>, <I>qrsh</I> (with  command  argument)  and
          <I>qalter</I>.

          Defines or redefines the environment  variables  to  be
          exported  to  the execution context of the job.  If the
          -v option is present  Sun  Grid  Engine  will  add  the
          environment  variables  defined  as  arguments  to  the
          switch and, optionally, values of specified  variables,
          to the execution context of the job.

          <I>Qalter</I> allows changing this option even while  the  job
          executes. The modified parameter will only be in effect
          after a restart or migration of the job, however.

          All environment variables specified with -v, -V or  the
          DISPLAY   variable   provided  with  -display  will  be
          exported to the defined JSV instances  only  optionally
          when  this  is requested explicitly during the job sub-
          mission verification.  (see -jsv option above  or  find
          more information concerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -verbose
          Available only for <I>qrsh</I> and <B><A HREF="../htmlman1/qmake.html?pathrev=V62u5_TAG">qmake(1)</A></B>.

          Unlike <I>qsh</I> and <I>qlogin</I>, <I>qrsh</I> does not output any  infor-
          mational   messages  while  establishing  the  session,
          compliant with the standard <B><A HREF="../htmlman1/rsh.html?pathrev=V62u5_TAG">rsh(1)</A></B> and <B><A HREF="../htmlman1/rlogin.html?pathrev=V62u5_TAG">rlogin(1)</A></B> system
          calls.   If  the  option  -verbose is set, <I>qrsh</I> behaves
          like the <I>qsh</I> and <I>qlogin</I> commands, printing  information
          about  the  process  of establishing the <B><A HREF="../htmlman1/rsh.html?pathrev=V62u5_TAG">rsh(1)</A></B> or <I>rlo-</I>
          <B><A HREF="../htmlman1/gin.html?pathrev=V62u5_TAG">gin(1)</A></B> session.

     -verify
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I>.

          Instead of submitting a job, prints  detailed  informa-
          tion  about the would-be job as though <B><A HREF="../htmlman1/qstat.html?pathrev=V62u5_TAG">qstat(1)</A></B> -j were
          used, including the effects of command-line  parameters
          and the external environment.

     -V   Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I> <I>with</I> <I>command</I> and <I>qalter</I>.

          Specifies that all environment variables active  within
          the <I>qsub</I> utility be exported to the context of the job.

          All environment variables specified with -v, -V or  the
          DISPLAY   variable   provided  with  -display  will  be
          exported to the defined JSV instances  only  optionally
          when  this  is requested explicitly during the job sub-
          mission verification.  (see -jsv option above  or  find
          more information concerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     -w e|w|n|p|v
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I>, <I>qlogin</I> and <I>qalter</I>.

          Specifies a validation level applied to the job  to  be
          submitted  (<I>qsub</I>,  <I>qlogin</I>,  and  <I>qsh</I>)  or the specified
          queued job (<I>qalter</I>).  The information  displayed  indi-
          cates  whether the job can possibly be scheduled assum-
          ing an  empty  system  with  no  other  jobs.  Resource
          requests exceeding the configured maximal thresholds or
          requesting unavailable resource attributes are possible
          causes for jobs to fail this validation.

          The specifiers e, w, n and v define the following vali-
          dation modes:

          `e'  error - jobs with invalid requests will be
               rejected.
          `w'  warning - only a warning will be displayed
               for invalid requests.
          `n'  none - switches off validation; the default for
               <I>qsub</I>, <I>qalter</I>, <I>qrsh</I>, <I>qsh</I>
               and <I>qlogin</I>.
          `p'  poke - does not submit the job but prints a
               validation report based on a cluster as is with
               all resource utilizations in place.
          `v'  verify - does not submit the job but prints a
               validation report based on an empty cluster.

          Note, that the necessary checks are performance consum-
          ing  and hence the checking is switched off by default.
          It should also be noted that load values are not  taken
          into  account  with  the  verification  since  they are
          assumed to be too volatile. To cause -w e  verification
          to  be  passed  at  submission  time, it is possible to
          specify non-volatile values (non-consumables)  or  max-
          imum values (consumables) in complex_values.

     -wd working_dir
          Available for <I>qsub</I>, <I>qsh</I>, <I>qrsh</I> and <I>qalter</I> only.

          Execute  the  job  from  the  directory  specified   in
          working_dir.    This  switch  will  activate  Sun  Grid
          Engine's path aliasing facility, if  the  corresponding
          configuration files are present (see <B><A HREF="../htmlman5/sge_aliases.html?pathrev=V62u5_TAG">sge_aliases(5)</A></B>).

          <I>Qalter</I> allows changing this option even while  the  job
          executes. The modified parameter will only be in effect
          after a restart or migration of the job, however.   The
          parameter  value  will  be  available  in  defined  JSV
          instances as parameter with  the  name  cwd  (see  -cwd
          switch above or find more information concerning JSV in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     command
          Available for <I>qsub</I> and <I>qrsh</I> only.

          The job's scriptfile or binary.  If not present  or  if
          the  operand  is  the single-character string '-', <I>qsub</I>
          reads the script from standard input.

          The command will be available in defined JSV  instances
          as  parameter  with  the  name CMDNAME (see -jsv option
          above  or  find  more  information  concerning  JSV  in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     command_args
          Available for <I>qsub</I>, <I>qrsh</I> and <I>qalter</I> only.

          Arguments to the  job.  Not  valid  if  the  script  is
          entered from standard input.

          <I>Qalter</I> allows changing this option even while  the  job
          executes. The modified parameter will only be in effect
          after a restart or migration of the job, however.

          The number of command arguments is provided to  config-
          ured  JSV instances as parameter with the name CMDARGS.
          Also the argument  values  can  by  accessed.  Argument
          names  have the format CMDARG&lt;number&gt; where &lt;number&gt; is
          a integer between 0 and CMDARGS - 1.  (see -jsv  option
          above  or  find  more  information  concerning  JSV  in
          <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

     xterm_args
          Available for <I>qsh</I> only.

          Arguments to the <B><A HREF="../htmlman1/xterm.html?pathrev=V62u5_TAG">xterm(1)</A></B> executable, as defined in the
          configuration.  For details, refer to <B><A HREF="../htmlman5/sge_conf.html?pathrev=V62u5_TAG">sge_conf(5)</A></B>).

          Information concerning xterm_args will be available  in
          JSV  context  as  parameters  with the name CMDARGS and
          CMDARG&lt;number&gt;. Find more information above in  section
          command_args.  (see  -jsv  option  above  or  find more
          information concerning JSV in <B><A HREF="../htmlman1/jsv.html?pathrev=V62u5_TAG">jsv(1)</A></B>)

ENVIRONMENTAL VARIABLES
     SGE_ROOT       Specifies the location of the Sun Grid Engine
                    standard configuration files.

     SGE_CELL       If set, specifies the default Sun Grid Engine
                    cell. To address a Sun Grid Engine cell <I>qsub</I>,
                    <I>qsh</I>, <I>qlogin</I> or <I>qalter</I> use (in  the  order  of
                    precedence):

                         The name of the cell  specified  in  the
                         environment  variable SGE_CELL, if it is
                         set.

                         The  name  of  the  default  cell,  i.e.
                         default.


     SGE_DEBUG_LEVEL
                    If  set,  specifies  that  debug  information
                    should  be written to stderr. In addition the
                    level of detail in which debug information is
                    generated is defined.

     SGE_QMASTER_PORT
                    If set,  specifies  the  tcp  port  on  which
                    <B><A HREF="../htmlman8/sge_qmaster.html?pathrev=V62u5_TAG">sge_qmaster(8)</A></B> is expected to listen for com-
                    munication requests.  Most installations will
                    use  a  services  map  entry  for the service
                    "sge_qmaster" instead to define that port.

     DISPLAY        For <I>qsh</I> jobs the DISPLAY has to be  specified
                    at job submission.  If the DISPLAY is not set
                    by using the -display or the -v  switch,  the
                    contents  of the DISPLAY environment variable
                    are used as default.

     In addition to those environment variables specified  to  be
     exported  to the job via the -v or the -V option (see above)
     <I>qsub</I>, <I>qsh</I>, and <I>qlogin</I> add the following variables  with  the
     indicated values to the variable list:


     SGE_O_HOME     the home directory of the submitting client.

     SGE_O_HOST     the name of the host on which the  submitting
                    client is running.

     SGE_O_LOGNAME  the LOGNAME of the submitting client.

     SGE_O_MAIL     the MAIL of the submitting  client.  This  is
                    the mail directory of the submitting client.

     SGE_O_PATH     the executable search path of the  submitting
                    client.

     SGE_O_SHELL    the SHELL of the submitting client.

     SGE_O_TZ       the time zone of the submitting client.

     SGE_O_WORKDIR  the absolute  path  of  the  current  working
                    directory of the submitting client.

     Furthermore, Sun Grid Engine sets additional variables  into
     the job's environment, as listed below.

     ARC

     SGE_ARCH       The Sun Grid Engine architecture name of  the
                    node on which the job is running. The name is
                    compiled-in into the <B><A HREF="../htmlman8/sge_execd.html?pathrev=V62u5_TAG">sge_execd(8)</A></B> binary.

     SGE_CKPT_ENV   Specifies the checkpointing  environment  (as
                    selected with the -ckpt option) under which a
                    checkpointing  job  executes.  Only  set  for
                    checkpointing jobs.

     SGE_CKPT_DIR   Only set  for  checkpointing  jobs.  Contains
                    path  <I>ckpt</I>_<I>dir</I>  (see  <B><A HREF="../htmlman5/checkpoint.html?pathrev=V62u5_TAG">checkpoint(5)</A></B>  ) of the
                    checkpoint interface.

     SGE_STDERR_PATH
                    the pathname of the file to which  the  stan-
                    dard  error  stream  of  the job is diverted.
                    Commonly used for enhancing the  output  with
                    error  messages from prolog, epilog, parallel
                    environment   start/stop   or   checkpointing
                    scripts.

     SGE_STDOUT_PATH
                    the pathname of the file to which  the  stan-
                    dard  output  stream  of the job is diverted.
                    Commonly used for enhancing the  output  with
                    messages   from   prolog,   epilog,  parallel
                    environment   start/stop   or   checkpointing
                    scripts.

     SGE_STDIN_PATH the pathname of the file from which the stan-
                    dard  input  stream of the job is taken. This
                    variable might be used  in  combination  with
                    SGE_O_HOST   in   prolog/epilog   scripts  to
                    transfer the input file from  the  submit  to
                    the execution host.

     SGE_JOB_SPOOL_DIR
                    The  directory  used  by  <B><A HREF="../htmlman8/sge_shepherd.html?pathrev=V62u5_TAG">sge_shepherd(8)</A></B>  to
                    store  job related data during job execution.
                    This directory is owned by root or by  a  Sun
                    Grid  Engine  administrative account and com-
                    monly is not open for read or write access to
                    regular users.

     SGE_TASK_ID    The index number of  the  current  array  job
                    task (see -t option above). This is an unique
                    number in each array job and can be  used  to
                    reference  different  input data records, for
                    example. This environment variable is set  to
                    "undefined"  for non-array jobs. It is possi-
                    ble to change the predefined  value  of  this
                    variable with -v or -V (see options above).

     SGE_TASK_FIRST The index number of the first array job  task
                    (see  -t  option  above).  It  is possible to
                    change the predefined value of this  variable
                    with -v or -V (see options above).

     SGE_TASK_LAST  The index number of the last array  job  task
                    (see  -t  option  above).  It  is possible to
                    change the predefined value of this  variable
                    with -v or -V (see options above).

     SGE_TASK_STEPSIZE
                    The step size of the array job  specification
                    (see  -t  option  above).  It  is possible to
                    change the predefined value of this  variable
                    with -v or -V (see options above).

     ENVIRONMENT    The ENVIRONMENT variable is set to  BATCH  to
                    identify that the job is being executed under
                    Sun Grid Engine control.

     HOME           The  user's  home  directory  path  from  the
                    <B><A HREF="../htmlman5/passwd.html?pathrev=V62u5_TAG">passwd(5)</A></B> file.

     HOSTNAME       The hostname of the node on which the job  is
                    running.

     JOB_ID         A   unique   identifier   assigned   by   the
                    <B><A HREF="../htmlman8/sge_qmaster.html?pathrev=V62u5_TAG">sge_qmaster(8)</A></B>  when  the  job was submitted.
                    The job ID is a decimal integer in the  range
                    1 to 99999.

     JOB_NAME       The job name. For batch jobs or jobs  submit-
                    ted  by  <I>qrsh</I> with a command, the job name is
                    built as basename of the <I>qsub</I> script filename
                    resp. the <I>qrsh</I> command.  For interactive jobs
                    it is set  to  `INTERACTIVE'  for  <I>qsh</I>  jobs,
                    `QLOGIN'  for  <I>qlogin</I>  jobs and `QRLOGIN' for
                    <I>qrsh</I> jobs without a command.

                    This default may be overwritten  by  the  -<I>N</I>.
                    option.

     JOB_SCRIPT     The path to the job script which is executed.
                    The value can not be overwritten by the -v or
                    -V option.

     LOGNAME        The user's  login  name  from  the  <B><A HREF="../htmlman5/passwd.html?pathrev=V62u5_TAG">passwd(5)</A></B>
                    file.

     NHOSTS         The number of hosts in use by a parallel job.

     NQUEUES        The number of queues allocated  for  the  job
                    (always 1 for serial jobs).

     NSLOTS         The number of queue slots in use by a  paral-
                    lel job.

     PATH           A default shell search path of:
                    /usr/local/bin:/usr/ucb:/bin:/usr/bin

     SGE_BINARY_PATH
                    The path where the Sun Grid  Engine  binaries
                    are installed. The value is the concatenation
                    of   the    cluster    configuration    value
                    binary_path   and   the   architecture   name
                    $SGE_ARCH environment variable.

     PE             The parallel environment under which the  job
                    executes (for parallel jobs only).

     PE_HOSTFILE    The path of a file containing the  definition
                    of the virtual parallel machine assigned to a
                    parallel job by  Sun  Grid  Engine.  See  the
                    description  of the $pe_hostfile parameter in
                    <B><A HREF="../htmlman5/sge_pe.html?pathrev=V62u5_TAG">sge_pe(5)</A></B> for details on the format  of  this
                    file. The environment variable is only avail-
                    able for parallel jobs.

     QUEUE          The name of the cluster queue  in  which  the
                    job is running.

     REQUEST        Available for batch jobs only.

                    The request name of a job as  specified  with
                    the  -N  switch  (see  above) or taken as the
                    name of the job script file.

     RESTARTED      This variable is set to 1 if a job  was  res-
                    tarted either after a system crash or after a
                    migration in case of a checkpointing job. The
                    variable has the value 0 otherwise.

     SHELL          The user's login  shell  from  the  <B><A HREF="../htmlman5/passwd.html?pathrev=V62u5_TAG">passwd(5)</A></B>
                    file. Note: This is not necessarily the shell
                    in use for the job.

     TMPDIR         The absolute  path  to  the  job's  temporary
                    working directory.

     TMP            The same as TMPDIR; provided for  compatibil-
                    ity with NQS.

     TZ             The  time   zone   variable   imported   from
                    <B><A HREF="../htmlman8/sge_execd.html?pathrev=V62u5_TAG">sge_execd(8)</A></B> if set.

     USER           The user's  login  name  from  the  <B><A HREF="../htmlman5/passwd.html?pathrev=V62u5_TAG">passwd(5)</A></B>
                    file.

     SGE_JSV_TIMEOUT
                    If the response time of  the  client  JSV  is
                    greater than this timeout value, then the JSV
                    will attempt to be  re-started.  The  default
                    value  is  10 seconds, and this value must be
                    greater than  0.  If  the  timeout  has  been
                    reached,  the  JSV  will only try to re-start
                    once, if the  timeout  is  reached  again  an
                    error will occur.

RESTRICTIONS
     There is no controlling terminal for batch  jobs  under  Sun
     Grid  Engine, and any tests or actions on a controlling ter-
     minal will fail. If these operations are in your  .login  or
     .cshrc file, they may cause your job to abort.

     Insert the following test before any commands that  are  not
     pertinent to batch jobs in your .login:

          if ( $?JOB_NAME) then
               echo "Sun Grid Engine spooled job"
               exit 0
          endif

     Don't forget to set your shell's search path in  your  shell
     start-up before this code.

EXIT STATUS
     The following exit values are returned:

     0    Operation was executed successfully.

     25   It was not possible to register a new job according  to
          the configured <I>max</I>_<I>u</I>_<I>jobs</I> or <I>max</I>_<I>jobs</I> limit. Additional
          information may be found in <B><A HREF="../htmlman5/sge_conf.html?pathrev=V62u5_TAG">sge_conf(5)</A></B>

     &gt;0   Error occurred.

EXAMPLES
     The following is the simplest form  of  a  Sun  Grid  Engine
     script file.

     =====================================================


     #!/bin/csh
        a.out


     =====================================================

     The next example is a more complex Sun Grid Engine script.

     =====================================================

     #!/bin/csh

     # Which account to be charged cpu time
     #$ -A santa_claus

     # date-time to run, format [[CC]yy]MMDDhhmm[.SS]
     #$ -a 12241200

     # to run I want 6 or more parallel processes
     # under the PE pvm. the processes require
     # 128M of memory
     #$ -pe pvm 6- -l mem=128

     # If I run on dec_x put stderr in /tmp/foo, if I
     # run on sun_y, put stderr in /usr/me/foo
     #$ -e dec_x:/tmp/foo,sun_y:/usr/me/foo

     # Send mail to these users
     #$ -M santa@nothpole,claus@northpole

     # Mail at beginning/end/on suspension
     #$ -m bes

     # Export these environmental variables
     #$ -v PVM_ROOT,FOOBAR=BAR

     # The job is located in the current
     # working directory.
     #$ -cwd

     a.out

     ==========================================================


FILES
     $<I>REQUEST</I>.<I>oJID</I>[.<I>TASKID</I>]      STDOUT of job #JID
     $<I>REQUEST</I>.<I>eJID</I>[.<I>TASKID</I>]      STDERR of job
     $<I>REQUEST</I>.<I>poJID</I>[.<I>TASKID</I>]     STDOUT of par. env. of job
     $<I>REQUEST</I>.<I>peJID</I>[.<I>TASKID</I>]     STDERR of par. env. of job

     $<I>cwd</I>/.<I>sge</I>_<I>aliases</I>         cwd path aliases
     $<I>cwd</I>/.<I>sge</I>_<I>request</I>         cwd default request
     $<I>HOME</I>/.<I>sge</I>_<I>aliases</I>        user path aliases
     $<I>HOME</I>/.<I>sge</I>_<I>request</I>        user default request
     &lt;<I>sge</I>_<I>root</I>&gt;/&lt;<I>cell</I>&gt;/<I>common</I>/<I>sge</I>_<I>aliases</I>
                               cluster path aliases
     &lt;<I>sge</I>_<I>root</I>&gt;/&lt;<I>cell</I>&gt;/<I>common</I>/<I>sge</I>_<I>request</I>
                               cluster default request
     &lt;<I>sge</I>_<I>root</I>&gt;/&lt;<I>cell</I>&gt;/<I>common</I>/<I>act</I>_<I>qmaster</I>
                               Sun Grid Engine master host file

SEE ALSO
     <B><A HREF="../htmlman1/sge_intro.html?pathrev=V62u5_TAG">sge_intro(1)</A></B>, <B><A HREF="../htmlman1/qconf.html?pathrev=V62u5_TAG">qconf(1)</A></B>, <B><A HREF="../htmlman1/qdel.html?pathrev=V62u5_TAG">qdel(1)</A></B>, <B><A HREF="../htmlman1/qhold.html?pathrev=V62u5_TAG">qhold(1)</A></B>, <B><A HREF="../htmlman1/qmod.html?pathrev=V62u5_TAG">qmod(1)</A></B>, <B><A HREF="../htmlman1/qrls.html?pathrev=V62u5_TAG">qrls(1)</A></B>,
     <B><A HREF="../htmlman1/qstat.html?pathrev=V62u5_TAG">qstat(1)</A></B>,    <B><A HREF="../htmlman5/accounting.html?pathrev=V62u5_TAG">accounting(5)</A></B>,   <B><A HREF="../htmlman5/sge_aliases.html?pathrev=V62u5_TAG">sge_aliases(5)</A></B>,   <B><A HREF="../htmlman5/sge_conf.html?pathrev=V62u5_TAG">sge_conf(5)</A></B>,
     <B><A HREF="../htmlman5/sge_request.html?pathrev=V62u5_TAG">sge_request(5)</A></B>, <B><A HREF="../htmlman5/sge_pe.html?pathrev=V62u5_TAG">sge_pe(5)</A></B>, <B><A HREF="../htmlman5/complex.html?pathrev=V62u5_TAG">complex(5)</A></B>.

COPYRIGHT
     If configured correspondingly, <I>qrsh</I> and <I>qlogin</I> contain  por-
     tions  of the <I>rsh</I>, <I>rshd</I>, <I>telnet</I> and <I>telnetd</I> code copyrighted
     by The Regents of the University of California.   Therefore,
     the  following note applies with respect to <I>qrsh</I> and <I>qlogin</I>:
     This product includes software developed by  the  University
     of California, Berkeley and its contributors.

     See <B><A HREF="../htmlman1/sge_intro.html?pathrev=V62u5_TAG">sge_intro(1)</A></B> as well  as  the  information  provided  in
     &lt;sge_root&gt;/3rd_party/qrsh   and  &lt;sge_root&gt;/3rd_party/qlogin
     for a statement of further rights and permissions.

















































</PRE>
<HR>
<ADDRESS>
Man(1) output converted with
<a href="http://www.oac.uci.edu/indiv/ehood/man2html.html">man2html</a>
</ADDRESS>
</BODY>
</HTML>