Chapter 3

User Commands

3.1 COMMANDS

This chapter gives a complete description of the following NQS commands in alphabetical order.

qalter(1-N)	.....	alter NQS batch request attributes
qcat(1-O)	.....	display error, input, or output text files of NQS running requests
qchk(1-N)	.....	get checkpoint of NQS batch requests
qdel(1-O)	.....	delete or signal NQS request(s)
qdev(1-O).	.....	display status of NQS device(s)
qhold(1-N)	.....	make an NQS request ineligible for execution
qlimit(1-O)	.....	show supported batch limits and shell strategy for a host(s)
qmove(1-N)	.....	move NQS requests
qmsg(1-N)	.....	send messages to the stderr or stdout files
qpr(1-O)	.....	submit hardcopy print requests to NQS
qrerun(1-N)	.....	rerun NQS requests
qrls(1-N)	.....	release previously held NQS requests
qrsm(1-N)	.....	resume execution of NQS requests
qrst(1-N)	.....	restart NQS requests from checkpoint
qspnd(1-N)	.....	suspend execution of NQS requests temporarily
qstat(1-O)	.....	display the status of NQS request(s)
qstata(1-N)	.....	display NQS access restriction information
qstatc(1-N)	.....	display the status of NQS queue complex(es)
qstatck(1-N)	.....	display NQS requests which have restart file
qstatd(1-N)	.....	display the status of NQS device(s)
qstatf(1-N)	.....	display information on NQS form(s)
qstatq(1-N)	.....	display the status of NQS queue(s)
qstatr(1-N)	.....	display the status of NQS request(s)
qsub(1-O)	.....	submit an NQS batch request
qwait(1-N)	.....	wait for the end of NQS job execution

3.2 COMMAND FORMAT

This section explains the standard format for command and file descriptions. Each command and file page contains only the description elements pertinent to that command.

NAME

intro - provides the command or file name and describes its purpose

SYNOPSIS

This area shows required command syntax, including options and arguments. The command line has the format:

name [option(s)][cmdarg(s)]

The command name always appears in bold. It is the name of an executable file. Command names are between two and nine characters and appear in lowercase letters and digits.

Specific options are bold and generic options are not bold. Options that are not required are placed in square brackets [ ]. cmdarg(s) are variable values. For instance, if cmdarg is a directory, it needs a directory name to be valid; if it is a file, it needs a file name. Options and their cmdargs are explained in greater detail under "Description."

Ellipses (...) in the command line mean that the previous option type or cmdarg can be repeated.

DESCRIPTION

This part of the command page describes the purpose and function of the entry. References to related entries and publicly accessible commands are often included here.

Command descriptions and associated options and arguments appear in this section. Options are preceded by a - and take two forms. The first is noargletter that represents a single-letter option that does not need an argument. These options can be grouped after one -, as shown in the following example.

ls -alr

The second form is argletter <> optarg[,...]. This is a single-letter options that requires an option argument (optarg). optarg is a character string that satisfies the preceding argletter.

Groups of optargs following an argletter must be separated by commas, or separated by blanks and quoted. Additionally, the first optarg of a group must be preceded by a blank.

A dash (-) can be used to indicate the end of a list of options. A dash (-) preceded and followed by blanks is only used to indicate the standard input.

cmdarg is the command argument or path name. The relative order of cmdargs can affect their significance as determined by the command.

DISPLAY FORMAT

Describes the output format generated by the command.

EXAMPLES

This section illustrates command usage.

FILES

Files used by the commands are listed here. Occasionally, a file description is included.

SEE ALSO

Commands and programs that contain related information are listed here. The entries are shown according to the section in which they appear. Commands are listed alphabetically within the section.

NOTES

Helpful hints for using the command appear here.

NAME

qalter - alter batch request attributes

SYNOPSIS

qalter [-h hostname] options request-id
qalter [-h hostname]options -r request-name

DESCRIPTION

qalter changes the resource limit execution environment of a batch request.

Request specification:

Specify a request with the request-id or request-name.

The request-id is displayed when a request is submitted. It consists of a serial number, and the host name part is assumed to be the local host.

The request is retrieved from requests in the local host owned by the command execution user and from those submitted to the local host and transferred to the remote machine. To manipulate any other request, specify the name of the remote host storing the request in the -h option.

Specify the -r option to designate a request with the request-name. However, an error occurs if more than one request having the same name exists in the retrieval range.

When the NQS/MPI function is available and if you specify the request-id of a master request, qalter(1) alters the attributes of the specified master request. If the master request is on the local host, or if the master request has been submitted to the local pipe queue and the tracking function is available, you can specify it without the -h option. Otherwise, you must specify the -h option.

You cannot alter the attributes of slave requests, PRE-RUNNING requests, and POST-RUNNING requests.

Request operator privilege:

A request can only be manipulated by the owner of the request.

Options:

The following options are available with qalter.

-a date-time

Alter the batch request start time (see qsub(1) for details). This time can only be changed on requests before execution. For example:

qalter -a "Tuesday, 23:00:00" 72.host1

-c CPU-count

Alter the CPU count value of the batch request. For example:

qalter -c 10 72.host1

-e [machine:] [[/]path/]stderr-filename

Alter the standard error output file name. Users can change this attribute only on non-executing requests. For example:

qalter -e host1:/usr/result.e 72.host1

-jm mode

Alter the batch request Job Occurrence Report (JOR) output mode to one of the following modes.

stderr

Outputs to the standard error result file

stdout

Outputs to the standard output file

file filename

Outputs to a specified file

mail

Notifies the requester by mail

Users can change this mode only on non-executing requests. For example:

qalter -jm stdout 72.host1

-l0 max-limit [,warn-limit]

Alter the per-request, file system group 0 (FSG0 = XMU) limit. For example:

qalter -l0 2kb 72.host1

-l1 max-limit [,warn-limit]

Alter the per-request, file system group 1 (FSG1) limit. For example:

qalter -l1 2kb 72.host1

-l2 max-limit [,warn-limit]

Alter the per-request, file system group 2 (FSG2) limit. For example:

qalter -l2 2kb 72.host1

-l3 max-limit [,warn-limit]

Alter the per-request, file system group 3 (FSG3) limit. For example:

qalter -l3 2kb 72.host1

-lc max-limit

Alter the per-process, core-file-size limit. For example:

qalter -lc 2kb 72.host1

-ld max-limit [,warn-limit]

Alter the per-process, data segment size limit. For example:

qalter -ld 2kb 72.host1

-lD max-limit

Alter the per-request tape drive limit. For example:

qalter -lD 5 72.host1

-le CPU-number

Alter the number of CPUs as the target of the per-process CPU resident time limit. For example:

qalter -le 2 72.host1

-lE CPU-number

Alter the number of CPUs as the target of the per-request CPU resident time limit. For example:

qalter -lE 2 72.host1

-lf max-limit [,warn-limit]

Alter the per-process, permanent-file-size limit. For example:

qalter -lf 2kb 72.host1

-lm max-limit [,warn-limit]

Alter the per-process, memory size limit. For example:

qalter -lm 2kb 72.host1

-lM max-limit [,warn-limit]

Alter the per-request, memory size limit. For example:

qalter -lM 2kb 72.host1

-ln value

Alter the per-process nice execution value limit of all processes constituting the batch request. The only quirk associated with this option results from the peculiar choice of nice execution values, using standard UNIX implementations. In general, increasingly negative nice execution values cause the relative execution priority of a process to increase, while increasingly positive nice execution values cause the relative priority to decrease.

Thus, a nice execution value limit of -ln -10 consumes more CPU resources than -ln 0. Users can change this value even on executing requests. Specifying any nice execution value with this option must be acceptable to the batch queue in which the request is ultimately placed. For example:

qalter -ln 10 72.host1

-lo max-limit

Alter the per-process open file number limit. For example:

qalter -lo 3 72.host1

-lO max-limit

Alter the per-request open file number limit. For example:

qalter -lO 3 72.host1

-lP max-limit
Alter the per-request process number limit. For example:

qalter -lP 3 72.host1

-lr max-limit[,warn-limit]

Alter the per-process, CPU resident time limit.

You cannnot specify the CPU resident time limit to be greater than the limit set for the submitted queue.

For example:

qalter -lr 1:00:00 72.host1

-lR max-limit[,warn-limit]

Alter the per-request, CPU resident time limit.

You cannnot specify the CPU resident time limit to be greater than the limit set for the submitted queue.

For example:

qalter -lR 1:00:00 72.host1

-ls max-limit [,warn-limit]

Alter the per-process, stack-segment size limit. For example:

qalter -ls 2kb 72.host1

-lt max-limit [,warn-limit]

Alter the per-process, CPU-time limit. For example:

qalter -lt 2:20 72.host1

-lT max-limit [,warn-limit]

Alter the per-request, CPU time limit. For example:

qalter -lT 2:30 72.host1

-lu max-limit

Alter the per-process number of CPU limit. This option is effective only when this resource limit is supported by the system. For example:

qalter -lu 2 72.host1

-lV max-limit [,warn-limit]

Alter the per-request, temporary file capacity. For example:

qalter -lV 2kb 72.host1

-lw max-limit

Alter the per-process, working set limit. For example:

qalter -lw 2kb 72.host1

-lW max-limit [,resv]

Alter the per-request physical memory area usage limit and pre-hold value.

You can change these values only for requests to be executed. The altered values must not exceed the limit of the queue to which the corresponding request is submitted.

For information on activation of a batch request limit and the exact syntax rule of limit, see the resource limit description of qsub(1).

This option is effective only when this resource limit is supported by the system. Otherwise, this option is ignored.

-lx max-limit [,warn-limit]
Alter the per-process permanent-file capacity. For example:

qalter -lx 2kb 72.host1

-lX max-limit [,warn-limit]

Alter the per-request permanent-file capacity. For example:

qalter -lX 2kb 72.host1

-mb mode

Alter the mail beginning transfer mode as follows.

on

Transfer mail at request execution start.

off

Do not transfer mail at request execution start.

You can change this mode only on non-executing requests. For example:

qalter -mb on 72.host1

-me mode

Alter the mail end transfer mode as follows.

on

Transfer mail at request execution end.

off

Do not transfer mail at request execution end.

Users can change this limit only on non-executing requests. For example:

qalter -me off 72.host1

-mu user-name

Alter the user transferring the mail. This attribute can be changed only on non-executing requests. For example:

qalter -mu SMITH 72.host1

-nc mode

Change the checkpoint mode of the batch request to the specified mode.

Specify either on or off for mode. on prevents getting the checkpoint while off enables getting the checkpoint. You can change this mode only on non-executing requests. For example:

qalter -nc on 72.host1

-nr mode

Change the start mode of the batch request to one of the following modes.

on

Non-restartable mode

off

Restartable mode

You can change this mode only on non-executing requests. For example:

qalter -nr on 72.host1

-o [machine:] [[/]path/] stdout-file-name

Alter the standard output file. You can change this attribute only on non-executing requests. For example:

qalter -o host1:/usr/result.o 72.host1

-re mode

Change the standard error-output-file of the batch request. Specify either s (spool) or n (non-spool). You can change this attribute only on non-executing requests. For example:

qalter -re s 72.host1

-ro mode

Change the standard output file of the batch request. Specify either s (spool) or n (non-spool). You can change this attribute only on non-executing requests. For example:

qalter -ro s 72.host1

-s shell-name

Alter the request execution shell. You can change this attribute only on non-executing requests. For example:

qalter -s /bin/csh 72.host1

-v level

Outputs the request execution report to the standard output file and standard error output file when the request terminates. level sets the output contents of the request execution report.

Request processes are managed in units of flocs. The request execution report is output as a flock execution report.

You cannot specify this option for requests on the SUPER-UX NQS.

You can specify 1 or 2 for level as follows:

1

Outputs the flock start time, termination time, termination status, type, and ID.

2

Outputs the assign and deassign status of the temporary file besides all the output contents of level 1.

-ve level

Outputs the request execution report to the standard error output file when the request terminates. level sets the output contents of the request execution report.

Request processes are managed in units of flocs. The request execution report is output as a flock execution report.

You cannot specify this option for requests on the SUPER-UX NQS.

You can specify 1 or 2 for level as follows:

1

Outputs the flock start time, flock termination time, flock termination status, flock type, and flock ID.

2

Outputs the assign and deassign status of the temporary file besides all the output contents of level 1.

-vo level

Outputs the request execution report to the standard output file when the request terminates. level is used to set the output contents of the request execution report.

Request processes are managed in units of flocs. The request execution report output as a flock execution report.

You cannot specify this option for requests on the SUPER-UX NQS.

You can specify 1 or 2 for level as follows:

1

Outputs the flock start time, termination time, termination status, type, and ID.

2

Outputs the assign and deassign status of the temporary file besides all the output contents of level 1.

SEE ALSO

qsub(1)

NOTES

See the LIMITS section in qsub for more information on implementing batch request limits and a description of precise syntax.

If you specify two or more tokens separated by white space, enclose them in double quotes or escape the string so that qalter and the shell interpret it as a single character string token. The value cannot exceed the value established by the batch queue.

If a request is sent via NQS to another host which does not support the tracking function, NQS cannot find the request correctly. At that time, use the -h option to specify the host name where the request exists.

The NQS/MPI function is available only on the cluster system.

NAME

qcat - display error, input, or output text files of NQS running requests

SYNOPSIS

qcat [-e][-i][-o][-t number][-u username][-h hostname] request-id...
qcat [-e][-i][-o][-t number][-u username][-h hostname] -r request-name...

DESCRIPTION

qcat displays the contents of error, input, or output text files of running requests.



qcat finds all the files, then reads each file in sequence and displays it on the standard output.



Request Specification:

Specify a request with the request-ID or request-name.

The request-ID is displayed when a request is submitted. It consists of a serial number and the name of the submitting host. When only the serial number is specified, the host name is assumed to be the local host.

The request is retrieved from the local host owned by the user who executed the command, from requests submitted to the local host, and requests transferred to the remote machine. To manipulate other request, s, use the -h option to specify the name of the remote host storing the request.

Specify the -r option to designate a request with the request-name. However, an error occurs if two or more requests having the same name exist in the retrieval range.

Request Operator Privilege:

A request can only be manipulated by its owner. However, a user having the NQS manager privilege can manipulate requests owned by a designated user using the -u username option.

Options:

-e

Displays the error file if it exists.

-i

Displays the input file (script file).

-o

Displays the output file if it exists.

-t number

Begins copying at distance number from the end of the file. number is counted
in units of lines

-h hostname

Specifies the target host from which to obtain display information.

-u username

Specifies the username of the specified requests. Only a superuser can specify this option.

If none of the options -e, -i, and -o are specified, an attempt is made to display the input file.

SEE ALSO

qstat(1)

NOTES

If a request is sent via NQS to another host that does not support the tracking function, NQS cannot find the request correctly. At that time, use the -h option to specify the host name where the request exists.

WARNING

This command is derived from the one developed by Sterling Software Corporation.

NAME

qchk - get checkpoint of NQS requests

SYNOPSIS

qchk [-f] [-F restart-file] [-u username] [-h hostname] request-id...
qchk [-f] [-F restart-file] [-u username] [-h hostname] -r request-name...

DESCRIPTION

qchk gets the checkpoint of the currently executed NQS request specified in the command line. Even if the checkpoint is retrieved, the request is not closed.

To get the checkpoint of a request that has a checkpoint, use the -f flag. If this flag is specified, NQS deletes the old checkpoint and gets the new one. If this flag is not specified, NQS returns an error message.

Requests that have a restart file can be seen by qstatck(1).

If the NQS manager permits to specify a name of restart files in nqs.conf(4), you can specify a restart file name using -F restart-file. The format of restart-file is as follows:

[[/]path/]file-name

If the beginning of path is not a slash (/), the path is interpreted as being a relative path name. If path is omitted, a restart file is created on the current directory.

If you do not specify a restart file name when the specification is permitted, qchk(1) creates a restart file on the current directory with the name "request-name.csequence-number.machine-ID". If the request-name consists of eight or more letters, qchk(1) uses only the leading seven letters.

If the system stalls after getting the checkpoint, the request automatically restarts from its checkpoint at restarting NQS.

Request specification:

Specify a request with the request-id or request-name.

The request-id is displayed when a request is submitted. It consists of a serial number, and the host name which is assumed to be the local host.

The request is retrieved from requests in the local host owned by the command execution user and from those submitted to the local host and transferred to the remote machine. To manipulate any other request, specify the name of the remote host storing the request in the -h option.

Specify the -r option to designate a request with the request-name. However, an error occurs if more than one request having the same name exists in the retrieval range.

When the NQS/MPI function is available, if you specify the request ID of a master request, qchk(1) checkpoints the specified master request and the related slave requests. If the master request is on the local host, or if the master request has been submitted to the local pipe queue and the tracking function is available, you can specify it without the -h option. Otherwise, you must specify the -h option. If the specified request is PRE-RUNNING or POST-RUNNING, you cannot checkpoint it. If any slave requests have already terminated, all related MPI requests cannot be checkpointed. Individual slave requests cannot be checkpointed.

Request operator privilege:

A request can only be manipulated by the owner of the request. However, a user having the NQS manager privilege can manipulate requests owned by a designated user using the -u username option.

SEE ALSO

qrst(1), qstat(1), qstatck(1), qmgr(1M)

NOTES

If a request is sent via NQS to another host that does not support the tracking function, NQS cannot find the request correctly. At that time, use the -h option to specify the host name where the request exists.

If you re-checkpoint a request with the -f option with a different file name from the previous one, qchk(1) asks if you want to delete the previous restart file. If you decide not to delete the previous file, qchk(1) stops re-checkpointing.

You cannot re-checkpoint a request without the -f option even if you specify a different restart file name with the -F option.

This command is available only when a request is executed on the SUPER-UX NQS.

The -u and -h options cannot be specified simultaneously.

When checkpointing fails, NQS sends error messages by mail indicating the reason of failure . See Section 6.5.5, "Error Codes" in the SUPER-UX System Administrator's Guide for details of the error messages.

The NQS/MPI function is available only on the cluster system.

NAME

qdel - delete or signal NQS request(s)

SYNOPSIS

qdel [-k] [-signal] [-s | -R] [-u username] [-h hostname] request-id...
qdel [-k] [-signal] [-s | -R] [-u username] [-h hostname] -r request-name...

DESCRIPTION

qdel deletes queued NQS requests. -k sends the default SIGKILL signal (-9) to any running request-id. This ends and deletes the request. If signal s is present, it is sent instead of SIGKILL.

An executing NQS request cannot be deleted without using -k or signal.

Even if the request for which the checkpoint was received is terminated by the above signal, it is not deleted if -s was specified. The request can be restarted. When -R was specified, a restart-file is deleted if the request is running and the checkpoint has been received for the request.

-s and -R cannot be specified at the same time.

If the specified batch request is EXITING, all network requests to stage out job output files for the batch request are deleted. If the corresponding network request is RUNNING, NQS sends SIGKILL. The job output files of the deleted network requests are put on the request owner's home directory on the host where the parent batch request was executed. At this time, -signo, -k, -R, and -s are ignored. You cannot specify network requests directly.

Request specification:

Specify a request with the request-id or request-name.

The request-id is displayed when a request is submitted. It consists of a serial number, and the host name part is assumed to be the local host.

The request is retrieved from requests in the local host owned by the command execution user and from those submitted to the local host and transferred to the remote machine. To manipulate any other request, , specify the name of the remote host storing the request in the -h option.

Specify the -r option to designate a request with the request-name. However, an error occurs if more than one request having the same name exists in the retrieval range.

When the NQS/MPI function is available and if you specify the request-id of a master request, qdel(1) deletes the specified master request and the related slave requests. If the master request is on the local host, or if the master request has been submitted to the local pipe queue and the tracking function is available, you can specify it without the -h option. Otherwise, you must specify the -h option. If one or more related requests are being sent via pipe, you cannot delete all specified requests. You cannot delete only a slave request either.

Specify the -k option to delete PRE-RUNNING requests or POST-RUNNING requests.

Request operator privilege:

A request can only be manipulated by the owner of the request. However, a user having the NQS manager privilege can manipulate requests owned by a designated user using the -u username option.

SEE ALSO

qdev(1), qlimit(1), qpr(1), qstat(1), qsub(1), qmgr(1M)
killj(2), setpgrp(2), signal(2) in the SUPER-UX Programmer's Reference Manual

NOTES

The concept of a job exists in SUPER-UX. All processes in an NQS request share the same job ID and can be recognized as a job group. The killj system call is used to send signals to the job group and can send signals to all processes pertaining to the request.

If a request is sent via NQS to another host that does not support the tracking function, NQS cannot find the request correctly. At that time, use the -h option to specify the host name where the request exists.

The -u and -h options cannot be specified simultaneously.

The NQS/MPI function is available only on the cluster system.

WARNING

This command is derived from the one developed by Sterling Software Corporation.

NAME

qdev - display status of NQS device(s)

SYNOPSIS

qdev [device-name] [device-name@hostname...]

DESCRIPTION

qdev displays the status of known devices on the local host. Devices can be specified as device-name or device-name@hostname. qdev displays a device header with several headings.

• Device is formatted as device-name@hostname.

• Fullname is the full path name of the special file associated with the device.

• Server is the command line used to execute the device.

• Forms configure the device.

• Status prefaces the general device state display.

Device states can be ENABLED, DISABLED, and ENABLED/CLOSED. If a device can accept queued requests, it is ENABLED. If the device cannot accept queued requests and is idle, its state is DISABLED. A third state of ENABLED/CLOSED describes a device that cannot accept queued requests, but is not yet idle.

Devices can also be ACTIVE, INACTIVE, and FAILED.

• If the device is busy, it is ACTIVE.

• If the device is idle and not known to be out of service, it is INACTIVE.

• If the device is idle and known to be out of service, it is FAILED. FAILED covers both hardware and software failures. If a device is busy, information about the active request follows the device header. The request-name, ID, and the user name submitting the request appear.

SEE ALSO

qdel(1), qlimit(1), qpr(1), qstat(1), qsub(1), qmgr(1M)

WARNING

This command is derived from the one developed by Sterling Software Corporation.

NAME

qhold - make an NQS request ineligible for execution

SYNOPSIS

qhold [-F restart-file] [-u username] [-h hostname] request-id...
qhold [-F restart-file] [-u username] [-h hostname] -r request-name...

DESCRIPTION

qhold holds an NQS request temporarily. The request is not executed until released with qrls.

If a request currently executed is specified, NQS automatically gets the checkpoint before holding and restarts it from the checkpoint at release. If getting the checkpoint is forbidden by the NQS manager, a request currently executed cannot be held.

If the NQS manager permits specifying restart files names in nqs.conf(4), you can specify a restart file name using -F restart-file. The format of restart-file is as follows:

[[/]path/]file-name

If the beginning of path is not a slash (/), the path is interpreted as being a relative path name. If path is omitted, a restart file is created on the current directory.

If you do not specify a restart file name when the specification is permitted, qhold(1) creates a restart file on the current directory with the name "request-name.hsequence-number.machine-ID". If the request-name consists of eight or more letters, qhold(1) uses only the leading seven letters.

If NQS is shut down with a held request, that request remains held until restart.

Request specification:

Specify a request with the request-id or request-name.

The request-id is displayed when a request is submitted. It consists of a serial number, and the host name is assumed to be the local host.

The request is retrieved from requests in the local host owned by the command execution user and from those submitted to the local host and transferred to the remote machine. To manipulate any other request, specify the name of the remote host storing the request in the -h option.

Specify the -r option to designate a request with the request-name. However, an error occurs if more than one request having the same name exists in the retrieval range.

When the NQS/MPI function is available and if you specify the request-id of a master request, qhold(1) holds the attributes of the specified master request. If the master request is on the local host, or if the master request has been submitted to the local pipe queue and the tracking function is available, you can specify it without the -h option. Otherwise, you must specify the -h option.

You cannot hold the slave requests, PRE-RUNNING requests, and POST-RUNNING requests.

When RUNNING or SUSPEND master request is specified, the master request and all related slave requests are held with checkpointing. At that time, however, if any related slave requests have already terminated, qhold aborts.

Request operator privilege:

A request can only be manipulated by the owner of the request. A user having the NQS manager privilege can manipulate requests owned by a designated user using the -u username option.

SEE ALSO

qdev(1), qlimit(1), qpr(1), qrls(1), qstat(1), qsub(1), qmgr(1M)

NOTES

If a request is sent via NQS to another host that does not support the tracking function, NQS cannot find the request correctly. At that time, use the -h option to specify the host name where the request exists.

The -u and -h options cannot be specified simultaneously.

The NQS/MPI function is available only on the cluster system.

When checkpointing fails, NQS sends error messages by mail indicating the reason for failure . See Section 6.5.5, "Error Codes" in the SUPER-UX System Administrator's Guide for details of the error messages.

NAME

qlimit - show supported batch limits and the shell strategy for a host(s)

SYNOPSIS

qlimit [hostname...]

DESCRIPTION

qlimit displays a set of batch request resource limits that can be directly enforced on the implied local host or named hosts. It also displays the batch request shell strategy. By default, qlimit displays information about the local host.

RESOURCE LIMITS

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

Batch request limits are restricted to those that can be directly supported by the underlying UNIX implementation. If a batch request specifies a limit that cannot be enforced by the UNIX implementation, the limit is simply ignored, and the batch request operates without limits (other than the obvious physical maximums).

When an attempt is made to queue a batch request, each limit value (that can also be supported by the local UNIX implementation) is compared against the corresponding limit value as configured for the batch queue.

If all the defined limits for the batch request are less than or equal to the enforceable limits of the queue, the request can be successfully queued, provided that no other anomalous conditions occur. For infinite limit values, the corresponding queue limit value must also be configured as infinity.

These resource limit checks are performed irrespective of the batch request submittal, by either qsub or by the pipe queue placement of a batch request. It is impossible to queue a batch request in an NQS batch queue if any of these resource limit checks fail.

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

Upon successful submittal of a request to a batch queue, the set of limits under which the request executes is frozen. This is not modified by subsequent qmgr commands that alter the limits in the containing batch queue. Nevertheless, the limit value of a submitted request can be altered with qalter or the modify subcommand of qmgr.

SHELL STRATEGIES

qlimit also displays the shell strategy. If a user does not specify a shell, NQS chooses a shell to execute that batch request. NQS supports three different algorithms, depending on user needs and on system performance criteria. Possible shell strategies include free, fixed, and login.

• Free --- Executes the user's login shell, as defined in the password file. This chooses and spawns the appropriate shell for running the batch shell script. A free shell strategy runs the batch request script interactively and is the default NQS shell strategy. In the free strategy, two shells are executed for a single request.

• Fixed --- Means that the same shell, as chosen by the System Administrator, is used to execute all batch requests. When a fixed shell strategy is configured for a particular NQS system, qlimit displays the fixed shell being used to run all batch requests at that host.

• Login --- Causes only the user's login shell to interpret the script.

  The fixed and login strategies exist for host systems that are short on available free processes. In these two strategies, a single shell is executed and that same shell executes all the commands in the batch request shell script.

SEE ALSO

qdel(1), qdev(1), qpr(1), qstat(1), qsub(1), qmgr(1M)

WARNING

This command is derived from the one developed by Sterling Software Corporation.

NAME

qmove - move NQS requests

SYNOPSIS

qmove [-u username] [-h hostname] request-id ... queue
qmove [-u username] [-h hostname] -r request-name ... queue
qmove -q [-u username] [-h hostname] queue ... queue

DESCRIPTION

qmove moves a request to another queue. Specifying the -q option moves all requests owned by the user and residing in one queue, to another queue.

When you specify an EXITING batch request and a network queue, all network requests for staging out job output files of the specified batch request can be moved to the specified network queue. At this time, RUNNING network request can also be moved. If the path set for staging out job output files for a specified batch request does not exist on the destination machine of the moved network queue, staging out fails.

You cannot move network requests using -q network-queue network-queue. You cannot specify network requests directly.

Request specification:

Specify a request with the request-id or request-name.

The request-id is displayed when a request is submitted. It consists of a serial number, and the host name is assumed to be the local host.

The request is retrieved from requests in the local host owned by the command execution user and from those submitted to the local host and transferred to the remote machine. To manipulate any other request, specify the name of the remote host storing the request in the -h option.

Specify the -r option to designate a request with the request-name. However, an error occurs if more than one request having the same name exists in the retrieval range.

When the NQS/MPI function is available and if you specify the request-id of a master request, qmove(1) moves the specified master request. If the master request is on the local host, or if the master request has been submitted to the local pipe queue and the tracking function is available, you can specify it without the -h option. Otherwise, you must specify the -h option.

You cannot move the slave requests, and RUNNING, PRE-RUNNING and POST-RUNNING master requests.

Request operator privilege:

A request can only be manipulated by the owner of the request. A user having the NQS manager privilege can manipulate requests owned by a designated user using -u username.

SEE ALSO

qdev(1), qlimit(1), qpr(1), qstat(1), qsub(1), qmgr(1M)

NOTES

Only an unexecuted request can be moved (except for network requests). If you specify a request that is running or try to move an exiting batch request to another batch queue, a warning appears.

If a request is sent to the other host via NQS which does not support the tracking function, NQS cannot find the request correctly. At that time, specify the host name where the request exists by the -h option.

The -u and -h options cannot be specified simultaneously.

If you try to move your requests when NQS updates its database file, qmove(1) sometimes shows the following message.

*** Warning: NQS is updating the database for requests ***

This message indicates that qmove(1) is waiting for the updating to complete.

The NQS/MPI function is available only on the cluster system.

NAME

qmsg - send messages to the stderr or stdout files

SYNOPSIS

qmsg [-e] [-o] request-id
qmsg [-e] [-o] -r request-name

DESCRIPTION

qmsg writes messages to the stderr, stdout, or both files. The messages are read from the standard input (stdin). The request must exist on the current host.

Request specification:

Specify a request with the request-id or request-name.

The request-id is displayed when a request is submitted. It consists of a serial number, and the host name is assumed to be the local host.

The request is retrieved from requests in the local host owned by the command execution user and from those submitted to the local host and transferred to the remote machine. To manipulate any other request, specify the name of the remote host storing the request in the -h option.

Specify the -r option to designate a request with the request-name. However, an error occurs if more than one request having the same name exists in the retrieval range.

Request operator privilege:

A request can only be manipulated by the owner of the request. Nevertheless, a superuser can send messages to any batch request.

Options:

-e

Write messages to the NQS batch request stderr file.

-o

Write messages to the NQS batch request stdout file.

If no option is specified, messages are written onto the NQS stderr file.

SEE ALSO

qdel(1), qlimit(1), qpr(1), qstat(1), qsub(1), qmgr(1M)

NAME

qpr - submit hardcopy print requests to NQS

SYNOPSIS

qpr [-a date-time] [-ac acctcode] [-f form-name] [-mb] [-me] [-mu username] [-n number-of-copies] [-p priority] [-q queue-name] [-r request-name] [-z] [files]

DESCRIPTION

qpr places files in a device queue for printing on a line or laser printer. If no file(s) is specified, qpr reads from standard input.

By default, qpr prints a request-id in standard output upon successful queuing. This ID can be compared with what is reported by qdev and qstat to investigate a request, and given as an argument to qdel to delete a request. A request-id is always of the form seqno.hostname where seqno refers to the sequence number assigned to the request by NQS. The unique request-id is used in NQS to identify the request in the network. The following qpr options can appear in any order and be intermixed with file names.

Options:

-a date-time

Submits a request at date-time. By default, qpr submits the request immediately. If date-time has two or more tokens separated by spaces, it must be placed within double quotes. For example:
-a "July 4, 2026 12:31 EDT"

The shell must interpret the entire date-time specification as a single lexical token.

The syntax accepted for date-time is relatively flexible. Unspecified date and time values default to an appropriate value (if a date is not specified, the current month, day, and year are assumed).

A date can be specified as a month and day (current year assumed). The year can also be specified as "Tues", "today", or "tomorrow". Weekday and month names can be abbreviated by any three-character (or longer) prefix of the actual name. An optional period can follow an abbreviated month or day name.

Specify time with either a 24-hour clock (default) or "am" and "pm". Time is interpreted using the precise meridian definitions whereby "12am" means 0:00:00, "12m" (meridian) is noon, and "12-pm" is midnight, or 24:00:00. Alternatively, the phrases "midnight" and "noon" are accepted as time specifications, where "midnight" is 24:00:00.

A time zone can also appear at any point in the date-time specification, "April 1, 1996 13:01-PDT". By default, the local time zone is assumed, with daylight savings time inferred when appropriate, based on the date specified. All alphabetic comparisons are performed in a case-insensitive fashion such that both "WeD" and "weD" are Wednesday. Some valid date-time examples are as follows.


01-Jan-1996 12am, PDT
Tuesday, 23:00:00
11pm tues.
tomorrow 23-MST

-ac acctcode

Uses acctcode as the account code of a request. The owner of a request must have permission to use acctcode. If this option is omitted, to submit a request, NQS uses the account code of process as the request account code.

-f form-name

Limits the set of acceptable devices to those loaded with form-name. By default, qpr submits the request only to a device that is loaded with default forms. If default forms are not defined, the request is submitted to the appropriate output device without regard to the forms configured for the device. In any case, only devices associated with the chosen queue are considered.

-mb

Sends mail at the beginning of an executing request to the user on the originating machine. If -mu is also present, mail goes to the user in the -mu option instead of to the invoking user.

-me

Sends mail at the end of an executing request to the user on the originating machine. If the -mu option is also present, mail is sent to that user instead of to the invoking user.

-mu username

Specifies that any mail concerning the request should be delivered to user-name. user-name may be formatted either as user (containing no "O" characters), or as user@machine. By default, mail concerning the request is sent to the invoker on the originating machine.

-n number-of-copies

Prints the specified number of copies. The default is one.

-p priority

Assigns an inter-queue priority. The priority must be an integer in the range of 0-63, inclusive. A value of 63 defines the highest inter-queue request priority, while a value of 0 defines the lowest. This priority does not determine the execution priority of the queue.

When adding a request, it is placed at a specific position so that it appears ahead of existing requests with less priority. Similarly, all requests with a higher priority remain ahead of the new request when the queuing process is complete. When the priority of the new request is equal to the priority of an existing request, the existing request takes precedence over the new request. If users do not choose an inter-queue priority, NQS assigns a default value.

-q queue-name

Specifies the queue for submitting a device request. By default, the environment variable set is searched for the variable QPR_QUEUE. If found, the character string value for it is the queue to which the request is submitted. IfQPR_QUEUE is not found, the request is submitted to the default device request queue, defined by the local System Administrator. Otherwise, the request cannot be queued, and an error message appears.

-r request-name

Assigns a name to the request. By default, the request-name defaults to the command line. If print files are not specified, STDIN is assigned to the request. In all cases, if the request name begins with a digit, the character "R" is prefixed. All request-names are truncated to a maximum length of 15 characters. Do not confuse request-name with request-id.

-z

Submits the request silently. If the request is successful, nothing is written to stdout or stderr.

QUEUE ACCESS

NQS supports queue access restrictions. For each queue type other than network, access may be either unrestricted or restricted. If unrestricted, any request can enter the queue. If access is restricted, a request can only enter the queue if the requester or the requester's login group has access to that queue (see qmgr). Requests submitted by root are an exception; they are always queued, even if root has not explicitly been given access. Use qstat to determine who has access to a particular queue.

SEE ALSO

qdel(1), qdev(1), qstat(1), qmgr(1M)

WARNING

This command is derived from the one developed by Sterling Software Corporation.

NAME

qrerun - rerun NQS requests

SYNOPSIS

qrerun [-u username] [-h hostname] request-id...
qrerun [-u username] [-h hostname] -r request-name...

DESCRIPTION

qrerun reruns an NQS request. It interrupts the execution of the specified request and it reexecutes it from the beginning.

Request specification:

Specify a request with the request-id or request-name.

The request-id is displayed when a request is submitted. It consists of a serial number, and the host name is assumed to be the local host.

The request is retrieved from requests in the local host owned by the command execution user and from those submitted to the local host and transferred to the remote machine. To manipulate any other request, , specify the name of the remote host storing in the -h option.

Specify the -r option to designate a request with request-name. However, an error occurs if more than one request having the same name exists in the retrieval range.

When the NQS/MPI function is available and if you specify the request-id of a master request, qrerun(1) reruns the specified master request and the related slave requests. If the master request is on the local host, or if the master request has been submitted to the local pipe queue and the tracking function is available, you can specify it without the -h option. Otherwise, you must specify the -h option.

You cannot rerun only the slave requests. And you cannot rerun the PRE-RUNNING and POST-RUNNING master requests.

Request operator privilege:

A request can only be manipulated by the owner of the request. A user having the NQS manager privilege can manipulate requests owned by a designated user using -u username.

SEE ALSO

qdev(1), qlimit(1), qpr(1), qstat(1), qsub(1), qmgr(1M)

NOTES

Only a running request can be rerun. If users specify a nonrunning request, a warning appears. If a request cannot be rerun, the request continues to run.

If a request is sent via NQS to another host that does not support the tracking function, NQS cannot find the request correctly. At that time, use the -h option to specify the host name where the request exists.

The -u and -h options cannot be specified simultaneously.

The NQS/MPI function is available only on the cluster system.

NAME

qrls - release previously held (with qhold) NQS requests

SYNOPSIS

qrls [-u username] [-h hostname] request-id...
qrls [-u username] [-h hostname] -r request-name...

DESCRIPTION

qrlsreleases a previously held NQS request. Execution of a held request is put on hold with qhold. The request is not executed in this state.

If a request is held at checkpoint, it restarts from the checkpoint at release.

This command cannot release the request held by the subcommand from qmgr(1M).

Request specification:

Specify a request with the request-id or request-name.

The request-id is displayed when a request is submitted. It consists of a serial number, and the host name is assumed to be the local host.

The request is retrieved from requests in the local host owned by the command execution user and from those submitted to the local host and transferred to the remote machine. To manipulate any other request, , specify the name of the remote host storing the request in the -h option.

Specify the -r option to designate a request with the request-name. However, an error occurs if more than one request having the same name exists in the retrieval range.

Request operator privilege:

A request can only be manipulated by the owner of the request. A user having the NQS manager privilege can manipulate requests owned by a designated user using -u username.

SEE ALSO

qdev(1), qhold(1), qlimit(1), qpr(1), qstat(1), qsub(1), qmgr(1M)

NOTES

Only he ld requests can be released. If users specify an unheld request, a warning appears.

If a request is sent via NQS to another host that does not support the tracking function, NQS cannot find the request correctly. At that time, use the -h option to specify the host name where the request exists.

The -u and -h options cannot be specified simultaneously.

If you release the checkpointed request on the system in which the specification of a restart file name is permitted, You must put the restart file on the same path and with the same file name as it has been checkpointed.

When restarting from checkpoint fails, NQS sends error messages by mail indicating the reason for failure . See Section 6.5.5, "Error Codes" in the SUPER-UX System Administrator's Guide for details of the error messages.

If the request is checkpointed in holding, NQS restarts all master and related slave requests from checkpoint. At that time, unless all NQSs necessary to execute master and slave requests are activated, restart fails. The NQS/MPI function is available only on the cluster system.

NAME

qrsm - resume execution of NQS requests

SYNOPSIS

qrsm [-u username] [-h hostname] request-id
qrsm [-u username] [-h hostname] -r request-name

DESCRIPTION

qrsm resumes execution of an NQS request that has been suspended (with qspnd).

This command cannot resume the request suspended by the qmgr(1M) subcommand.

Request specification:

Specify a request with the request-id or request-name.

The request-id is displayed when a request is submitted. It consists of a serial number, and the host name is assumed to be the local host.

The request is retrieved from requests in the local host owned by the command execution user and from those submitted to the local host and transferred to the remote machine. To manipulate any other request, specify the name of the remote host storing the request in the -h option.

Specify the -r option to designate a request with the request-name. However, an error occurs if more than one request having the same name exists in the retrieval range.

Request operator privilege:

A request can only be manipulated by the owner of the request. A user having the NQS manager privilege can manipulate requests owned by a designated user using -u username .

SEE ALSO

qdev(1), qlimit(1), qpr(1), qspnd(1), qstat(1), qsub(1), qmgr(1M)

NOTES

Only a SUSPENDED request can be resumed. If you specify a nonsuspended request, a warning appears.

If a request is sent via NQS to another host that does not support the tracking function, NQS cannot find the request correctly. At that time, use the -h option to specify the host name where the request exists.

The -u and -h options cannot be specified simultaneously.

When the suspended master request is specified on the system where the NQS/MPI function is used, qrsm(1) resumes the specified master request and the related slave requests.

The NQS/MPI function is available only on the cluster system.

NAME

qrst - restart NQS requests from checkpoint

SYNOPSIS

qrst [-d [-n]] [-u username] [-h hostname] request-id...
qrst [-d [-n]] [-u username] [-h hostname] -r request-name...

DESCRIPTION

qrst restarts NQS requests specified in the command line from its checkpoint.

Requests that have a restart file can be seen by qstatck(1).

A request that has gotten its checkpoint can be restarted again and again while its restart file exists. The restart file needs a huge area, so the request does not have to restart. Removing the restart file by executing qrst with the -d option is suggested. When a request restarts normally, the restart file is removed. But if restart is refused for some reason, the restart file remains.

If the NQS database is not saved in spite of existence of the restart file, the request cannot be restarted. The -n option should be specified in order to remove the restart file without trying restart. The -n option has no meaning unless -d is specified. So if only -n is specified, NQS ignores it.

Only a terminated request can be restarted. If a request not terminated is specified, a warning is given.

This command cannot restart the request by checkpoint with the subcommand from qmgr(1M).

Request specification:

Specify a request with the request-id or request-name.

The request-id is displayed when a request is submitted. It consists of a serial number, and the host name is assumed to be the local host.

The request is retrieved from requests in the local host owned by the command execution user and from those submitted to the local host and transferred to the remote machine. To manipulate any other requests, specify the name of the remote host storing the request in the -h option.

Specify the -r option to designate a request with request-name. However, an error occurs if more than one request having the same name exists in the retrieval range.

Request operator privilege:

A request can only be manipulated by the owner of the request. However, a user having the NQS manager privilege can manipulate requests owned by a designated user using the -u username option.

SEE ALSO

qchk(1), qstat(1), qstatck(1), qmgr(1M)

NOTES

If a request is sent via NQS to another host that does not support the tracking function, NQS cannot find the request correctly. At that time, use the -h option to specify the host name where the request exists.

The checkpoint/restart function is available only for requests on SUPER-UX NQS.

The -u and -h options cannot be specified simultaneously.

If you restart the checkpointed request on the system in which the specification of a restart file name is permitted, you must place the restart file on the same path with the same file name as it has been checkpointed.

When restarting from checkpoint fails, NQS sends error messages by mail indicating the reason for failure. See Section 6.5.5, "Error Codes" in the SUPER-UX System Administrator's Guide for details of the error messages.

If the request is checkpointed by qchk(1), NQS restarts all master and related slave requests from checkpoint. At that time, unless all NQSs necessary to execute master and slave requests are activated, restart fails. The NQS/MPI function is available only on the cluster system.

NAME

qspnd - suspend execution of NQS requests temporarily

SYNOPSIS

qspnd [-u username] [-h hostname] request-id...
qspnd [-u username] [-h hostname] -r request-name...

DESCRIPTION

qspnd temporarily suspends execution of the NQS request.

Request specification:

Specify a request with the request-id or request-name.

The request-id is displayed when a request is submitted. It consists of a serial number, and the host name is assumed to be the local host.

The request is retrieved from requests in the local host owned by the command execution user and from those submitted to the local host and transferred to the remote machine. To manipulate any other requests, specify the name of the remote host in the -h option.

Specify the -r option to designate a request with the request-name. However, an error occurs if more than one request having the same name exists in the retrieval range.

When the NQS/MPI function is available and if you specify the request-id of a master request, qspnd(1) suspends the specified master request and the related slave requests. If the master request is on the local host, or if the master request has been submitted to the local pipe queue and the tracking function is available, you can specify it without the -h option. Otherwise, you must specify the -h option.

You cannot suspend only the slave requests. You cannot suspend PRE-RUNNING and POST-RUNNING master requests, either.

Request operator privilege:

A request can only be manipulated by the owner of the request. However, a user having the NQS manager privilege can manipulate requests owned by a designated user using the -u username option.

SEE ALSO

qdev(1), qlimit(1), qpr(1), qrsm(1), qstat(1), qsub(1), qmgr(1M)

NOTES

Only a running request can be temporarily suspended. If users specify an idle request, a warning appears.

If a request is sent via NQS to another host that does not support the tracking function, NQS cannot find the request correctly. At that time, use the -h option to specify the host name where the request exists.

The -u and -h options cannot be specified simultaneously.

The NQS/MPI function is available only on the cluster system.

NAME

qstat - display the status of NQS request(s)

SYNOPSIS

qstat [-a] [-l] [-m] [-u username] [-x] [queue-name ...] [queue-name@hostname ...]

DESCRIPTION

qstat displays the state of all or specified NQS queues on the local host (the default). qstat displays a queue header, which contains information about the queue, followed by request information. Ordinarily, qstat shows only those requests belonging to the invoker. qstat options are described next.

Options:

-a

Shows all requests.

-l

Shows requests in a long format.

-m

Shows requests in a medium length format.

-u username

Shows only those requests belonging to user-name.

-x

Shows the queue header in an extended format

The queue header always includes the queue name, type, status, an indication of whether or not the queue is pipeonly (accepts requests from pipe queues only), and the number of requests in queue. An extended queue header goes on to display the priority and run limit of a queue, as well as access restrictions, cumulative use statistics, server, destinations (for pipe queues), queue-to-device mappings (for device queues), and resource limits (for batch queues). By default, qstat displays the following information about a request.

• Request name
• Request ID
• Job ID
• Owner
• Relative request priority
• Current request state

For running requests, the process group or job ID is also shown as soon as information becomes available to the local NQS daemon. If the request is submitted to SUPER-UX, the job ID is displayed, otherwise, the process group is displayed.

qstat -m shows the constraining time and date if the request was submitted with a constraint that it run at a certain time and date.

qstat -l shows the time that the request was created, an indication of whether or not mail is to be sent, and the user name on the originating machine. If a batch queue is being examined, resource limits, planned disposition of stderr and stdout, any advice concerning the command interpreter, and the umask value are shown. If a device queue is being examined, the requested forms are shown.

QUEUE STATE

The queue state is defined by two properties. The first property determines whether or not requests can be submitted to the queue. If they can, then the queue is ENABLED; otherwise, the queue is DISABLED.

CLOSED, ENABLED, or DISABLED appears in the queue status field to indicate the status of the queue. Requests can only be submitted to a queue with the ENABLED state.

The second property describes what happens to executable requests and also determines if any requests are RUNNING. An executable request is ready to run, but is waiting for initiation by the request scheduler. The queue states describing the second property of a queue are displayed as STOPPED, STOPPING, RUNNING, INACTIVE, and SHUTDOWN.

If executable requests are blocked and no requests are presently RUNNING, the queue is STOPPED. If the same situation exists but at least one request is running, the queue is STOPPING. This means the requests that are presently RUNNING are allowed to complete execution, but no new requests are initiated.

If the queue contains one or more requests that are presently executing, the queue is RUNNING. If the queue does not contain any requests, the queue is INACTIVE. If the NQS daemon for the local host is not running, the queue is SHUTDOWN.

REQUEST STATE

The state of a request can be ARRIVING, HOLDING, WAITING, QUEUED, STAGING, ROUTING, RUNNING, SUSPENDING, DEPARTING, or EXITING.

• An ARRIVING request is being submitted from a remote host.

• A HOLDING request indicates a request on hold.

• A WAITING request is submitted with the constraint that it not run before a certain date and time.

• Queued requests are eligible to proceed (by ROUTING or RUNNING). When a request reaches the head of a pipe queue, 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 is a batch request that is not yet executing, but is having input files brought on to the machine.

• A RUNNING request has reached its final destination queue, and is temporarily interrupted during an execution.

• EXITING describes a batch request that has completed execution, and exits from the system after the required output files are returned (to possibly remote machines).

Imagine a batch request from a workstation, destined for a remote batch queue to be run immediately. That request goes through the QUEUED, ROUTING, and DEPARTING states in a local pipe queue, then it disappears. From a remote queue, the request would be ARRIVING, QUEUED, STAGING (if required by the batch request), RUNNING, and finally EXITING. Upon EXITING, the batch request disappears from the batch queue.

If the NQS/MPI function is used on the cluster system, batch requests called master request and slave request are available. At that time, the PRE-RUNNING state (master request is waiting for the beginning of slave requests) and the POST-RUNNING state (master request is waiting for the exiting of slave requests) are also available.

SEE ALSO

qdel(1), qdev(1), qlimit(1), qpr(1), qsub(1), qmgr(1M)

NOTES

STAGING or DEPARTING are not supported.

If you try to see the status of requests when NQS updates its database file, qstat(1) sometimes shows the following message.

*** Warning: NQS is updating the database for requests ***

This message indicates that qstat(1) is waiting for the updating to complete.

WARNING

This command is derived from the one developed by Sterling Software Corporation.

NAME

qstata - display NQS access restriction information

SYNOPSIS

qstata [options]

DESCRIPTION

qstata displays information on access restrictions. These refer to the limits on the input of requests to NQS as well as on the execution of requests in NQS. The following are qstata options.

Options:

-a

Display users and groups that are not permitted to place requests.

-ac acctcode

Specify the account code to be checked.

-h host-name

Display NQS access restrictions of a host.

-n

Do not display a header.

You cannot specify -a and -h simultaneously. You cannot specify -a and -ac simultaneously.

DISPLAY FORMAT

When -a is not specified, the following messages are displayed according to the status of NQS access restrictions.

• If NQS restricts your access:

  You are not permitted to place requests in NQS.

  (return value=1)

• If NQS restricts your group's access:

  Your group is not permitted to place requests in NQS.

  (return value=2)

• If excess of budget restricts your access:

  You are not permitted to place request in NQS. (Excess of the budget)

  (return value=3)

• If excess of budget restricts your group's access:

  Your group is not permitted to place request in NQS. (Excess of the budget)

  (return value=3)

• If excess of budget restricts your account code's access:

  Your account code is not permitted to place request in NQS. (Excess of the budget)

  (return value=3)

• If NQS permits your access:

  You are permitted to place requests in NQS.

  (return value=0)

The following lists headings and field descriptions displayed when -a is specified.

USER	List of users restricted from placing requests in NQS.
GROUP	List of groups restricted from placing requests in NQS.
BUDGET	List of users, groups, and account codes restricted from placing requests in NQS because of excess of the budget.

NAME

qstatc - display the status of NQS queue complex(es)

SYNOPSIS

qstatc [option] [queue-complex-name-list]

DESCRIPTION

qstatc displays queue complex(es) status. queue-complex-name-list displays information about that queue complex. Otherwise, information of all queue complexes on a specified host appear.

Options:

-f

Display detailed information on the queue complex(es) concerned.

-n

Do not display a header.

-h hostname

Specify the queue complex(es) on hostname. The default is the local host.

queue-complex-name-list

Specify the queue-complex-name-list as follows.

queue-complex-name

Queue complex(es) corresponding to the names specified in the host concerned.

queue-complex-name@hostname

Queue complexes corresponding to the names specified by the host defined in host-name.

DISPLAY FORMAT

The following list headings and field descriptions displayed when the -f option is not specified. The host name (maximum 15 characters) appears in the header.

COMPLEX	Queue complex name (maximum 15 characters)
RLM	Maximum number of requests for simultaneous execution assigned to the queue complex
USR	Maximum number of requests per user for simultaneous execution assigned to the queue complex
GRP	Maximum number of requests per group for simultaneous execution assigned to the queue complex
TOT	Total number of requests registered to the queue complex
QUE	Number of requests queued
RUN	Number of requests running
WAI	Number of requests waiting
HLD	Number of requests holding
SUS	Number of requests suspended
ARR	Number of requests arriving
EXT	Number of requests exiting
<TOTAL>	Total of each item RLM, QUE, RUN, WAI, HLD, SUS, ARR, and EXT

The following lists headings and field descriptions displayed when the -f option is specified. queue-complex-name@hostname appears in the header.

RLM	Maximum number of requests for simultaneous execution in queue
TOT	Number of registered requests in queue
QUE	Number of requests queued
RUN	Number of requests running
WAI	Number of requests waiting
HLD	Number of requests holding
SUS	Number of requests suspended
ARR	Number of requests arriving
EXT	Number of requests exiting
<TOTAL>	Total of each item RLM, QUE, RUN, WAI, HLD, SUS, ARR, and EXT However, only the TOTAL of RLM means maximum number of requests for simultaneous execution in the queue complex.
QUEUE NAME	Queue complex construction queue name (maximum 15 characters)
ENA	State (first principal property)
	ENA (enabled)
	DIS (disabled)
	CLS (closed)
STS	State (second principal property)
	STP (stopped/stopping)
	RUN (running)
	INA (inactive)
	SHT (shutdown)
PRI	Inter-queue priority
BPR	Batch base-priority (SUPER-UX only)
TMS	Time slice value (SUPER-UX only)
MPR	Memory scheduling priority (SUPER-UX only)

RUN LIMITS

Run limits of queue complex

User run limit	Maximum number of simultaneous execution requests per user
Grop run limit	Group run limit Maximum number of simultaneous execution requests per group
FSG0(XMU) run limit	File system group 0 (XMU) run limit of complex (SUPER-UX only)
FSG1 run limit	File system group 1 run limit of complex (SUPER-UX only)
FSG2 run limit	File system group 2 run limit of complex (SUPER-UX only)
FSG3 run limit	File system group 3 run limit of complex (SUPER-UX only)
Memory run limit	Memory run limit of complex (SUPER-UX only)

OTHERS

Other parameter(s) (SUPER-UX only)

Resource occupy wait

Resource occupy wait time of complex

NAME

qstatck - display NQS requests which have restart file

SYNOPSIS

qstatck [-c] [-n] [-a] [-p] [-u username] [-h hostname] [-t level]

DESCRIPTION

qstatck displays Network Queuing System (NQS) requests that have restart files. If -u username is omitted, information for all command execution requests for a specified host appears. (Only the NQS manager can use this option.) If -h hostname is omitted, the current host is the assumed target. Some options cannot be used except by the NQS manager. When these options are used by an ordinary user, a warning is issued and no information is displayed.

Options:

-c

Output request-id, request-names, and queue names in full length.

-n

Do not output a header.

-p

Output restart file name with the full path.
This option is available only when the specification of restart file name is permitted by the NQS manager.

-h hostname

Specifies requests on the host specified in hostname. If this option is absent, the current host is assumed.

-t level

Defines the request search level.

level0 (level = 0)

Displays the requests on the host on which the statck command is executed, or the request on the host specified by the -h option.

level1 (level = 1)

Also displays the requests transferred to the remote host or node. Part of the information is omitted but information is displayed at a higher speed than in level 2.

level2 (level = 2)

Also displays the requests transferred to the remote host or node. Complete information of the requests is displayed.

level3 (level = 3)

Rewrite a tracking file which is broken by any troubles on nodes or hosts.

The following options can only be used by the NQS manager:

-u username

Requests concerned are restricted to the specified username.

-a

Refers to all requests on the current host. The specification of the -u and -h is invalidated when -a is specified.

Restart File Attributes

Attributes of the restart file displayed under ATTRIB are as follows:

user	Restart file that is taken by user using the qchk(1) command.
shutdown	Restart file that is automatically taken at NQS shutdown.
hold	Restart file that is automatically taken when currently executed request is held.
illegal	Restart file that is unable to restart.

DISPLAY FORMAT

The following lists the heading and field descriptions displayed when qstatck is issued. Host name appears in the header.

REQUEST ID	Request ID
NAME	Request name
OWNER	Request owner
QUEUE	Submitted queue name
JID	Job ID
ATTRIB ATT	Attributes of restart file USR (user) SHT (shutdown) (only when the -p option is not specified) HLD (hold) ILL (illegal) (ATT appears only when the -p option is specified)
CREATED	Request completion date
ENTERED	Scheduling starting date
CHECKPOINTED	Taking checkpoint date
RESTART FILE	Restart file name (only when the -p option is specified)

NAME

qstatd - display the status of NQS device(s)

SYNOPSIS

qstatd [option] [device-name-list]

DESCRIPTION

qstatd displays the status of NQS device(s). Specify device-name-list to display information on a named device(s). Otherwise, information on all devices for a specified host appears. The following are qstatd options.

Options:

-f

Display detailed information about specified device(s)

-n

Do not display a header.

-h hostname

List the device(s) of the host specified in hostname. The default is the local host.

device-name-list

Specify device-name-list as follows.

device-name

Device(s) corresponding to that specified for a particular host. The default is the local host if the -h option is not used.

device-name@hostname

Device(s) corresponding to that specified for a host defined by hostname.

Device Status

The two properties illustrating the device status or queue state are described next. The first property determines whether the device accepts the submitted request(s). The following states are used.

enabled	The device can accept requests.
disabled	The device is not accepting requests and is in an idle state.
disabled/closed	The device is not accepting requests and is not in an idle state.

The second property determines whether the device is busy. The following states are used.

active	The device is currently busy.
inactive	The device is currently idle but is not known to be out of service.
failed	The device is currently in the idle state and known to be out of service.

DISPLAY FORMAT

The following lists the headings and field descriptions displayed when-fis not specified. In this case, hostname appears on the header.

DEVICE NAME

Device name

ENA

State (first principal property)
ENA (enabled)
DIS (disabled)
CLS(closed)


STS

State (second principal property)
ACT(active)
INA (inactive)
FAI (failed)

FORMS

Relation form list

The following lists the headings and field descriptions displayed when -f is specified. In this case, devicename@hostname appears on the header.

Status

State (first and second principal property)

Fullname

Full path name of device file (/dev/... and so on)

Server

Full path name of usable device server

FORMS

Relation form list

RELATION DEVICE QUEUES

Relation device queue list

NAME

qstatf - display information on NQS form(s)

SYNOPSIS

qstatf [option] [form-name-list]

DESCRIPTION

qstatf displays information on form(s). Specify form-name-list to display information about the named form(s). Otherwise, information for all forms on the current host appear. The following are qstatf options.

Options:

-h hostname

Refer to the form(s) on the host specified in hostname.

-n

Do not display a header.

DISPLAY FORMAT

The following lists the headings and field descriptions displayed when qstatf is issued. In this case, form name appears on the header (maximum is 15 characters).

DEVICE NAME

Device name of members of the form (maximum 15 characters)

ENA

State (first principal property)

ENA (enabled)
DIS (disabled)
CLS (closed)

STS

State (second principal property)

STP (stopped/stopping)
RUN (running)
INA(inactive)
SHT(shutdown)

For more information on the device states, see qstatd.

SEE ALSO

qstatd(1)

qstatq - display the status of NQS queue(s)

SYNOPSIS

qstatq [option] [queue-name-list]

DESCRIPTION

qstatq displays the queue status. Specify queue-name-list to display information about the named queue(s). However, the queue-name-list specification can be invalid depending on the type of option selected, as described under "Options." By default, information on all queues on a specified host is displayed. The following are qstatq options.

Options:

-b

Restrict to batch queues. When specifying this option, queue-name becomes invalid.

-d

Restrict to device queues. When specifying this option, queue-name becomes invalid.

-p

Restrict to pipe queues. When specifying this option, queue-name becomes invalid.

-N

Restrict to network queues. When specifying this option, queue-name becomes invalid.

-f

Display detailed information on the queue(s) concerned.

-L

Display resource limits of batch queues. When specifying this option, queue-name becomes invalid.

-n

Do not display a header.

-h hostname

List queue(s) specified in hostname. Without this option, the default is the local host.

queue-name-list

Specify queue-name-list as follows.

queue-name

The queue corresponds to the name specified on the host.

queue-name@hostname

The queue corresponds to the name specified in hostname

QUEUE STATES

Two properties define the general queue state. The first property determines whether or not requests can be submitted to the queue. The following are Property 1 states.

enabled	The NQS daemon is operating and the queue can accept requests.
disabled	The queue cannot accept requests.
closed	The queue is enabled, but the NQS daemon is not running and no equests are accepted.

Requests can only be submitted to the queue if the queue is enabled. The second property describes what happens to executable requests and also determines if any request in the queue are running. An executable request is ready to run, but is waiting for initiation by the request scheduler. The following lists Property 2 states.

stopped	Queued requests not already running are blocked from running, and no requests are presently executing in the queue.
stopping	Queued requests not already running are blocked from running, and at least one request is presently running in the queue.
running	Queued requests are ready to run and one or more requests are presently running in the queue.
inactive	Queued requests are ready to run and no requests are presently running in the queue.
shutdown	Queued requests are ready to run but the NQS daemon for the local host where the queue resides is not running.

REQUEST STATES

The following lists request states.

arriving	Request is being queued via a pipe queue.
holding	Request is not scheduled and is presently prevented from entering any other state because a hold was placed on the request.
waiting	Request is delayed because 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	Queued requests are scheduled and are therefore eligible to proceed.
routing	Request is being routed (only for pipe queues).
running	Request is being executed.
suspending	The execution of a request is temporarily suspended.
exiting	NQS stdout/stderr files of requests are being staged out.
pre-running	Master request is waiting until all slave requests' execution begins. (available only when the NQS/MPI function is used on the cluster system)
post-running	Master request is waiting until all slave requests' execution finishes. (available only when the NQS/MPI function is used on the cluster system)

DISPLAY FORMAT

The following lists the headings and field descriptions displayed when -f and -L are not specified. In addition, each heading includes letters with the following definitions.

b

list heading is displayed for batch queues

d

list heading is for device queues

p

list heading is for pipe queues.

n

list heading is for network queues.

For each queue, hostname is displayed on the header.

QUEUE NAME (b, d, p, n)

Queue name (up to 15 characters)

DESTINATION MACHINE (n)

Staging out destination host

ENA (b, d, p, n)

State (first principal priority)
ENA (enabled)
DIS (disabled)
CLS (closed)


STS (b, d, p, n)

State (second principal priority)
STP (stopped/stopping)
RUN (running)
INA (inactive)
SHT (shutdown)

PRI (b, d, p, n)

Inter-queue priority

BPR (b) Batch base priority

TMS (b) Timeslice value

MPR (b) Memory scheduling priority

RLM (b, d, p, n)

Maximum number of requests for concurrent execution in queue

TOT (b, d, p, n)

Number of registered requests in queue

QUE (b, d, p, n)

Number of requests in queued state

RUN (b, d, n)

Number of requests in running state


When the NQS/MPI function is used on the cluster system, number of requests in pre-running state and post-running state is added.

ROU (p) Number of requests in routing state

WAI (b, d, p, n)

Number of requests in waiting state

HLD (b, d, p)

Number of requests in holding state

SUS (b) Number of requests in suspending state

ARR (b, d, p)

Number of requests in arriving state

EXT (b) Number of requests in exiting state

<TOTAL> (b, d, p, n)

Total of each item RLM, TOT, QUE, RUN, WAI, HLD, SUS, ROU, ARR, and EXT. However, only TOTAL of RLM means maximum number of requests for concurrent execution for all batch/pipe/network queues.

The following lists the headings and field descriptions displayed when -L is specified.

In this case, hostname appears on the header (maximum is 15 characters).

QUEUE NAME	Queue name(up to 15 characters)
TOTAL	Run limit of the queue (SUPER-UX)
USER	User run limit of the queue (SUPER-UX)
GROUP	Group run limit of the queue (SUPER-UX)
XMU	File System Group 0 (FSG0 = XMU) run limit of the queue (SUPER-UX)
CPU/P	Per-process CPU time limit
MEM/P	Per-process memory size limit
PFCP/P	Per-process permanent file capacity limit
OFIL/P	Per-process open file number limit
PFSZ/P	Per-process permanent file size limit
DAT/P	Per-process data segment size limit
STK/P	Per-process stack segment size limit
NCPU/P	Per-process number of CPU limit
COR/P	Per-process core file size limit
CPU/R	Per-request CPU time limit
MEM/R	Per-request memory size limit
PFCP/R	Per-request permanent file capacity limit
TPCP/R	Per-request temporary file capacity limit
OFIL/R	Per-request open file number limit
DRV/R	Per-request tape drives limit
PRC/R	Per-request process number limit
FSG0/R	Per-request file system group 0 (XMU) limit
FSG1/R	Per-request file system group 1 limit
FSG2/R	Per-request file system group 2 limit
FSG3/R	Per-request file system group 3 limit
CPRT/P	Per-process CPU resident time limit
CPRN/P	Number of CPUs as the target of the per-process CPU resident time limit
CPRT/R	Per-request CPU resident time limit
CPRN/R	Number of CPUs as the target of the per-request CPU resident time limit

The following lists the headings and field descriptions displayed when -f is specified. In addition, each heading contains letters with the following definitions.

b

list heading is displayed for batch queues

d

list heading is for device queues

p

list heading is for pipe queues

n

list heading is for network queues

For each queue, queuename@hostname appears in the header.

Priority (b, d, p, n)

Inter-queue priority

Status (b, d, p, n)

State (first and second principal property)

Base Batch Priority (b)

Base priority

Time slice value (b)

Timeslice value

Nice Value (b)

Nice value

Memory Priority (b)

Memory scheduling priority

Mod factor of CPU1 (b)

Modification factor of CPU

Tick Count (b)

Tick count

Decay factor (b)

Decay factor

Decay interval (b)

Decay interval

Mrt Size Effect (b)

Effect of process size on Memory Resident Time (MRT)

Mrt Pri Effect (b)

Effect of memory Scheduling Priority on MRT

Aging Range (b)

Aging range

Mrt Minimum (b)

MRT minimum

Slave Priority (b)
Slave priority

Scheduling Mode (b)

Request scheduling method

Continuous Scheduling Number (b)

Per-user continuous scheduling number

Default Scheduling priority (b)

Default scheduling priority

Resource occupy wait (b)

Resource occupy wait time

Resource Sharing Group (b)

Resource sharing group (RSG)

CPU count(b)

CPU count value

Queue server (p, n)

Server path name used when routing requests or staging out

ENTRIES

Number of registered requests in queue

Total (b, d, p, n)

Total number of registered requests in queue

Queued (b, d, p, n)

Number of requests in queued state

Running (b, d, n)

Number of requests in running state


When the NQS/MPI function is used on the cluster system, number of requests in pre-running state and post-running state is added.

Routing (p)

Number of requests in routing state

Waiting (b, d, p, n)

Number of requests in waiting state

Held (b, d, p)

Number of requests in holding state

Suspending (b)

Number of requests in suspending state

Arriving (b, d, p)

Number of requests in arriving state

Exiting (b)

Number of requests in exiting state

COMPLEX MEMBERSHIP (b)

Relation queue complex list

RUN LIMITS

Maximum number of simultaneous execution requests in queue

Total run limit (b, d, p)

Maximum number of simultaneous execution requests in queue

FSG0 run limit (b)

File system group 0 (XMU) run limit

FSG1 run limit (b)

File system group 1 run limit

FSG2 run limit (b)

File system group 2 run limit

FSG3 run limit (b)

File system group 3 run limit

Memory run limit (b)

Memory run limit

User run limit (b, p)

Maximum number of simultaneous execution requests per user

Group run limit (b, p)

Maximum number of simultaneous execution requests per group

DEVICES (d)

Relation device list

DESTINATIONS (p)

Requests destination queue list

DESTINATION MACHINE (MID) (n)

Name of the staging out destination host (machine ID)

RESOURCE LIMITS

Resource limit names and resource limit values (format: name = value). If the default standard mode is on, resource standard values also appear in the format: (S: value).

Per-process (b)

Per-process resource limit names and their values

Per-request (b)

Per-request resource limit names and their values

ACCESS

Lists access restriction

Route (b, d, p)

Existence or nonexistence of the pipe only attribute

User (b, d, p)

List of users who can access this queue (when nothing appears with the above "ACCESS"), or

List of users who cannot access this queue (when "(DENY)" appears with the above "ACCESS")

Group (b, d, p)

List of groups who can access this queue (when nothing appears with the above "ACCESS"), or

List of groups who cannot access this queue (when "(DENY)" appears with the above "ACCESS")

When all users and groups can access this queue, the string "Unrestricted access" appears.

ATTRIBUTE (b, p)

Attributes of a queue

LOAD BALANCE (b, p)(appears only on the cluster system)

Whether a queue is to be used for the demand delivery method (ON or OFF)

BEFORECHECK (p)

Whether a queue is to be used for the check function (ON or OFF)

STAYWAIT (p)

Whether a queue is to be used for the staywait function (ON or OFF)

FREE DESTINATION (p)

Whether the queue destination is free (ON or OFF)

TRANSPARENT (p)

Whether a queue is the transparent pipe queue (ON or OFF)

MPI_MASTER (b)

Whether a queue is the master queue (appears only when the NQS/MPI function is used and the queue is the master queue (= ON))

MPI_SLAVE (b)

Whether a queue is the slave queue (appears only when the NQS/MPI function is used and the queue is the slave queue (= ON))

LOAD BALANCING PARAMETER (b, p)

Attribute of a queue for demand delivery method (appears only on the cluster system when LOAD BALANCE is ON)

Keeping request number limit (b)

Keep request limit

Delivery wait time (b)

Delivery wait time

Reserved run limit (p)

Reserved run limit

Destination retry wait (p)

Destination retry wait time

FORCE RESTART MODE

Whether the restart(2) restarts a request by force in the following case
(ON means restarts forcely, and OFF means stop restarting)(SUPER-UX)

When file open failed (b)

When the checkpoint file cannot be opened

When file modified (b)

When the checkpoint file has been modified

RELATED MPI QUEUES (b)

List of the master queues and the related slave queues that the MPI processes are executed as NQS requests

Appears only when MPI_MASTER is ON.


The format is "label(queue-name@node-name)".

CUMULATIVE TIME

Cumulative time

System space time (b, d, p, n)

Cumulative system space time

User space time (b, d, p, n)

Cumulative user space time

NAME

qstatr - display the status of NQS request(s)

SYNOPSIS

qstatr [-a] [-b] [-c] [-d] [-N] [-R] [-l] [-f] [-n] [-t level] [-h hostname] [-u username]
[request-id ...]

qstatr [-a] [-b] [-c] [-d] [-N] [-R] [-l] [-f] [-n] [-t level] [-h hostname] [-u username]
[-r request-name ...]

DESCRIPTION

qstatr displays the status of all NQS requests. Specify request-id-list to display information on the request(s) concerned. Otherwise, information on all requests owned by command execution appears.

A warning appears when this option is used by users and information does not appear. The following are qstatr options.

Options:

-b

Display batch request status.

-c

Output queue names, request-names, and request-id in full length.

-d

Display device request status.

-N

Display network request status.

-R

Instead of the currently used memory size, the currently assigned memory size appears. When -f is specified, this option is ignored.

-l

Instead of the currently consumed CPU time, the remaining CPU time appears. When -f is specified, this option is ignored.

-f

Display full information on request(s).

-n

Do not display a header.

-t level

Defines the request search level.

level0 (level = 0)

Displays only the requests on the host executed by the qstatr command or specified by the -h option.

level1 (level = 1)

Also displays the requests transferr