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   and  qqllooggiinn__ccoommmmaanndd  in the global and local configuration
       settings of _s_g_e___c_o_n_f(5).

       On the server-side, an Grid Engine _t_e_l_n_e_t_d is used if the parameter  is
       not   set.   Otherwise,   it   should   be   set   to   something  like
       /usr/sbin/in.telnetd.  On the client side, an  Grid  Engine  _t_e_l_n_e_t  is
       used  it the parameter is not set. Otherwise, it should be set to some-
       thing like /usr/bin/telnet.

       The client side command is automatically parameterized with the  remote
       host  name and port number to which to connect, resulting in an invoca-
       tion 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
       _s_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 _s_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 _s_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 _s_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 _q_a_l_t_e_r_.

       _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.  The
       only  modification to the copied jobs supported by _q_r_e_s_u_b is assignment
       of a 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 user with manager privileges can use _q_r_e_s_u_b on jobs submitted by
       another user.  Regular 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 _s_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
       $SGE_ROOT/$SGE_CELL/common/sge_request.  User private  default  request
       files   are   processed  under  the  locations  $HOME/.sge_request  and
       $cwd/.sge_request. The working 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],
              where:

              CC  denotes the century in 2 digits.
              YY  denotes the year in 2 digits.
              MM  denotes the month in 2 digits.
              DD  denotes the day in 2 digits.
              hh  denotes the hour in 2 digits.
              mm  denotes the minute in 2 digits.
              ss  denotes the seconds in 2 digits (default 00).

              If any of the optional date fields is omitted, the corresponding
              value  of the current date is assumed. If CC is not specified, a
              YY of < 70 means 20YY.
              Usage of this option may cause unexpected results if the  clocks
              of  the hosts in the Grid Engine pool are out of sync. Also, the
              proper behavior of this option very much depends on the  correct
              setting  of the appropriate timezone, e.g. in the TZ environment
              variable (see _d_a_t_e(1) for details), when the Grid Engine daemons
              _s_g_e___q_m_a_s_t_e_r(8) and _s_g_e___e_x_e_c_d(8) are invoked.

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

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

              _q_a_l_t_e_r allows changing this option even while the job  executes.

       --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 may be  any  arbitrary
              ASCII alphanumeric string but may not contain  "\n", "\t", "\r",
              "/", ":", "@", "\", "*",  or "?".  In the absence of this param-
              eter  Grid Engine will place the default account string "sge" in
              the accounting record of the job.

              _q_a_l_t_e_r allows changing this option even while the job  executes.

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

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

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

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

       --CC pprreeffiixx__ssttrriinngg
              Available for _q_s_u_b and qrsh with script submission (-b n).

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

       --ddiissppllaayy ddiissppllaayy__ssppeecciiffiieerr
              Available for _q_s_h only.

              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.

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

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

              The  tilde  sign ("~")  can be  used as an alternative to $HOME,
              as is common in _c_s_h(1) or _k_s_h(1).  Note, that the "~" sign  also
              works  in combination 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.

       --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 resource requirements following in  the  com-
              mand  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.

       --hh || --hh {{uu||ss||oo||nn||UU||OO||SS}}......
              Available for _q_s_u_b, _q_s_h, _q_r_s_h, _q_l_o_g_i_n, _q_a_l_t_e_r and _q_r_e_s_u_b.

              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.

              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 an 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 is execut-
              ing. The modified parameter will  only  be  in  effect  after  a
              restart or migration of the job, however.

       --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 550044

              DDeeffiinneess oorr rreeddeeffiinneess tthhee jjoobb ddeeppeennddeennccyy lliisstt  ooff  tthhee  ssuubbmmiitttteedd
              jjoobb..  AA rreeffeerreennccee bbyy jjoobb nnaammee oorr ppaatttteerrnn iiss oonnllyy aacccceepptteedd iiff tthhee
              rreeffeerreenncceedd jjoobb iiss oowwnneedd bbyy tthhee ssaammee uusseerr aass tthhee  rreeffeerrrriinngg  jjoobb..
              TThhee  ssuubbmmiitttteedd jjoobb iiss nnoott eelliiggiibbllee ffoorr eexxeeccuuttiioonn uunnlleessss aallll jjoobbss
              rreeffeerreenncceedd iinn tthhee ccoommmmaa--sseeppaarraatteedd jjoobb iidd aanndd//oorr  jjoobb  nnaammee  lliisstt
              hhaavvee  ccoommpplleetteedd..   IIff aannyy ooff tthhee rreeffeerreenncceedd jjoobbss eexxiittss wwiitthh eexxiitt
              ccooddee 110000,, tthhee ssuubbmmiitttteedd jjoobb wwiillll rreemmaaiinn  iinneelliiggiibbllee  ffoorr  eexxeeccuu--
              ttiioonn..

              WWiitthh  tthhee hheellpp ooff jjoobb nnaammeess oorr rreegguullaarr ppaatttteerrnn oonnee ccaann ssppeecciiffyy aa
              jjoobb ddeeppeennddeennccyy oonn mmuullttiippllee jjoobbss ssaattiissffyyiinngg tthhee  rreegguullaarr  ppaatttteerrnn
              oorr  oonn  aallll  jjoobbss wwiitthh tthhee rreeqquueesstteedd nnaammee.. TThhee nnaammee ddeeppeennddeenncciieess
              aarree rreessoollvveedd aatt ssuubbmmiitt ttiimmee aanndd ccaann oonnllyy bbee cchhaannggeedd vviiaa  qqaalltteerr..
              NNeeww  jjoobbss  oorr  nnaammee cchhaannggeess ooff ootthheerr jjoobbss wwiillll nnoott bbee ttaakkeenn iinnttoo
              aaccccoouunntt..

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

       --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 time the  job  runs  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.

       --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  SGE_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 SGE_QMASTER_PORT with the  option  "-v  SGE_QMASTER_PORT"
              either as a command argument or an embedded directive.

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

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

       --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 this option even while the job  executes.
              The modified parameter will only be in effect after a restart or
              migration of the job, however.

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

              By default, 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.

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

              _q_a_l_t_e_r allows changing this option even while the job  executes.

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

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

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

       --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 can be any printable set of  char-
              acters  except  "\n",  "\t",  "\r", "/", ":", "@", "\", "*", and
              "?", and it has to start with an alphabetic  character.  Invalid
              job names will be denied at submit 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.
              If _q_s_h or _q_l_o_g_i_n is run  without   the  --NN  option,  the  string
              `INTERACT' is assigned to the job.
              If  _q_r_s_h is run without the --NN option, 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.

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

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

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


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

              Start  parallel programming environment (PE). The range descrip-
              tor behind the PE name specifies the  number  of  parallel  pro-
              cesses  to  be  run.  Grid  Engine will allocate the appropriate
              resources as  available.  The  _s_g_e___p_e(5)  manual  page  contains
              information  about the definition of PEs and about how to obtain
              a list of currently valid PEs.
              You can specify a PE name which  uses  the  wildcard  character,
              "*".   Thus  the request "pvm*" will match any parallel environ-
              ment with a name starting with the string "pvm". In the case  of
              multiple  parallel  environments  whose  names  match  the  name
              string, the parallel environment with the most  available  slots
              is chosen.
              The  range  specification  is a list of range expressions of the
              form "n-m", where n and m are positive, non-zero integers.   The
              form "n" is equivalent to "n-n".  The form "-m" is equivalent to
              "1-m".  The form "n-" is equivalent to "n-infinity".  The  range
              specification  is  processed  as  follows: The largest number of
              queues requested is checked first. If enough queues meeting  the
              specified  attribute  list  are available, all are allocated. If
              not, the next smaller number of queues is checked, and so forth.
              If  additional  --ll options are present, they restrict the set of
              eligible queues for the parallel 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.

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

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

       --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 re-
              runnable.

              _q_a_l_t_e_r allows changing this option even while the job  executes.



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

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

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

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

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

       --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
              SSGGEE__TTAASSKK__IIDD. The option arguments n, m and s will  be  available
              through  the environment variables SSGGEE__TTAASSKK__FFIIRRSSTT, SSGGEE__TTAASSKK__LLAASSTT
              and  SSGGEE__TTAASSKK__SSTTEEPPSSIIZZEE.

              The 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
              SGE_TASK_ID containing one of the 5 index numbers.

              All array job tasks  inherit  the  same  resource  requests  and
              attribute definitions as specified in the _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.  An array job or  a  sub-array  can  be
              accessed, however,  as a single unit by commands like _q_m_o_d(1) or
              _q_d_e_l(1).  See the corresponding manual pages for further 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
              $SGE_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.



       --tteerrssee
              Available for _q_s_u_b only.

              Causes  _q_s_u_b to display only the job-id of the job being submit-
              ted 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.

       --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_s_h, _q_r_s_h 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.

       --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, this option prints detailed infor-
              mation 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 exter-
              nal 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, _q_a_l_t_e_r and _q_r_e_s_u_b.

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

       --ww ee|ww|nn|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; the default for _q_r_s_h, _q_s_h
                   and _q_l_o_g_i_n.
              `w'  warning - only a warning will be displayed
                   for invalid requests.
              `n'  none - switches off validation; the default for
                   _q_s_u_b and _q_a_l_t_e_r.
              `v'  verify - does not submit the job but prints an
                   extensive validation report.

              Note, that the necessary checks are  performance  consuming  and
              hence the checking is switched off by default.

              Note  also,  that the reasons for job requirements being invalid
              with respect to resource availability of queues are displayed in
              the  "--ww  vv" case using the format as described for the _q_s_t_a_t(1)
              --FF option (see description of FFuullll FFoorrmmaatt in section OOUUTTPPUUTT FFOORR--
              MMAATTSS of the _q_s_t_a_t(1) manual page.

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

       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.

       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.

       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 _s_g_e___c_o_n_f(5)).

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

       SSGGEE__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 SGE_CELL, if it is set.

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


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

       SSGGEE__QQMMAASSTTEERR__PPOORRTT
                      If set, specifies the tcp port on  which  _s_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:


       SSGGEE__OO__HHOOMMEE     the home directory of the submitting client.

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

       SSGGEE__OO__LLOOGGNNAAMMEE  the LOGNAME of the submitting client.

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

       SSGGEE__OO__PPAATTHH     the executable search path of the submitting client.

       SSGGEE__OO__SSHHEELLLL    the SHELL of the submitting client.

       SSGGEE__OO__TTZZ       the time zone of the submitting client.

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

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

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

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

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

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

       SGE_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 SGE_O_HOST in prolog/epilog scripts
                      to transfer the input file from the submit to the execu-
                      tion host.

       SGE_JOB_SPOOL_DIR
                      The  directory  used  by  _s_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.

       SGE_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).

       SGE_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).

       SGE_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).

       SGE_TASK_STEPSIZE
                      The  stepsize  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 _s_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 _s_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 _s_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
       _$_R_E_Q_U_E_S_T_._h_o_s_t_s_J_I_D_[_._T_A_S_K_I_D_]  hosts file of par. env. of job

       _$_c_w_d_/_._s_g_e___a_l_i_a_s_e_s        cwd path aliases
       _$_c_w_d_/_._s_g_e___r_e_q_u_e_s_t        cwd default request
       _$_H_O_M_E_/_._s_g_e___a_l_i_a_s_e_s       user path aliases
       _$_H_O_M_E_/_._s_g_e___r_e_q_u_e_s_t       user default request
       _$_S_G_E___R_O_O_T_/_$_S_G_E___C_E_L_L_/_c_o_m_m_o_n_/_s_g_e___a_l_i_a_s_e_s
                                cluster path aliases
       _$_S_G_E___R_O_O_T_/_$_S_G_E___C_E_L_L_/_c_o_m_m_o_n_/_s_g_e___r_e_q_u_e_s_t
                                cluster default request
       _$_S_G_E___R_O_O_T_/_$_S_G_E___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
       _s_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), _s_g_e___a_l_i_a_s_e_s(5), _s_g_e___c_o_n_f(5), _s_g_e___r_e_q_u_e_s_t(5),  _s_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   _s_g_e___i_n_t_r_o(1)   as   well   as   the   information   provided   in
       $SGE_ROOT/3rd_party/qrsh and $SGE_ROOT/3rd_party/qlogin for a statement
       of further rights and permissions.




GE 6.1                   $Date: 2007/07/19 08:17:16 $                SUBMIT(1)
