After submission, a request is routed to a batch queue. The request then waits in the batch queue until the NQS system is ready to execute it. While a request is being routed by a pipe queue or is waiting to execute in a batch queue, you can delete it in the following ways:

To delete a request, you must be validated using the same method that is used for submitting requests. For further information about passwords and validation files, see Chapter 2, “Preparing to Use NQE”.

If the UNICOS multilevel security (MLS) feature or the UNICOS/mk security enhancements are enabled on your system and NQS is configured to enforce mandatory access controls (MAC), your active label must equal the job submission label if your job is queued; your active label must equal the job execution label if your job is executing. If you specified the -C or -L options on the cqsub or qsub command line or specified an alternative active security compartment or level by selecting Submit -> Configure -> General Options when the job was submitted, the job execution label may not be the same as the job submission label. To display the job submission and execution label information for a specific job, you can use either the cqstatl -f or qstat -f command, or you can select Status -> Actions -> Detailed Job Status. NQS managers and operators bypass the MAC checks.

Using the NQE GUI

You can use the procedure described in this section to delete a request that was sent to NQS or a request that was sent to the NQE database. You can delete a request by selecting Delete Job on the Actions menu of the NQE GUI Status window.

---

Note: You can use the NQE GUI to delete a request whether or not the request is executing.

---

If your site uses password validation, you must either set the NQS_PASSWORD_NEEDED environment variable or, in the NQE GUI Submit window, select Set Password on the Actions menu to ensure that you are prompted for a password; otherwise, your request will not execute. The password you supply is for the user name under which the request will execute.

After you submitted the request to be executed, you received a response similar to one of the following:

• If you submitted your request to NQS, you received a response similar to the following:

  Request 46.latte submitted to queue: nqenlb

  
  

• If you submitted your request to the NQE database, you received a response similar to the following:

  Task id t4 inserted into database nqedb

  
  

To display its status, use the NQE GUI Status window. See Figure 12-1 for a sample NQE GUI Status window. The Location column of the display shows requests submitted to NQS (in the format of queue@host) and requests submitted to the NQE database (in the format of nqe_database).

Figure 12-1. NQE GUI Status Window Example

Highlight the request in the job summary area, select the Actions menu, and then select Delete Job, which deletes the currently selected request from the job summary area. You will receive a response stating that your request was deleted.

For a summary of the NQE GUI Status options, see the nqe(1) man page.

Using the cqdel Command or the qdel Command to Delete a Request Not Executing

You can use only the cqdel command to delete a request from the NQE database. To use the cqdel or qdel command to delete a request that was sent to a specific destination, provide the NQE database task ID (for cqdel only) or the NQS request ID on the command line. For example, to delete request 46.latte that was sent to NQS, you would enter the following command:

% cqdel -d nqs 46.latte Request 46.latte has been deleted.

If a request has already begun execution, the following message is displayed when you issue the cqdel command:

% cqdel -d nqs 5167.sequoia QUESR: ERROR: Failed to delete request "5167.sequoia" QUESR: ERROR: Request is running at transaction peer

The cqdel command or qdel command used without options does not affect an executing request. You can delete the request by using the NQE GUI Status window, as described in “Using the NQE GUI”, or you can signal the request by using the cqdel -k command or the qdel -k command, as described in “Using the cqdel Command or qdel Command to Delete an Executing Request”.

---

Note: If your site uses password validation, you must include the cqdel -P option or set the NQS_PASSWORD_NEEDED environment variable to ensure that you are prompted for a password. The password you supply is for the user name under which the request will execute.

---

For a summary of the cqdel and qdel command options, see the cqdel(1) and qdel(1) man pages.

Using the cqdel Command or qdel Command to Delete an Executing Request

If you use the NQE GUI, the method described in “Using the NQE GUI Status Window” in Chapter 13, works whether or not the request is executing.

You can use only the cqdel command to delete a request from the NQE database. If you use the cqdel or qdel command to delete an executing request, you must send the request a signal by using one of the following command formats; separate a list of NQS request identifiers (requestids) or NQE database task identifiers (tids) with a space:

cqdel [{-k | -s sig_name | -signo } ] [requestids | tids]

qdel [ {-f | -k | -s sig_name | -signo } ] requestids

For example, to use the cqdel -k command to delete a request from the NQE database that has a task identifier of t135, you would enter the following command; the command deletes the request, but the task remains in the NQE database with a status of Terminated:

% cqdel -d nqedb -k t135 NQE Task "t135" has been signalled (Acknowledged).

---

Note: If your site uses password validation, you must include the cqdel -P option or set the NQS_PASSWORD_NEEDED environment variable to ensure that you are prompted for a password. The password you supply is for the user name under which the request will execute.

---

You can specify the qdel -f command to delete both a request and the job output.

For a summary of cqdel and qdel command options, see the cqdel(1) and qdel(1) man pages.

The following screens show the submission and signaling of a request in an NQS queue. In this example, the request is submitted using the cqsub command:

% cqsub -q nqebatch t1 Request 21.carob submitted to queue: nqebatch

Next, the NQE GUI Status window is used to display its status, as shown in Figure 12-2:

Figure 12-2. NQE GUI Status Window Example

Then the executing request is signaled (deleted):

% cqdel -k 21.carob Request 21.carob is running and has been signaled.

If a request has been routed to a queue at a server not on your local NQS server (which is defined in NQS_SERVER), you can delete it by using either the NQE GUI Status window or the cqdel command or qdel command to delete or signal it.

---

Note: If your request was submitted to the NQE database, delete the request by selecting Delete Job on the Actions menu of the NQE GUI Status window as described in “Using the NQE GUI”.

---

If you are using the NQE GUI, to delete a request on another NQS server, select Delete Job on the Actions menu of the NQE GUI Status window as described in “Using the NQE GUI”.

If you use the cqdel or qdel command, you must specify the name of the NQS server as part of the command line. You can do this by using one of the following command options:

-h target_host requestids
request@hostname ...

For example, either of the following commands deletes a request that currently resides on a remote server named peat but was originally submitted at a local system called coal:

cqdel -h peat 450.coal
cqdel [email protected]

If password validation is enforced at the local system, you will be prompted for a password. The password requested is for the user name at the remote host under whom the request will execute. If both password validation and validation files are in force at the remote system, you can simply press RETURN when prompted for a password; the validation file is then checked. If validation files are checked, the qdel command will be successful only if your user name is included in a validation file at the remote system. For more information about passwords and validation files, see Chapter 2, “Preparing to Use NQE”.

If the UNICOS MLS feature or the UNICOS/mk security enhancements are enabled on a remote system, you cannot delete a request at the remote host if the host has a workstation access list (WAL) entry for the host of origin that restricts your access to NQS services.

Deleting requests requires the same validation that is used for submitting requests. NQS will then search for a validation file. For NQE database requests, you can delete only requests that were submitted with your database user name. For more information on NQS validation, see Chapter 2, “Preparing to Use NQE”.

If you use the NQE GUI, you can delete a request by selecting Delete Job on the Actions menu of the NQE GUI Status window as described in “Using the NQE GUI”.

If you use the cqdel or qdel command to delete requests owned by another user, you can use the following command formats:

cqdel -d dest_type -u username [requestids | tids]

qdel -u username requestids

The username is the name of the user specified by the -u option.

In the following example, the cqdel command deletes a request that has identifier 1173.coal submitted by sandy (assuming you are authorized correctly):

cqdel -d nqs -u sandy 1173.coal

The following cqdel command deletes a request that was sent to the NQE database; the request has a task identifier of t100 and was submitted by the NQE database user name sandy (assuming you are authorized correctly):

cqdel -d nqedb -u dbuser=sandy t100

In the following example, if you are logged in as user sam to a UNICOS operating system called coal and want to delete a request submitted by a user called sandy, the following entry must be in the .rhosts or .nqshosts file in the home directory of sandy:

coal sam

If this entry exists, the following qdel command deletes a request submitted by sandy that has the identifier 1173.coal :

qdel -u sandy 1173.coal

The -u option may not be valid for remote requests that use file validation on UNICOS MLS or on UNICOS/mk security-enhanced systems. When the UNICOS MLS feature or the UNICOS/mk security enhancements are enabled on your system, the system might be configured to require the/etc/hosts.equiv and .rhosts files to each contain a match for the remote host and to require that the remote user and local user names match (that is, the -u option is not allowed).