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

       _Q_a_l_t_e_r can be used to change the attributes of pending jobs. For  array
       jobs  for which some of the tasks are be pending and others are running
       (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. 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 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 _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.   Speci-
              fies  the deadline initiation time in [[CC]YY]MMDDhhmm[.SS] for-
              mat (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 and _q_a_l_t_e_r only.

              Defines or redefines the path used for the standard error stream
              of  the  job. If the ppaatthh constitutes an absolute path name, the
              error-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 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 specified.

              By  default  the  file  name  for  standard  error  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.

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

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

              Defines  or  redefines  the job dependency list of the submitted
              job. A reference by job  name  or  regular  expression  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 ineligi-
              ble for execution.

              With the help of job names or regular expressions one can  spec-
              ify  a  job  dependency  on multiple jobs satisfying the regular
              expression 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.

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

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

              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.

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

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

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

       --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 tick-
              ets  for  the  specified  job.  Requires manager/operator privi-
              leges.

       --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.   Speci-
              fies  the project to which this job is assigned. The administra-
              tor 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.

              Parallel  programming environment (PE) to instantiate. The range
              descriptor behind the PE name specifies the number  of  parallel
              processes  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
              rerunnable.

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

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



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

       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.

       ARC

       SGE_ARCH       The  Grid  Engine architecture name of the node on which
                      the job is running. The name  is  compiled-in  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_>_/_<_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_>_/_<_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_>_/_<_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  state-
       ment of further rights and permissions.



GE 6.0                   $Date: 2005/11/23 21:49:50 $                SUBMIT(1)
