qdel(1)


          qdel - delete or signal NQS request(s).

     SYNOPSIS
          qdel [ -k ] [ -r request-pattern [ -c ] ] [ -signo ] [ -u
          username ] [ -v ] request-id ...

     DESCRIPTION
          Qdel deletes all queued NQS requests whose respective
          request-id is listed on the command line.

          Alternatively, if the -r switch is used, the user can
          specifiy a request name pattern using grep style patterns.
          If the -r switch is used, the -c switch may be used to
          prompt the user for each match of the request pattern.  The
          user will be given the request name and will be prompted as
          to whether the job should be deleted or not, or if the user
          wishes to quit.  This is supported only for requests running
          on the local system.

          Additionally, if the flag -k is specified, then the default
          signal of SIGKILL (-9) is sent to any running request whose
          request-id is listed on the command line.  This will cause
          the receiving request to exit and be deleted.  If the flag
          -signo is present, then the specified signal is sent instead
          of the SIGKILL signal to any running request whose request-
          id is listed on the command line.  In the absence of the -k
          and - signo flags, qdel will not delete a running NQS
          request.

          To delete or signal an NQS request, the invoking user must
          be the owner; namely the submitter of the request.  The only
          exception to this rule occurs when the invoking user is the
          superuser, or has NQS operator privileges as defined in the
          NQS manager database.  Under these conditions, the invoker
          may specify the -u username flag which allows the invoker to
          delete or signal requests owned by the user whose account
          name is username.  When this form of the command is used,
          all request-ids listed on the command line are presumed to
          refer to requests owned by the specified user.

          An NQS request is always uniquely identified by its
          request-id, no matter where it is in the network of the
          machines running NQS.  A request-id is always of the form:
          seqno or seqno.hostname or seqno.hostname@hostname2 where
          hostname identifies the machine from whence the request was
          originally submitted, seqno identifies the sequence number
          assigned to the request on the originating host, and
          hostname2 identifies the host on which the request is
          running. Hostname2 is not required if the request is running
          on the local machine.  If the hostname portion of a
          request-id is omitted, then the local host is always

          The request-id of any NQS request is displayed when the
          request is first submitted (unless the silent mode of
          operation for the given NQS command was specified).  The
          user can also obtain the request-id of any request through
          the use of the qstat(1) command.

          The -v switch will print out the version of qdel.

     CAVEATS
          When an NQS request is signalled by the methods discussed
          above, the proper signal is sent to all processes comprising
          the NQS request that are in the same process group.
          Whenever an NQS request is spawned, a new process group is
          established for all processes in the request.  However,
          should one or more processes of the request successfully
          execute a setpgrp() system call, then such processes will
          not receive any signals sent by the qdel(1) command.  This
          can lead to "rogue" request processes which must be killed
          by other means such as the kill(1) command.  For the UNIX
          implementations that support the ability to "lock" a
          process, and all of its progeny into a process-group, NQS
          will exploit this capability to prevent processes from
          "escaping" in this manner.

     SEE ALSO
          qdev(1), qlimit(1), qpr(1), qstat(1), qsub(1),
          kill(2), setpgrp(2), signal(2) in the NPSN UNIX System
          Programmer Reference Manual.
          qmgr(1M) in the NPSN UNIX System Administrator Reference
          Manual.

     NPSN HISTORY
          Origin: Sterling Software Incorporated

          August 1985 - Brent Kingsbury, Sterling Software
          Original release.

          May 1986
          Second release.

          August 1994 - John Roman, Monsanto Company
          Release 3.36