QJOB(1)

NAME
qjob - display status of NQS queues in a networked environment

SYNOPSIS
qjob

DESCRIPTION
Qjob displays the status of queues known to the Network Queueing System (NQS) as remote ones. The /etc/batchservers file should contain host names for machines currently in connection with the local host via pipe queues. Each entry consists of a line specifying the name of the machine. This file is normally created and maintained by NQS queue managers.

The current state of each NQS queue in the list of hosts is displayed. For each selected queue, qjob displays a queue header (information about the queue itself) followed by information about requests in the queue. qjob shows only those requests belonging to the invoker.

The queue header always includes the queue-name, queue type, queue status (see below), an indication of whether or not the queue is pipeonly (accepts requests from pipe queues only), and the number of requests in the queue.

Qjob displays the following information about a request: the request-name, the request-id, the owner, the relative request priority, and the current request state (see below). For running requests, the process group is also shown, as soon as this information becomes available to the local NQS daemon.

It must be understood that the relative ordering of requests within a queue does not always determine the order in which the requests will be run. The NQS request scheduler is allowed to make exceptions to the request ordering for the sake of efficient machine resource usage. However, requests appearing near the beginning of the queue have higher priority than requests appearing later, and will usually be run before requests appearing later on in the queue.

QUEUE STATE
The general state of a queue is defined by two principal properties of the queue.

The first property determines whether or not requests can be submitted to the queue. If they can, then the queue is said to be enabled. Otherwise the queue is said to be disabled. One of the words CLOSED, ENABLED, or DISABLED will appear in the queue status field to indicate the respective queue states of: enabled (with no local NQS daemon), enabled (and local NQS daemon is present), and disabled. Requests can only be submitted to the queue if the queue is enabled, and the local NQS daemon is present.

The second principal property of a queue determines if requests which are ready to run, but are not now presently running, will be allowed to run upon the completion of any currently running requests, and whether any requests are presently running in the queue.

If queued requests not already running are blocked from running, and no requests are presently executing in the queue, then the queue is said to be stopped. If the same situation exists with the difference that at least one request is running, then the queue is said to be stopping, where the requests presently executing will be allowed to complete execution, but no new requests will be spawned.

If queued requests ready to run are only prevented from doing so by the NQS request scheduler, and one or more requests are presently running in the queue, then the queue is said to be running. If the same circumstances prevail with the exception that no requests are presently running in the queue, then the queue is said to be inactive. Finally, if the NQS daemon for the local host upon which the queue resides is not running, but the queue would otherwise be in the state of running or inactive, then the queue is said to be shutdown. The queue states describing the second principal property of a queue are therefore respectively displayed as STOPPED, STOPPING, RUNNING, INACTIVE, and SHUTDOWN.

REQUEST STATE
The state of a request may be arriving, holding, waiting, queued, staging, routing, running, departing, or exiting. A request is said to be arriving if it is being enqueued from a remote host. Holding indicates that the request is presently prevented from entering any other state (including the running state), because a hold has been placed on the request. A request is said to be waiting if it was submitted with the constraint that it not run before a certain date and time, and that date and time have not yet arrived. Queued requests are eligible to proceed (by routing or running). When a request reaches the head of a pipe queue and receives service there, it is routing. A request is departing from the time the pipe queue turns to other work until the request has arrived intact at its destination. Staging denotes a batch request that has not yet begun execution, but for which input files are being brought on to the execution machine. A running request has reached its final destination queue, and is actually executing. Finally, exiting describes a batch request that has completed execution, and will exit from the system after the required output files have been returned (to possibly remote machines).

Imagine a batch request originating on a workstation, destined for the batch queue of a computation engine, to be run immediately. That request would first go through the states queued, routing, and departing in a local pipe queue. Then it would disappear from the pipe queue. From the point of view of a queue on the computation engine, the request would first be arriving, then queued, staging (if required by the batch request), running, and finally exiting. Upon completion of the exiting phase of execution, the batch request would disappear from the batch queue.

CAVEATS
NQS is not finished, and continues to undergo development. Some of the request states shown above may or may not be supported in your version of NQS.

SEE ALSO
qstat(1)

NPSN HISTORY
Origin: CERN

August 1991 - Christian Boissat, CERN
Original release.