SUBMIT(1)                  Grid Engine User Commands                 SUBMIT(1)



NNAAMMEE
       qsub   -  submit a batch job to Grid Engine.

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

       qlogin -  submit an interactive login session to Grid Engine.

       qrsh   -  submit an interactive rsh session to Grid Engine.

       qalter -  modify a pending batch job of Grid Engine.

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

SSYYNNTTAAXX
       qqssuubb [ ooppttiioonnss ] [ ccoommmmaanndd || ---- [ ccoommmmaanndd__aarrggss ]]

       qqsshh [ ooppttiioonnss ] [ ---- xxtteerrmm__aarrggss ]

       qqllooggiinn [ ooppttiioonnss ]

       qqrrsshh [ ooppttiioonnss ] [ ccoommmmaanndd [ ccoommmmaanndd__aarrggss ]]

       qqaalltteerr [ ooppttiioonnss ] wwcc__jjoobb__rraannggee__lliisstt [ ---- [ ccoommmmaanndd__aarrggss ]]

       qqaalltteerr [ ooppttiioonnss ] --uu uusseerr__lliisstt || --uuaallll [ ---- [ ccoommmmaanndd__aarrggss ]]

       qqrreessuubb [ ooppttiioonnss ] jjoobb__iidd__lliisstt

DDEESSCCRRIIPPTTIIOONN
       _Q_s_u_b  submits batch jobs to the Grid Engine queuing system. Grid Engine
       supports single- and multiple-node jobs. CCoommmmaanndd can be  a  path  to  a
       binary or a script (see --bb below) which contains the commands to be run
       by the job using a shell (for example, _s_h(1) or _c_s_h(1)).  Arguments  to
       the  command are given as ccoommmmaanndd__aarrggss to _q_s_u_b _.  If ccoommmmaanndd 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 --CC option described below, the  line
       is parsed for embedded command flags.

       _Q_s_h  submits  an  interactive  X-windows  session  to  Grid  Engine. An
       _x_t_e_r_m(1) 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 _-_d_i_s_p_l_a_y _q_s_h 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  _q_s_h that appropriate
       resources to execute the job are not available.  xxtteerrmm__aarrggss are  passed
       to  the  _x_t_e_r_m(1) executable.  Note, however, that the _-_e and _-_l_s xterm
       options do not work with _q_s_h _.

       _Q_l_o_g_i_n is similar to _q_s_h in that it submits an interactive job  to  the
       queueing  system. It does not open an _x_t_e_r_m(1) window on the X display,
       but uses the current terminal for user I/O. Usually, _q_l_o_g_i_n establishes
       a _t_e_l_n_e_t(1) connection with the remote host, using standard client- and
       server-side commands. These commands can be configured  with  the  qqlloo--
       ggiinn__ddaaeemmoonn  (server-side,  Grid  Engine  _t_e_l_n_e_t_d  if not set, otherwise
       something like /usr/sbin/in.telnetd) and  qqllooggiinn__ccoommmmaanndd  (client-side,
       Grid  Engine  _t_e_l_n_e_t if not set, otherwise something like /usr/bin/tel-
       net) parameters in the  global  and  local  configuration  settings  of
       _g_e___c_o_n_f(5).   The  client  side  command is automatically parameterized
       with the remote host name and port number to which to connect,  result-
       ing in an invocation like

              /usr/bin/telnet my_exec_host 2442

       for  example.  _Q_l_o_g_i_n is invoked exactly like _q_s_h and its jobs can only
       run on INTERACTIVE queues.   _Q_l_o_g_i_n  jobs  can  only  be  used  if  the
       _g_e___e_x_e_c_d(8) is running under the root account.

       _Q_r_s_h  is similar to _q_l_o_g_i_n in that it submits an interactive job to the
       queuing system.  It uses the current terminal for user  I/O.   Usually,
       _q_r_s_h  establishes  a _r_s_h(1) connection with the remote host. If no com-
       mand is given to  _q_r_s_h,  an  _r_l_o_g_i_n(1)  session  is  established.   The
       server-side  commands  used  can  be configured with the rrsshh__ddaaeemmoonn and
       rrllooggiinn__ddaaeemmoonn parameters in the global and local configuration settings
       of  _g_e___c_o_n_f(5).   An Grid Engine _r_s_h_d or _r_l_o_g_i_n_d is used if the parame-
       ters 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 rrsshh__ccoommmmaanndd and rrllooggiinn__ccoommmmaanndd parameters can  be  set
       in  the global and local configuration settings of _g_e___c_o_n_f(5).  If they
       are not set, special Grid Engine _r_s_h(1) and _r_l_o_g_i_n(1)  binaries  deliv-
       ered  with Grid Engine are used.  Use the cluster configuration parame-
       ters to integrate mechanisms like  _s_s_h  or  the  _r_s_h(1)  and  _r_l_o_g_i_n(1)
       facilities supplied with the operating system.

       _Q_r_s_h  jobs can only run in INTERACTIVE queues unless the option --nnooww nnoo
       is used (see below).  They can also only be run, if the _g_e___e_x_e_c_d(8)  is
       running under the root account.

       _Q_r_s_h  provides an additional useful feature for integrating with inter-
       active tools providing a specific command  shell.  If  the  environment
       variable  QQRRSSHH__WWRRAAPPPPEERR  is set when _q_r_s_h is invoked, the command inter-
       preter pointed to by QQRRSSHH__WWRRAAPPPPEERR will be executed to run _q_r_s_h commands
       instead  of  the  users  login shell or any shell specified in the _q_r_s_h
       command-line.  The options --ccwwdd,  --vv,  --VV,  and --ddiissppllaayy only apply  to
       batch jobs.

       _Q_a_l_t_e_r  can be used to change the attributes of pending jobs. For array
       jobs with a mix of running and pending tasks (see the --tt option below),
       modification  with  _q_a_l_t_e_r  only affects the pending tasks.  _Q_a_l_t_e_r can
       change most of the characteristics 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  submit
       options, such as the job script, cannot be changed with I. qalter.

       _Q_r_e_s_u_b  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  sup-
       ported  by _q_r_e_s_u_b is assignment of a new hold state with the --hh option.
       This option can be used to  first  copy  a  job  and  then  change  its
       attributes via _q_a_l_t_e_r.

       Only a manager can use _q_r_e_s_u_b on jobs submitted by another user.  Regu-
       lar users can only use _q_r_e_s_u_b on their own jobs.

       For _q_s_u_b, _q_s_h, _q_r_s_h, and _q_l_o_g_i_n the  administrator  and  the  user  may
       define  default request files (see _g_e___r_e_q_u_e_s_t(5)) which can contain any
       of the options described below.  If an option in a default request file
       is  understood by _q_s_u_b and _q_l_o_g_i_n but not by _q_s_h the option is silently
       ignored if _q_s_h is invoked. Thus you can maintain shared default request
       files for both _q_s_u_b and _q_s_h.

       A   cluster   wide   default   request   file   may   be  placed  under
       $GE_ROOT/$GE_CELL/common/ge_request.   User  private  default   request
       files   are   processed   under  the  locations  $HOME/.ge_request  and
       $cwd/.ge_request. The working directory 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 processed 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 (_q_s_u_b 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 embedded flags, however,
       will override the default settings.

       NNoottee, that the _-_c_l_e_a_r option can be used to discard any  previous  set-
       tings  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
       _q_a_l_t_e_r.

       The  options  described below can be requested either hard or soft.  By
       default, all requests are considered hard until the --ssoofftt  option  (see
       below) is encountered. The hard/soft status remains in effect until its
       counterpart is encountered 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.

OOPPTTIIOONNSS
       --@@ ooppttiioonnffiillee
              Forces _q_s_u_b, _q_r_s_h, _q_s_h, or _q_l_o_g_i_n to use the  options  contained
              in ooppttiioonnffiillee. The indicated file may contain all valid options.
              Comment lines must start with a "#" sign.

       --aa ddaattee__ttiimmee
              Available for _q_s_u_b and _q_a_l_t_e_r only.

              Defines or redefines the time and date at which a job is  eligi-
              ble for execution. DDaattee__ttiimmee conforms to [[CC]]YY]MMDDhhmm[.SS],
              for the details, please see DDaattee__ttiimmee in: _s_g_e___t_y_p_e_s(1).

              If this option is used with _q_s_u_b or if a corresponding value  is
              specified  in _q_m_o_n then a parameter named aa and the value in the
              format  CCYYMMDDhhmm.SS  will  be  passed  to  the  defined  JSV
              instances  (see  --jjssvv option below or find more information con-
              cerning JSV in _j_s_v(1))

       --aacc vvaarriiaabbllee[[==vvaalluuee]],,......
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r only.

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

              The  outcome  of the evaluation of all --aacc, --ddcc, and --sscc options
              or corresponding  values  in  _q_m_o_n  is  passed  to  defined  JSV
              instances as parameter with the name aacc.  (see --jjssvv option below
              or find more information concerning JSV in _j_s_v(1)) _Q_A_L_T_E_R allows
              changing this option even while the job executes.

       --aarr aarr__iidd
              Available for _q_s_u_b, _q_a_l_t_e_r, _q_r_s_h, _q_s_h, or _q_l_o_g_i_n 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 _q_r_s_t_a_t(1) command.

              Note  that the --aarr option adds implicitly the --ww ee option if not
              otherwise requested.

              _Q_a_l_t_e_r 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  _q_m_o_n  is  specified
              then  this  value  will  be  passed  to defined JSV instances as
              parameter with the name aarr.  (see --jjssvv option below or find more
              information concerning JSV in _j_s_v(1))

       --AA aaccccoouunntt__ssttrriinngg
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r only.

              Identifies  the account to which the resource consumption of the
              job should be charged. The aaccccoouunntt__ssttrriinngg should conform to  the
              nnaammee  definition  in  M  sge_types  1  .  In the absence of this
              parameter Grid Engine will place the default account string "ge"
              in the accounting record of the job.

              _Q_a_l_t_e_r  allows changing this option even while the job executes.

              If this option or a corresponding value  in  _q_m_o_n  is  specified
              then  this  value  will  be  passed  to defined JSV instances as
              parameter with the name AA.  (see --jjssvv option below or find  more
              information concerning JSV in _j_s_v(1))

       --bb yy[[eess]]||nn[[oo]]
              Available  for  _q_s_u_b,  _q_r_s_h only. _Q_a_l_t_e_r 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
              ccoommmmaanndd should be treated as binary or script. If the  value  of
              --bb is 'y', then ccoommmmaanndd  may be a binary or script.  The ccoommmmaanndd
              might not be  accessible  from  the  submission  host.   Nothing
              except the path of the ccoommmmaanndd will be transferred from the sub-
              mission host to  the  execution  host.  Path  aliasing  will  be
              applied  to the path of ccoommmmaanndd before ccoommmmaanndd will be executed.

              If the value of --bb is 'n' then ccoommmmaanndd needs to be a script  and
              it will be handled as script. The script file has to be accessi-
              ble by the submission host. It will be transferred to the execu-
              tion  host.  _q_s_u_b/_q_r_s_h  will  search  directive  prefixes within
              script.

              _q_s_u_b will implicitly use --bb nn whereas _q_r_s_h will apply the  --bb  yy
              option if nothing else is specified.

              The  value specified with this option or the corresponding value
              specified in _q_m_o_n will only be passed to defined  JSV  instances
              if  the  value is _y_e_s.  The name of the parameter will be bb. The
              value will be yy also when then long form yyeess was specified  dur-
              ing submission.  (see --jjssvv option below or find more information
              concerning JSV in _j_s_v(1))

              Please note that submission of ccoommmmaanndd as script (--bb nn) can have
              a  significant  performance impact, especially for short running
              jobs and big job scripts.  Script submission adds  a  number  of
              operations to the submission 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.

       --cc ooccccaassiioonn__ssppeecciiffiieerr
              Available for _q_s_u_b and _q_a_l_t_e_r only.

              Defines or redefines whether the job should be checkpointed, and
              if so, under what circumstances. The specification of the check-
              pointing  occasions  with this option overwrites the definitions
              of the _w_h_e_n parameter  in  the  checkpointing  environment  (see
              _c_h_e_c_k_p_o_i_n_t(5))  referenced  by  the _q_s_u_b _-_c_k_p_t switch.  Possible
              values for ooccccaassiioonn__ssppeecciiffiieerr 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.
              <interval>  checkpoint in the specified time interval.

              The minimum CPU interval is defined in the  queue  configuration
              (see _q_u_e_u_e___c_o_n_f(5) for details).  <interval> has to be specified
              in the format hh:mm:ss.   The  maximum  of  <interval>  and  the
              queue's minimum CPU interval is used if <interval> 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 corresponding value
              specified in _q_m_o_n will be passed to defined JSV instances.   The
              <interval> will we available as parameter with the name cc__iinntteerr--
              vvaall, The character  sequence  specified  will  be  available  as
              parameter  with  the name cc__ooccccaassiioonn.  (see --jjssvv option below or
              find more information concerning JSV in _j_s_v(1))


       --cckkpptt cckkpptt__nnaammee
              Available for _q_s_u_b and _q_a_l_t_e_r only.

              Selects the checkpointing environment (see _c_h_e_c_k_p_o_i_n_t(5)) to  be
              used  for  checkpointing  the job. Also declares the job to be a
              checkpointing job.

              If this option or a corresponding value  in  _q_m_o_n  is  specified
              then  this  value  will  be  passed  to defined JSV instances as
              parameter with the name cckkpptt.  (see --jjssvv option  below  or  find
              more information concerning JSV in _j_s_v(1))

       --cclleeaarr Available for _q_s_u_b, _q_s_h, _q_r_s_h, and _q_l_o_g_i_n only.

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

       --ccwwdd   Available for _q_s_u_b, _q_s_h, _q_r_s_h and _q_a_l_t_e_r only.

              Execute the job from the current working directory.  This switch
              will activate Grid Engine's path aliasing facility, if the  cor-
              responding  configuration files are present (see _g_e___a_l_i_a_s_e_s(5)).

              In the case of _q_a_l_t_e_r, the previous definition  of  the  current
              working directory will be overwritten if _q_a_l_t_e_r is executed from
              a different directory than the preceding _q_s_u_b or _q_a_l_t_e_r.

              _Q_a_l_t_e_r 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  _q_m_o_n  is  specified
              then  this  value  will  be  passed  to defined JSV instances as
              parameter with the name ccwwdd. 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 --ccwwdd was not specified  during  job
              submission.   (see  --jjssvv  option  below or find more information
              concerning JSV in _j_s_v(1))


       --CC pprreeffiixx__ssttrriinngg
              Available for _q_s_u_b and _q_r_s_h with script submission (--bb nn).

              _P_r_e_f_i_x___s_t_r_i_n_g defines the prefix that declares  a  directive  in
              the  job's  command.  The  prefix  is  not  a job attribute, but
              affects the behavior of _q_s_u_b and  _q_r_s_h.  If  pprreeffiixx  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 Grid Engine  command.   The  default  is
              "#$".
              The  user  should  be  aware  that changing the first delimiting
              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.

       --ddcc vvaarriiaabbllee,,......
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r only.

              Removes  the given variable(s) from the job's context.  Multiple
              --aacc, --ddcc, and --sscc options may be given.  The order is important.

              _Q_a_l_t_e_r  allows changing this option even while the job executes.

              The outcome of the evaluation of all --aacc, --ddcc, and  --sscc  options
              or  corresponding  values  in  _q_m_o_n  is  passed  to  defined JSV
              instances as parameter with the name aacc.  (see --jjssvv option below
              or find more information concerning JSV in _j_s_v(1))

       --ddiissppllaayy ddiissppllaayy__ssppeecciiffiieerr
              Available for _q_s_h and _q_r_s_h.

              Directs  _x_t_e_r_m(1)  to  use ddiissppllaayy__ssppeecciiffiieerr in order to contact
              the X server.  The ddiissppllaayy__ssppeecciiffiieerr 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 --ddiissppllaayy option overwrite settings from the submission envi-
              ronment and from --vv command line options.

              If this option or a corresponding value  in  _q_m_o_n  is  specified
              then  this  value  will  be  passed  to defined JSV instances as
              parameter with the name ddiissppllaayy. This value will also be  avail-
              able  in the job environment which might optionally be passed to
              JSV scripts. The variable  name  will  be  DDIISSPPLLAAYY.   (see  --jjssvv
              option below or find more information concerning JSV in _j_s_v(1))

       --ddll ddaattee__ttiimmee
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r only.

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

              This option is applicable only for users allowed to submit dead-
              line jobs.

              If this option or a corresponding value  in  _q_m_o_n  is  specified
              then  this  value  will  be  passed  to defined JSV instances as
              parameter with the name ddll. The format for the  date_time  value
              is  CCYYMMDDhhmm.SS (see --jjssvv option below or find more informa-
              tion concerning JSV in _j_s_v(1))


       --ee [[[[hhoossttnnaammee]]::]]ppaatthh,,......
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r only.

              Defines or redefines the path used for the standard error stream
              of  the  job.  For  _q_s_h, _q_r_s_h and _q_l_o_g_i_n only the standard error
              stream of prolog and epilog is redirected.  If the ppaatthh  consti-
              tutes an absolute path name, the error-path attribute of the job
              is set to ppaatthh, including the hhoossttnnaammee. If the path name is rel-
              ative,  Grid Engine expands ppaatthh either with the current working
              directory path (if the --ccwwdd switch (see above)  is  also  speci-
              fied)  or  with the home directory path. If hhoossttnnaammee 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
              contains a ":" without a hhoossttnnaammee, a leading ":" has to be spec-
              ified.

              By  default the file name for interactive jobs is _/_d_e_v_/_n_u_l_l. For
              batch jobs the default file name has the  form  _j_o_b___n_a_m_e_.e_j_o_b___i_d
              and  _j_o_b___n_a_m_e_.e_j_o_b___i_d.ttaasskk__iidd for array job tasks (see --tt option
              below).

              If ppaatthh 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 fol-
              lowing 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 --NN 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 _c_s_h(1) or _k_s_h(1).  Note, that the "~" sign also works in com-
              bination  with user names, so that "~<user>" expands to the home
              directory of <user>. Using another user ID than that of the  job
              owner requires corresponding permissions, of course.

              _Q_a_l_t_e_r  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 _q_m_o_n is specified
              then this value will be  passed  to  defined  JSV  instances  as
              parameter  with the name ee.  (see --jjssvv option below or find more
              information concerning JSV in _j_s_v(1))

       --hhaarrdd  Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r only.

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

              If  this  option  or  a corresponding value in _q_m_o_n is specified
              then the corresponding --qq and --ll resource requirements  will  be
              passed  to  defined  JSV  instances  as parameter with the names
              qq__hhaarrdd and ll__hhaarrdd. Find for information in the sections describ-
              ing  --qq and --ll.  (see --jjssvv option below or find more information
              concerning JSV in _j_s_v(1))

       --hh || --hh {{uu||ss||oo||nn||UU||OO||SS}}......
              Available for _q_s_u_b (only --hh),  _q_r_s_h,  _q_a_l_t_e_r  and  _q_r_e_s_u_b  (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
              _q_a_l_t_e_r and _q_r_l_s(1).  In case of _q_a_l_t_e_r this is supported by  the
              following additional option specifiers for the --hh switch:

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

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

              In  the  case of _q_s_u_b only user holds can be placed on a job and
              thus only the first form of the option with the --hh switch  alone
              is allowed.  As opposed to this, _q_a_l_t_e_r requires the second form
              described above.

              An alternate means to assign hold is provided  by  the  _q_h_o_l_d(1)
              facility.

              If  the  job is a array job (see the --tt option below), all tasks
              specified via --tt are affected by  the  --hh  operation  simultane-
              ously.

              _Q_a_l_t_e_r  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 _q_s_u_b or during the submission
              of a job in _q_m_o_n then the parameter hh with the value uu  will  be
              passed to the defined JSV instances indicating that the job will
              be in user hold afer the submission finishes.  (see --jjssvv  option
              below or find more information concerning JSV in _j_s_v(1))

       --hheellpp  Prints  a listing of all options.

       --hhoolldd__jjiidd wwcc__jjoobb__lliisstt
              Available  for  _q_s_u_b,  _q_r_s_h,  and _q_a_l_t_e_r only. See _s_g_e___t_y_p_e_s(1).
              for wwcc__jjoobb__lliisstt 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  execu-
              tion.

              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.

              _Q_a_l_t_e_r 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  _q_m_o_n  is  specified
              then  this  value  will  be  passed  to defined JSV instances as
              parameter with the name hhoolldd__jjiidd.  (see  --jjssvv  option  below  or
              find more information concerning JSV in _j_s_v(1))

       --hhoolldd__jjiidd__aadd wwcc__jjoobb__lliisstt
              Available  for  _q_s_u_b,  _q_r_s_h,  and _q_a_l_t_e_r only. See _s_g_e___t_y_p_e_s(1).
              for wwcc__jjoobb__lliisstt definition.

              Defines or redefines the job array dependency list of  the  sub-
              mitted  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 exe-
              cution 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 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.

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

              _q_a_l_t_e_r 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  _q_m_o_n  is  specified
              then  this  value  will  be  passed  to defined JSV instances as
              parameter with the name hhoolldd__jjiidd__aadd.  (see --jjssvv option below  or
              find more information concerning JSV in _j_s_v(1))

       --ii [[[[hhoossttnnaammee]]::]]ffiillee,,......
              Available for _q_s_u_b, and _q_a_l_t_e_r only.

              Defines or redefines the file used for the standard input stream
              of the job. If the _f_i_l_e constitutes an  absolute  filename,  the
              input-path  attribute  of  the job is set to ppaatthh, including the
              hhoossttnnaammee. If the path name is relative, Grid Engine expands ppaatthh
              either  with  the  current  working  directory path (if the --ccwwdd
              switch (see above) is also specified) or with the home directory
              path.  If hhoossttnnaammee is present, the standard input stream will be
              placed in the corresponding location only if the job runs on the
              specified host. If the path contains a ":" without a hhoossttnnaammee, 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 _-_e  option
              for the standard error stream.

              _Q_a_l_t_e_r  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 _q_m_o_n is specified
              then this value will be  passed  to  defined  JSV  instances  as
              parameter  with the name ii.  (see --jjssvv option below or find more
              information concerning JSV in _j_s_v(1))

       --iinnhheerriitt
              Available only for _q_r_s_h and _q_m_a_k_e(1).

              _q_r_s_h allows the user to start a task  in  an  already  scheduled
              parallel  job.   The option --iinnhheerriitt tells _q_r_s_h 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

              qqrrsshh  --iinnhheerriitt [ ootthheerr ooppttiioonnss ] hhoossttnnaammee ccoommmmaanndd [ ccoommmmaanndd__aarrggss
              ]

              Note also, that in combination with --iinnhheerriitt, most other command
              line options will be ignored.  Only the options --vveerrbboossee, --vv and
              --VV will be interpreted.  As a replacement to option --ccwwdd  please
              use --vv PPWWDD.

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

              _N_o_t_e_:  If  in your system the qmaster tcp port is not configured
              as a service, but rather via the environment  variable  GE_QMAS-
              TER_PORT, make sure that this variable is set in the environment
              when calling _q_r_s_h or _q_m_a_k_e with the --iinnhheerriitt option. If you call
              _q_r_s_h or _q_m_a_k_e with the --iinnhheerriitt option from within a job script,
              export GE_QMASTER_PORT  with  the  option  "-v  GE_QMASTER_PORT"
              either as a command argument or an embedded directive.

              This  parameter  is not available in the JSV context.  (see --jjssvv
              option below or find more information concerning JSV in _j_s_v(1))


       --jj yy[[eess]]||nn[[oo]]
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r only.

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

              _Q_a_l_t_e_r 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 corresponding  value
              specified  in  _q_m_o_n will only be passed to defined JSV instances
              if the value is _y_e_s.  The name of the parameter will be  jj.  The
              value  will be yy also when then long form yyeess was specified dur-
              ing submission.  (see --jjssvv option below or find more information
              concerning JSV in _j_s_v(1))

       --jjss jjoobb__sshhaarree
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r 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 Func-
              tional Policy. It has no effect  on  the  Urgency  and  Override
              Policies  (see  _s_h_a_r_e___t_r_e_e(5), _s_c_h_e_d___c_o_n_f(5) and the _G_r_i_d _E_n_g_i_n_e
              _I_n_s_t_a_l_l_a_t_i_o_n _a_n_d _A_d_m_i_n_i_s_t_r_a_t_i_o_n _G_u_i_d_e for further information on
              the resource management policies supported by Grid Engine).

              In case of the Share Tree Policy, users can distribute the tick-
              ets to which they are currently entitled among their jobs  using
              different shares assigned via --jjss. 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 policies, 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  _q_m_o_n  is  specified
              then  this  value  will  be  passed  to defined JSV instances as
              parameter with the name jjss.  (see --jjssvv option below or find more
              information concerning JSV in _j_s_v(1))

       --jjssvv jjssvv__uurrll
              Available for _q_s_u_b, _q_s_h, _q_r_s_h and _q_l_o_g_i_n 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  submit-
              ted.

              The  JSV  instance which is directly passed with the commandline
              of a client is executed as first to verify  the  job  specifica-
              tion.  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 _j_s_v(1) and _s_g_e___r_e_q_u_e_s_t(5).

              The syntax of the jjssvv__uurrll is specified in _s_g_e___t_y_p_e_s_(_1_)_.()

       --ll rreessoouurrccee==vvaalluuee,...
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r only.

              Launch the job in a Grid Engine queue meeting the given resource
              request list.  In case of  _q_a_l_t_e_r  the  previous  definition  is
              replaced by the specified one.

              _c_o_m_p_l_e_x(5) describes how a list of available resources and their
              associated valid value specifiers can be obtained.

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

              _Q_a_l_t_e_r  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 _q_m_o_n is specified the
              these hard and soft resource  requirements  will  be  passed  to
              defined  JSV  instances  as  parameter with the names ll__hhaarrdd and
              ll__ssoofftt.  If  regular  expressions  will  be  used  for  resource
              requests,  then  these  expressions  will be passed as they are.
              Also shortcut names will not  be  expanded.   (see  --jjssvv  option
              below or find more information concerning JSV in _j_s_v(1))

       --mm bb||ee||aa||ss||nn,,......
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r only.

              Defines  or  redefines  under  which circumstances mail is to be
              sent to the job owner or to the users defined with the --MM option
              described  below.  The option arguments have the following mean-
              ing:

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

              _Q_a_l_t_e_r allows changing the b, e, and  a  option  arguments  even
              while  the  job executes. The modification of the b option argu-
              ment will only be in effect after a restart or migration of  the
              job, however.

              If  this  option  or  a corresponding value in _q_m_o_n is specified
              then this value will be  passed  to  defined  JSV  instances  as
              parameter  with the name mm.  (see --jjssvv option below or find more
              information concerning JSV in

       --MM uusseerr[[@@hhoosstt]],,......
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r 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.

              _Q_a_l_t_e_r  allows changing this option even while the job executes.

              If this option or a corresponding value  in  _q_m_o_n  is  specified
              then  this  value  will  be  passed  to defined JSV instances as
              parameter with the name MM.  (see --jjssvv option below or find  more
              information concerning JSV in _j_s_v(1))

       --mmaasstteerrqq wwcc__qquueeuuee__lliisstt
              Available for _q_s_u_b, _q_r_s_h, _q_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r.  Only meaning-
              ful 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 _m_a_s_t_e_r
              _q_u_e_u_e of this parallel  job.  A  more  detailed  description  of
              _w_c___q_u_e_u_e___l_i_s_t can be found in _s_g_e___t_y_p_e_s(1).  The _m_a_s_t_e_r _q_u_e_u_e is
              defined as the queue where the  parallel  job  is  started.  The
              other  queues  to which the parallel job spawns tasks are called
              _s_l_a_v_e _q_u_e_u_e_s.  A parallel job only has one _m_a_s_t_e_r _q_u_e_u_e.

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

              _Q_a_l_t_e_r 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 _q_m_o_n is specified the
              this  hard  resource  requirement  will be passed to defined JSV
              instances as parameter with the name mmaasstteerrqq.  (see --jjssvv  option
              below or find more information concerning JSV in _j_s_v(1))

       --nnoottiiffyy
              Available for _q_s_u_b, _q_r_s_h (with command) and _q_a_l_t_e_r only.

              This flag, when set causes 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 sec-
              onds before the SIGSTOP. 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 opera-
              tions.  The amount of time delay is  controlled  by  the  nnoottiiffyy
              parameter in each queue configuration (see _q_u_e_u_e___c_o_n_f(5)).

              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 --nnoottiiffyy option if you are running
              multi-threaded applications in your jobs under  Linux,  particu-
              larly on 2.0 or earlier kernels.

              _Q_a_l_t_e_r  allows changing this option even while the job executes.

              Only if this option is used the parameter named nnoottiiffyy with  the
              value  yy  will  be  passed  to defined JSV instances.  (see --jjssvv
              option below or find more information concerning JSV in _j_s_v(1))

       --nnooww yy[[eess]]||nn[[oo]]
              Available for _q_s_u_b, _q_s_h, _q_l_o_g_i_n and _q_r_s_h.

              --nnooww yy 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 --nnooww option, if all tasks cannot be immediately sched-
              uled, no tasks are scheduled.  --nnooww yy is default for _q_s_h, _q_l_o_g_i_n
              and _q_r_s_h

              With  the  --nnooww  nn  option, the job will be put into the pending
              queue if it cannot be executed immediately. --nnooww  nn  is  default
              for _q_s_u_b.

              The  value specified with this option or the corresponding value
              specified in _q_m_o_n will only be passed to defined  JSV  instances
              if the value is _y_e_s.  The name of the parameter will be nnooww. The
              value will be yy also when then long form yyeess was specified  dur-
              ing submission.  (see --jjssvv option below or find more information
              concerning JSV in _j_s_v(1))

       --NN nnaammee
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r only.

              The name of the job. The name should follow the  "nnaammee"  defini-
              tion  in _s_g_e___t_y_p_e_s(1).  Invalid job names will be denied at sub-
              mit time.

              If the --NN option is not present, 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  stan-
              dard input, the job name defaults to STDIN.

              In  the  case of _q_s_h or _q_l_o_g_i_n with the --NN option is absent, the
              string `INTERACT' is assigned to the job.

              In the case of _q_r_s_h if the --NN 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.

              _Q_a_l_t_e_r  allows changing this option even while the job executes.

              The value specified with this option or the corresponding  value
              specified  in  _q_m_o_n  will  be passed to defined JSV instances as
              parameter with the name _N.  (see --jjssvv option below or find  more
              information concerning JSV in _j_s_v(1))

       --nnoosshheellll
              Available only for _q_r_s_h with a command line.

              Do  not  start  the command line given to _q_r_s_h 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  command  line
              parsing  is  required. If the command line contains shell syntax
              like environment variable  substitution  or  (back)  quoting,  a
              shell  must  be  started.   In  this case, either do not use the
              --nnoosshheellll 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'

       --nnoossttddiinn
              Available only for _q_r_s_h.

              Suppress the input stream STDIN - _q_r_s_h will pass the  option  -n
              to  the  _r_s_h(1)  command. This is especially useful, if multiple
              tasks are executed in parallel using _q_r_s_h,  e.g.  in  a  _m_a_k_e(1)
              process  -  it  would  be undefined, which process would get the
              input.

       --oo [[[[hhoossttnnaammee]]::]]ppaatthh,,......
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r only.

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

              By default the file  name  for  standard  output  has  the  form
              _j_o_b___n_a_m_e_.o_j_o_b___i_d  and  _j_o_b___n_a_m_e_.o_j_o_b___i_d.ttaasskk__iidd  for  array  job
              tasks (see --tt option below).

              _Q_a_l_t_e_r 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  _q_m_o_n  is  specified
              then  this  value  will  be  passed  to defined JSV instances as
              parameter with the name oo.  (see --jjssvv option below or find  more
              information concerning JSV in _j_s_v(1))

       --oott oovveerrrriiddee__ttiicckkeettss
              Available for _q_a_l_t_e_r only.

              Changes  the  number  of override tickets for the specified job.
              Requires manager/operator privileges.

       --PP pprroojjeecctt__nnaammee
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r only.

              Specifies the project to which this job is assigned. The  admin-
              istrator  needs to give permission to individual users to submit
              jobs to a specific project. (see --aapprrjj option to _q_c_o_n_f(1)).

              If this option or a corresponding value  in  _q_m_o_n  is  specified
              then  this  value  will  be  passed  to defined JSV instances as
              parameter with the name oott.  (see --jjssvv option below or find more
              information concerning JSV in _j_s_v(1))

       --pp pprriioorriittyy
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r 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.  Grid Engine
              managers and administrators may also increase the priority asso-
              ciated  with  jobs.  If a pending job has higher priority, it is
              earlier eligible for being dispatched by the Grid Engine  sched-
              uler.

              If this option or a corresponding value in _q_m_o_n is specified and
              the priority is not 0 then this value will be passed to  defined
              JSV  instances  as  parameter with the name pp.  (see --jjssvv option
              below or find more information concerning JSV in _j_s_v(1))

       --ppee ppaarraalllleell__eennvviirroonnmmeenntt nn[[--[[mm]]]]||[[--]]mm,,......
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r only.

              Parallel programming environment (PE) to instantiate.  For  more
              detail about PEs, please see the _s_g_e___t_y_p_e_s(1).

              _Q_a_l_t_e_r  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 _q_m_o_n is specified
              then the parameters ppee__nnaammee, ppee__mmiinn and ppee__mmaaxx will be passed to
              configured  JSV  instances where ppee__nnaammee will be the name of the
              parallel environment and the values ppee__mmiinn and ppee__mmaaxx  represent
              the values n and m which have been provided with the --ppee option.
              A missing specification of m will be expanded as  value  9999999
              in  JSV scripts and it represents the value infinity.  (see --jjssvv
              option below or find more information concerning JSV in _j_s_v(1))

       --ppttyy yy[[eess]]||nn[[oo]]
              Available for _q_r_s_h and _q_l_o_g_i_n 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,  _q_r_s_h
              _w_i_t_h_o_u_t _a _c_o_m_m_a_n_d and _q_l_o_g_i_n start the job in a pty, _q_r_s_h _w_i_t_h _a
              _c_o_m_m_a_n_d starts the job without a pty.

              This parameter is not available in the JSV context.   (see  --jjssvv
              option below or find more information concerning JSV in _j_s_v(1))

       --qq wwcc__qquueeuuee__lliisstt
              Available for _q_s_u_b, _q_r_s_h, _q_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r.

              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  _w_c___q_u_e_u_e___l_i_s_t  in  _s_g_e___t_y_p_e_s(1).  This
              parameter has all the properties of a resource request and  will
              be merged with requirements derived from the --ll option described
              above.

              _Q_a_l_t_e_r 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 _q_m_o_n is specified the
              these  hard  and  soft  resource  requirements will be passed to
              defined JSV instances as parameters with the  names  qq__hhaarrdd  and
              qq__ssoofftt.  If  regular  expressions  will  be  used  for  resource
              requests, then these expressions will be  passed  as  they  are.
              Also  shortcut  names  will  not  be expanded.  (see --jjssvv option
              below or find more information concerning JSV in _j_s_v(1))

       --RR yy[[eess]]||nn[[oo]]
              Available for _q_s_u_b, _q_r_s_h, _q_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r.

              Indicates whether a reservation for this  job  should  be  done.
              Reservation  is never done for immediate jobs, i.e. jobs submit-
              ted using the --nnooww yyeess option.  Please note that  regardless  of
              the reservation request, job reservation might be disabled using
              max_reservation in _s_c_h_e_d___c_o_n_f(5) and might be limited only to  a
              certain number of high priority jobs.

              By default jobs are submitted with the --RR nn option.

              The  value specified with this option or the corresponding value
              specified in _q_m_o_n will only be passed to defined  JSV  instances
              if  the  value is _y_e_s.  The name of the parameter will be RR. The
              value will be yy also when then long form yyeess was specified  dur-
              ing submission.  (see --jjssvv option below or find more information
              concerning JSV in _j_s_v(1))

       --rr yy[[eess]]||nn[[oo]]
              Available for _q_s_u_b and _q_a_l_t_e_r only.

              Identifies the ability of a job to be  rerun  or  not.   If  the
              value  of  --rr  is  'yes',  the  job will be rerun if the job was
              aborted without leaving a consistent exit state.  (This is typi-
              cally the case if the node on which the job is running crashes).
              If --rr is 'no', the job will  not  be  rerun  under  any  circum-
              stances.
              Interactive  jobs  submitted  with  _q_s_h_,  _q_r_s_h or _q_l_o_g_i_n are not
              rerunnable.

              _Q_a_l_t_e_r allows changing this option even while the job  executes.

              The  value specified with this option or the corresponding value
              specified in _q_m_o_n will only be passed to defined  JSV  instances
              if  the  value is _y_e_s.  The name of the parameter will be rr. The
              value will be yy also when then long form yyeess was specified  dur-
              ing submission.  (see --jjssvv option below or find more information
              concerning JSV in _j_s_v(1))

       --sscc vvaarriiaabbllee[[==vvaalluuee]],,......
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r only.

              Sets the given name/value pairs as the job's context. VVaalluuee  may
              be  omitted.  Grid  Engine replaces the job's previously defined
              context with the one given as the argument.  Multiple --aacc,  --ddcc,
              and --sscc 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  variables  are  nnoott
              passed to the job's execution context in its environment.

              _Q_a_l_t_e_r  allows changing this option even while the job executes.

              The outcome of the evaluation of all --aacc, --ddcc, and  --sscc  options
              or  corresponding  values  in  _q_m_o_n  is  passed  to  defined JSV
              instances as parameter with the name aacc.  (see --jjssvv option below
              or find more information concerning JSV in _j_s_v(1))

       --sshheellll yy[[eess]]||nn[[oo]]
              Available only for _q_s_u_b.

              --sshheellll nn causes qsub to execute the command line directly, as if
              by _e_x_e_c(2).  No command shell will  be  executed  for  the  job.
              This  option only applies when --bb yy is also used.  Without --bb yy,
              --sshheellll nn 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  command  line
              parsing  is required. If the command line contains shell syntax,
              like environment variable  substitution  or  (back)  quoting,  a
              shell  must  be  started.   In  this  case either do not use the
              --sshheellll nn option or execute the shell as  the  command  line  and
              pass the path to the executable as a parameter.

              If  a  job executed with the --sshheellll nn option fails due to a user
              error, such as an invalid path to the executable, the  job  will
              enter the error state.

              --sshheellll  yy cancels the effect of a previous --sshheellll nn.  Otherwise,
              it has no effect.

              See --bb and --nnoosshheellll for more information.

              The value specified with this option or the corresponding  value
              specified  in  _q_m_o_n will only be passed to defined JSV instances
              if the value is _y_e_s.  The name of the parameter will  be  sshheellll.
              The  value  will be yy also when then long form yyeess was specified
              during submission.  (see --jjssvv option below or find more informa-
              tion concerning JSV in _j_s_v(1))

       --ssoofftt  Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r only.

              Signifies  that  all resource requirements following in the com-
              mand line will be soft requirements and are to be filled  on  an
              "as available" basis.
              As  Grid  Engine scans the command line and script file for 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  --ssoofftt
              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 --hhaarrdd flag (see
              above) is encountered at a later stage of the scan, all resource
              requests  following  it once again become "essential". The --hhaarrdd
              and --ssoofftt options in effect act as "toggles" during the scan.

              If this option or a corresponding value  in  _q_m_o_n  is  specified
              then  the  corresponding --qq and --ll resource requirements will be
              passed to defined JSV instances  as  parameter  with  the  names
              qq__ssoofftt and ll__ssoofftt. Find for information in the sections describ-
              ing --qq and --ll.  (see --jjssvv option below or find more  information
              concerning JSV in _j_s_v(1))

       --ssyynncc yy[[eess]]||nn[[oo]]
              Available for _q_s_u_b.

              --ssyynncc yy causes _q_s_u_b to wait for the job to complete before exit-
              ing.  If the job completes successfully, _q_s_u_b_'_s exit  code  will
              be that of the completed job.  If the job fails to complete suc-
              cessfully, _q_s_u_b will print out a error  message  indicating  why
              the  job  failed  and  will  have an exit code of 1.  If _q_s_u_b is
              interrupted, e.g. with CTRL-C, before the job completes, the job
              will be canceled.
              With  the  --ssyynncc nn option, _q_s_u_b will exit with an exit code of 0
              as soon as the  job  is  submitted  successfully.   --ssyynncc  nn  is
              default for _q_s_u_b.
              If  --ssyynncc yy is used in conjunction with --nnooww yy, _q_s_u_b will behave
              as though only --nnooww yy were given until the job has been success-
              fully  scheduled,  after  which  time _q_s_u_b will behave as though
              only --ssyynncc yy were given.
              If --ssyynncc yy is used in conjunction with --tt nn[[--mm[[::ii]]]],  _q_s_u_b  will
              wait for all the job's tasks to complete before exiting.  If all
              the job's tasks complete successfully, _q_s_u_b_'_s 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, _q_s_u_b will print
              out an error message indicating why the job task(s)  failed  and
              will  have an exit code of 1.  If _q_s_u_b 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 submission is
              not available in the JSV context.  (see  --jjssvv  option  below  or
              find more information concerning JSV in _j_s_v(1))

       --SS [[[[hhoossttnnaammee]]::]]ppaatthhnnaammee,,......
              Available for _q_s_u_b, _q_s_h and _q_a_l_t_e_r.

              Specifies  the interpreting shell for the job. Only one ppaatthhnnaammee
              component without a hhoosstt specifier is valid and  only  one  path
              name  for a given host is allowed. Shell paths with host assign-
              ments define the interpreting 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 envi-
              ronment variables as described for the --ee option above.

              In the case of _q_s_h the specified shell path is used  to  execute
              the  corresponding  command interpreter in the _x_t_e_r_m(1) (via its
              _-_e option) started on behalf of  the  interactive  job.   _Q_a_l_t_e_r
              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 _q_m_o_n is specified
              then this value will be  passed  to  defined  JSV  instances  as
              parameter  with the name SS.  (see --jjssvv option below or find more
              information concerning JSV in _j_s_v(1))

       --tt nn[[--mm[[::ss]]]]
              Available for _q_s_u_b and _q_a_l_t_e_r only.

              Submits a so called _A_r_r_a_y _J_o_b, i.e. an array of identical  tasks
              being  differentiated  only by an index number and being treated
              by Grid Engine almost like a series of jobs. The option argument
              to --tt specifies the number of array job tasks and the index num-
              ber which will be associated with the tasks. The  index  numbers
              will  be  exported to the job tasks via the environment variable
              GGEE__TTAASSKK__IIDD. The option arguments n, m and s  will  be  available
              through  the  environment  variables GGEE__TTAASSKK__FFIIRRSSTT, GGEE__TTAASSKK__LLAASSTT
              and  GGEE__TTAASSKK__SSTTEEPPSSIIZZEE.

              Following restrictions apply to the values n and m:

                     1 <= n <= MIN(2^31-1, max_aj_tasks)
                     1 <= m <= MIN(2^31-1, max_aj_tasks)
                     n <= m

              _m_a_x___a_j___t_a_s_k_s  is  defined  in  the  cluster  configuration  (see
              _s_g_e___c_o_n_f(5))

              The task id range specified in the option argument may be a sin-
              gle number, a simple range of the form n-m or  a  range  with  a
              step  size.  Hence,  the task id range specified 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 GE_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 _q_s_u_b or _q_a_l_t_e_r command
              line, except for the --tt option. The tasks are scheduled indepen-
              dently  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
              _q_m_o_d(1) or _q_d_e_l(1).  See the corresponding manual pages for fur-
              ther detail.

              Array  jobs are commonly used to execute the same type of opera-
              tion 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 dif-
              ferent files with the default location

              <jobname>.['e'|'o']<job_id>'.'<task_id>

              In order to change this default, the  --ee  and  --oo  options  (see
              above)  can  be  used together with the pseudo environment vari-
              ables  $HOME,  $USER,   $JOB_ID,   $JOB_NAME,   $HOSTNAME,   and
              $GE_TASK_ID.

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

              If  this  option  or  a corresponding value in _q_m_o_n is specified
              then this value will be  passed  to  defined  JSV  instances  as
              parameters  with  the  name  tt__mmiinn,  tt__mmaaxx  and tt__sstteepp (see --jjssvv
              option below or find more information concerning JSV in _j_s_v(1))



       --tteerrssee
              Available for _q_s_u_b only.

              -terse causes the _q_s_u_b 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 _q_s_u_b  output
              to get the job-id.

              Information  that this switch was specified during submission is
              not available in the JSV context.  (see  --jjssvv  option  below  or
              find more information concerning JSV in _j_s_v(1))

       --uu uusseerrnnaammee,,......
              Available  for  _q_a_l_t_e_r only. Changes are only made on those jobs
              which were submitted by users specified in  the  list  of  user-
              names.   For  managers  it  is possible to use the qqaalltteerr --uu ''**''
              command to modify all jobs of all users.

              If you use the --uu switch it is not permitted to specify an addi-
              tional _w_c___j_o_b___r_a_n_g_e___l_i_s_t.

       --vv vvaarriiaabbllee[[==vvaalluuee]],,......
              Available for _q_s_u_b, _q_r_s_h (with command argument) and _q_a_l_t_e_r.

              Defines or redefines the environment variables to be exported to
              the execution context of the job.  If the --vv option  is  present
              Grid  Engine will add the environment variables defined as argu-
              ments to the switch and, optionally, values of  specified  vari-
              ables, to the execution context of the job.

              _Q_a_l_t_e_r  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 --vv, --VV or the DISPLAY
              variable provided with --ddiissppllaayy will be exported to the  defined
              JSV  instances only optionally when this is requested explicitly
              during the job submission verification.  (see --jjssvv option  below
              or find more information concerning JSV in _j_s_v(1))

       --vveerrbboossee
              Available only for _q_r_s_h and _q_m_a_k_e(1).

              Unlike  _q_s_h  and  _q_l_o_g_i_n, _q_r_s_h does not output any informational
              messages while establishing  the  session,  compliant  with  the
              standard _r_s_h(1) and _r_l_o_g_i_n(1) system calls.  If the option --vveerr--
              bboossee is set, _q_r_s_h behaves like  the  _q_s_h  and  _q_l_o_g_i_n  commands,
              printing  information  about  the  process  of  establishing the
              _r_s_h(1) or _r_l_o_g_i_n(1) session.

       --vveerriiffyy
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r.

              Instead of submitting a job, prints detailed  information  about
              the  would-be job as though _q_s_t_a_t(1) -j were used, including the
              effects of command-line parameters and the external environment.

       --VV     Available for _q_s_u_b, _q_s_h, _q_r_s_h _w_i_t_h _c_o_m_m_a_n_d and _q_a_l_t_e_r.

              Specifies  that all environment variables active within the _q_s_u_b
              utility be exported to the context of the job.

              All environment variables specified with --vv, --VV or  the  DISPLAY
              variable  provided with --ddiissppllaayy will be exported to the defined
              JSV instances only optionally when this is requested  explicitly
              during  the job submission verification.  (see --jjssvv option below
              or find more information concerning JSV in _j_s_v(1))

       --ww ee|ww|nn|pp|vv
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n and _q_a_l_t_e_r.

              Specifies a validation level applied to the job to be  submitted
              (_q_s_u_b,  _q_l_o_g_i_n,  and  _q_s_h) or the specified queued job (_q_a_l_t_e_r).
              The information displayed indicates whether the job can possibly
              be  scheduled  assuming  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  validation
              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
                   _q_s_u_b, _q_a_l_t_e_r, _q_r_s_h, _q_s_h
                   and _q_l_o_g_i_n.
              `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 consuming 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 possi-
              ble to specify non-volatile values (non-consumables) or  maximum
              values (consumables) in complex_values.

       --wwdd wwoorrkkiinngg__ddiirr
              Available for _q_s_u_b, _q_s_h, _q_r_s_h and _q_a_l_t_e_r only.

              Execute  the  job  from  the directory specified in working_dir.
              This switch will activate Grid Engine's path aliasing  facility,
              if  the  corresponding  configuration  files  are  present  (see
              _g_e___a_l_i_a_s_e_s(5)).

              _Q_a_l_t_e_r 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
              ccwwdd (see --ccwwdd switch above or find more  information  concerning
              JSV in _j_s_v(1))

       ccoommmmaanndd
              Available for _q_s_u_b and _q_r_s_h only.

              The  job's scriptfile or binary.  If not present or if the oper-
              and is the single-character string '-', _q_s_u_b  reads  the  script
              from standard input.

              The command will be available in defined JSV instances as param-
              eter with the name CCMMDDNNAAMMEE (see --jjssvv option below or  find  more
              information concerning JSV in _j_s_v(1))

       ccoommmmaanndd__aarrggss
              Available for _q_s_u_b, _q_r_s_h and _q_a_l_t_e_r only.

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

              _Q_a_l_t_e_r 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  configured  JSV
              instances  as parameter with the name CCMMDDAARRGGSS. Also the argument
              values  can  by  accessed.  Argument  names  have   the   format
              CCMMDDAARRGG<<nnuummbbeerr>> where <<nnuummbbeerr>> is a integer between 0 and CCMMDDAARRGGSS
              - 1.  (see --jjssvv option below or find more information concerning
              JSV in _j_s_v(1))

       xxtteerrmm__aarrggss
              Available for _q_s_h only.

              Arguments to the _x_t_e_r_m(1) executable, as defined in the configu-
              ration.  For details, refer to _g_e___c_o_n_f(5)).

              Information concerning xxtteerrmm__aarrggss will be available in JSV  con-
              text  as  parameters  with  the name CCMMDDAARRGGSS and CCMMDDAARRGG<<nnuummbbeerr>>.
              Find more information above in section ccoommmmaanndd__aarrggss.  (see  --jjssvv
              option below or find more information concerning JSV in _j_s_v(1))

EENNVVIIRROONNMMEENNTTAALL VVAARRIIAABBLLEESS
       GGEE__RROOOOTT        Specifies  the location of the Grid Engine standard con-
                      figuration files.

       GGEE__CCEELLLL        If set, specifies  the  default  Grid  Engine  cell.  To
                      address  a  Grid Engine cell _q_s_u_b, _q_s_h, _q_l_o_g_i_n or _q_a_l_t_e_r
                      use (in the order of precedence):

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

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


       GGEE__DDEEBBUUGG__LLEEVVEELL If set, specifies that debug information should be writ-
                      ten to stderr. In addition the level of detail in  which
                      debug information is generated is defined.

       GGEE__QQMMAASSTTEERR__PPOORRTT
                      If set, specifies the tcp port on which _g_e___q_m_a_s_t_e_r(8) is
                      expected to listen  for  communication  requests.   Most
                      installations will use a services map entry for the ser-
                      vice "sge_qmaster" instead to define that port.

       DISPLAY        For _q_s_h jobs the DISPLAY has to be specified at job sub-
                      mission.   If  the DISPLAY is not set by using the --ddiiss--
                      ppllaayy or the --vv switch, the contents of the DISPLAY envi-
                      ronment variable are used as default.

       In  addition to those environment variables specified to be exported to
       the job via the --vv or the --VV option (see above) _q_s_u_b, _q_s_h,  and  _q_l_o_g_i_n
       add  the  following variables with the indicated values to the variable
       list:


       GGEE__OO__HHOOMMEE      the home directory of the submitting client.

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

       GGEE__OO__LLOOGGNNAAMMEE   the LOGNAME of the submitting client.

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

       GGEE__OO__PPAATTHH      the executable search path of the submitting client.

       GGEE__OO__SSHHEELLLL     the SHELL of the submitting client.

       GGEE__OO__TTZZ        the time zone of the submitting client.

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

       Furthermore, Grid Engine sets additional variables into the job's envi-
       ronment, as listed below.

       ARC

       SGE_ARCH       The Grid Engine architecture name of the node  on  which
                      the  job  is  running.  The name is compiled-in into the
                      _g_e___e_x_e_c_d(8) binary.

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

       GE_CKPT_DIR    Only set for checkpointing jobs. Contains path  _c_k_p_t___d_i_r
                      (see _c_h_e_c_k_p_o_i_n_t(5) ) of the checkpoint interface.

       GE_STDERR_PATH the  pathname  of  the  file to which the standard error
                      stream of the job is diverted. Commonly used for enhanc-
                      ing  the output with error messages from prolog, epilog,
                      parallel   environment   start/stop   or   checkpointing
                      scripts.

       GE_STDOUT_PATH the  pathname  of  the file to which the standard output
                      stream of the job is diverted. Commonly used for enhanc-
                      ing the output with messages from prolog, epilog, paral-
                      lel environment start/stop or checkpointing scripts.

       GE_STDIN_PATH  the pathname of the file from which the  standard  input
                      stream  of the job is taken. This variable might be used
                      in combination with GE_O_HOST in  prolog/epilog  scripts
                      to transfer the input file from the submit to the execu-
                      tion host.

       GE_JOB_SPOOL_DIR
                      The  directory  used  by  _g_e___s_h_e_p_h_e_r_d(8)  to  store  job
                      related  data  during  job  execution. This directory is
                      owned by root or by a Grid Engine administrative account
                      and  commonly  is  not  open for read or write access to
                      regular users.

       GE_TASK_ID     The index number of the current array job task  (see  --tt
                      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  possible  to
                      change  the predefined value of this variable with --vv or
                      --VV (see options above).

       GE_TASK_FIRST  The index number of the first array  job  task  (see  --tt
                      option  above).  It is possible to change the predefined
                      value of this  variable  with  --vv  or  --VV  (see  options
                      above).

       GE_TASK_LAST   The  index  number  of  the  last array job task (see --tt
                      option above). It is possible to change  the  predefined
                      value  of  this  variable  with  --vv  or  --VV (see options
                      above).

       GE_TASK_STEPSIZE
                      The step size of the array  job  specification  (see  --tt
                      option  above).  It is possible to change the predefined
                      value of this  variable  with  --vv  or  --VV  (see  options
                      above).

       ENVIRONMENT    The  ENVIRONMENT  variable  is  set to BATCH to identify
                      that the job is being executed under  Grid  Engine  con-
                      trol.

       HOME           The  user's home directory path from the _p_a_s_s_w_d(5) file.

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

       JOB_ID         A unique identifier assigned by the  _g_e___q_m_a_s_t_e_r(8)  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 submitted by  _q_r_s_h
                      with a command, the job name is built as basename of the
                      _q_s_u_b script filename resp. the _q_r_s_h command.  For inter-
                      active  jobs  it  is  set to `INTERACTIVE' for _q_s_h jobs,
                      `QLOGIN' for _q_l_o_g_i_n jobs and  `QRLOGIN'  for  _q_r_s_h  jobs
                      without a command.

                      This default may be overwritten by the _-_N_.  option.

       LOGNAME        The user's login name from the _p_a_s_s_w_d(5) 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 parallel job.

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

       SGE_BINARY_PATH
                      The path where the Grid Engine binaries  are  installed.
                      The value is the concatenation of the cluster configura-
                      tion  value  bbiinnaarryy__ppaatthh  and  the   architecture   name
                      $$SSGGEE__AARRCCHH 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 vir-
                      tual parallel machine assigned to a parallel job by Grid
                      Engine. See the description of the $$ppee__hhoossttffiillee  parame-
                      ter  in _g_e___p_e(5) for details on the format of this file.
                      The environment variable is only available for  parallel
                      jobs.

       QUEUE          The  name  of the cluster queue in which the job is run-
                      ning.

       REQUEST        Available for batch jobs only.

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

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

       SHELL          The  user's  login  shell from the _p_a_s_s_w_d(5) file. NNoottee::
                      This is not necessarily the shell in use for the job.

       TMPDIR         The absolute path to the job's temporary working  direc-
                      tory.

       TMP            The same as TMPDIR; provided for compatibility with NQS.

       TZ             The time zone variable imported from _g_e___e_x_e_c_d(8) if set.

       USER           The user's login name from the _p_a_s_s_w_d(5) file.

RREESSTTRRIICCTTIIOONNSS
       There  is no controlling terminal for batch jobs under Grid Engine, and
       any tests or actions on a controlling  terminal  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 "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.

EEXXIITT SSTTAATTUUSS
       The following exit values are returned:

       0    Operation was executed successfully.

       25   It was not possible to register a new job according to the config-
            ured  _m_a_x___u___j_o_b_s  or _m_a_x___j_o_b_s limit. Additional information may be
            found in _s_g_e___c_o_n_f(5)

       >0   Error occurred.

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

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


       #!/bin/csh
          a.out


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

       The next example is a more complex 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

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


FFIILLEESS
       _$_R_E_Q_U_E_S_T_._o_J_I_D_[_._T_A_S_K_I_D_]      STDOUT of job #JID
       _$_R_E_Q_U_E_S_T_._e_J_I_D_[_._T_A_S_K_I_D_]      STDERR of job
       _$_R_E_Q_U_E_S_T_._p_o_J_I_D_[_._T_A_S_K_I_D_]     STDOUT of par. env. of job
       _$_R_E_Q_U_E_S_T_._p_e_J_I_D_[_._T_A_S_K_I_D_]     STDERR of par. env. of job

       _$_c_w_d_/_._g_e___a_l_i_a_s_e_s        cwd path aliases
       _$_c_w_d_/_._g_e___r_e_q_u_e_s_t        cwd default request
       _$_H_O_M_E_/_._g_e___a_l_i_a_s_e_s       user path aliases
       _$_H_O_M_E_/_._g_e___r_e_q_u_e_s_t       user default request
       _<_g_e___r_o_o_t_>_/_<_c_e_l_l_>_/_c_o_m_m_o_n_/_g_e___a_l_i_a_s_e_s
                               cluster path aliases
       _<_g_e___r_o_o_t_>_/_<_c_e_l_l_>_/_c_o_m_m_o_n_/_g_e___r_e_q_u_e_s_t
                               cluster default request
       _<_g_e___r_o_o_t_>_/_<_c_e_l_l_>_/_c_o_m_m_o_n_/_a_c_t___q_m_a_s_t_e_r
                               Grid Engine master host file

SSEEEE AALLSSOO
       _g_e___i_n_t_r_o(1), _q_c_o_n_f(1), _q_d_e_l(1), _q_h_o_l_d(1), _q_m_o_d(1),  _q_r_l_s(1),  _q_s_t_a_t(1),
       _a_c_c_o_u_n_t_i_n_g(5), _g_e___a_l_i_a_s_e_s(5), _g_e___c_o_n_f(5), _g_e___r_e_q_u_e_s_t(5), _g_e___p_e(5), _c_o_m_-
       _p_l_e_x(5).

CCOOPPYYRRIIGGHHTT
       If configured correspondingly, _q_r_s_h and _q_l_o_g_i_n contain portions of  the
       _r_s_h,  _r_s_h_d,  _t_e_l_n_e_t  and _t_e_l_n_e_t_d code copyrighted by The Regents of the
       University of California.  Therefore, the following note  applies  with
       respect to _q_r_s_h and _q_l_o_g_i_n: This product includes software developed by
       the University of California, Berkeley and its contributors.

       See   _g_e___i_n_t_r_o(1)   as   well   as   the   information   provided    in
       <ge_root>/3rd_party/qrsh and <ge_root>/3rd_party/qlogin for a statement
       of further rights and permissions.



GE 6.2u2                 $Date: 2009/01/12 14:18:39 $                SUBMIT(1)
