qlimit(1)


          qlimit - show supported batch limits, and shell strategy for
          the named host(s).

     SYNOPSIS
          qlimit [ -v ] [ host-name ... ]

     DESCRIPTION
          Qlimit displays the set of batch request resource limit
          types that can be directly enforced on the implied local
          host or named hosts, and also the batch request shell
          strategy defined for the implied local host or named hosts.

          If no host-names are given, then the information displayed
          is only relevant to the local host.  Otherwise, the
          supported batch request limits, and batch request shell
          strategy for each of the named hosts is displayed.

          The -v switch indicates that the version of the program is
          to be printed.

          NQS supports many batch request resource limit types that
          can be applied to an NQS batch request.  However, not all
          UNIX implementations are capable of supporting the rather
          extensive set of limit types that NQS provides.

          The set of limits applied to a batch request, is always
          restricted to the set of limits that can be directly
          supported by the underlying UNIX implementation.  If a batch
          request specifies a limit that cannot be enforced by the
          underlying UNIX implementation, then the limit is simply
          ignored, and the batch request will operate as though there
          were no limit (other than the obvious physical maximums),
          placed upon that resource type.

          When an attempt is made to queue a batch request, each
          limit-value specified by the request (that can also be
          supported by the local UNIX implementation), is compared
          against the corresponding limit-value as configured for the
          destination batch queue.  If the corresponding batch queue
          limit-value for all batch request limit-values is defined as
          unlimited, or is greater than or equal to the corresponding
          batch request limit-value, then the request can be
          successfully queued, provided that no other anomalous
          conditions occur.  For request infinity limit-values, the
          corresponding queue limit-value must also be configured as
          infinity.

          These resource limit checks are performed irrespective of
          the batch request arrival mechanism, either by a direct use
          of the qsub(1) command, or by the indirect placement of a
          batch request into a batch queue via a pipe queue.  It is
          queue if any of these resource limit checks fail.

          Finally, if a request fails to specify a limit-value for a
          resource limit type that is supported on the execution
          machine, then the corresponding limit-value as configured
          for the destination queue, becomes the limit-value for the
          unspecified request limit.

          Upon the successful queueing of a request in a batch queue,

          the set of limits under which the request will execute is
          frozen, and will not be modified by subsequent qmgr(1M)
          commands that alter the limits of the containing batch
          queue.

          As mentioned above, this command also displays the shell
          strategy as configured for the implied local host, or named
          hosts.  In the absence of a shell specification for a batch
          request, NQS must choose which shell should be used to
          execute that batch request.  NQS supports three different
          algorithms, or strategies to solve this problem that can be
          configured for each system by a system administrator,
          depending on the needs of the user's involved, and upon
          system performance criterion.

          The three possible shell strategies are called:

                    fixed,
                    free, and
                    login.

          These shell strategies respectively cause the configured
          fixed shell to be exec'd to interpret all batch requests,
          cause the user's login shell as defined in the password file
          to be exec'd which in turn chooses and spawns the
          appropriate shell for running the batch shell script, or
          cause only the user's login shell to be exec'd to interpret
          the script.

          A shell strategy of fixed means that the same shell as
          chosen by the system administrator, will be used to execute
          all batch requests.

          A shell strategy of free will run the batch request script
          exactly as would an interactive invocation of the script,
          and is the default NQS shell strategy.

          The strategies of fixed, and login exist for host systems
          that are short on available free processes.  In these two
          strategies, a single shell is exec'd, and that same shell is
          the shell that executes all of the commands in the batch
          request shell script.
          particular NQS system, then the "fixed" shell that will be
          used to run all batch requests at that host is displayed.

     SEE ALSO
          qdel(1), qdev(1), qpr(1), qstat(1), and qsub(1) in the NPSN
          UNIX System Programmer Reference Manual.
          qmgr(1M) in the NPSN UNIX System Administrator Reference
          Manual.

     NPSN HISTORY
          Origin: Sterling Software Incorporated

          May 1986 - Brent Kingsbury, Sterling Software
          Original release.

          August, 1994 - John Roman, Monsanto Company
          Version 3.36