If you cannot find a request, try the following steps to locate it.

A request may be queued without being run for the following reasons.

cqstatl -f -h target_host requestids

cqstatl -f queues

Unless the user specified a different location for these files, they should be in the directory that was current when the request was submitted. If they are not there, check the user's home directory or the home directory at the remote system of the user under which the request executed.

If you cannot find any output files, check for electronic mail messages sent to the user. NQS might have removed the request for a variety of reasons (for example, it requested more of a resource than was allowed for that user or the request violated your system's security). The mail message contains a description of the problem.

The user may get a mail message stating that the standard output and error files could not be written back to the user's system. The message indicates where these files were actually placed (usually in the home directory of the remote user under which the request was run). These files usually cannot be written back because the user's home directory does not contain a suitable validation file entry that authorizes NQS to write the output files. However, it also may be due to a problem with the network connection to the NQS system.

NQS tries the following methods to return output to a user:

If the standard error file contains an excessive number of syntax errors, the user may be using the wrong shell. Usually, it is the shell flow control commands (such as if, while, for, and foreach) that cause errors when the wrong shell is used. Ensure that the user is using the correct shell strategy.

If the user receives an error message such as file not found or file does not exist in the standard error file, the batch request may have tried to access a file that could not be found.

NQS assumes that any files the user is trying to access are in the home directory of the user at the execution host. To indicate that a file is in another location, the user should either specify the full path name or use the cd command to move to that directory before trying to access the file within the batch request script.

NQS can shut off a queue or several queues (with no intervention from a manager or operator). The reason for the action might be that the nqsdaemon session reached a process limit or that it cannot allocate a resource. To determine the reason, you should examine the NQS log file. After determining the reason and correcting the problem, the queue(s) can be restarted manually.

Requests may unexpectedly switch states from queued to wait. A checkpointed UNICOS, UNICOS/mk, or IRIX request may be waiting for a specific process or a job ID to become available. When it becomes available, the request will remain in queued state until it executes.

Most qmgr commands can be executed only by an NQS manager or operator. An operator can issue only a subset of the commands that are available to the manager. If you try to use a command that you are not allowed to use, the following message is displayed:

NQS manager[TCML_INSUFFPRV ]: Insufficient privilege at
local host.

If NQS or qmgr fails with a no local machine id message, and the site is using DNS (Domain Name Service) to resolve host names, follow these procedures:

qmgr can now find the machine ID for the host name of the local machine.

If NQS appears to be running slowly, you may need to edit the /etc/hosts file.

Because NQS supports networks of machines, it uses the gethostbyname system call to get the host information for a request. The implementation makes calls to this routine while processing all requests, including requests that are submitted on a local machine for execution on the local machine.

The gethostbyname system call looks up the host name by doing a sequential search of the /etc/hosts.bin binary file (or the text version /etc/hosts if the binary file does not exist).

The bigger the host file, and the further down in the file the local machine name appears, the longer it will take for the system call to complete, and the longer the nqsdaemon will take to process requests.

To solve this problem, edit the /etc/hosts file so that the local machine appears at the top of the file, then use the mkbinhost file to make a new copy of the binary /etc/host.bin file.

NQE allows an administrator to expand the default scope of the information displayed to non-NQS managers using the qstat(1) or cqstatl(1) commands. The default behavior for these commands is to display information only to non-NQS managers regarding jobs that they have submitted themselves. To let users display the status of all jobs residing at that NQS node when they execute the qstat(1) or cqstatl(1) command, use the NQE configuration utility (nqeconfig(8) command) and set the nqeinfo file variable NQE_NQS_QSTAT_SHOWALL to 1, which modifies the information that is displayed to the users of these commands.

If the NQS_SERVER environment variable is not set, the client tries to connect to the NQS server on the local host. If the user cannot connect to a local NQS server, the following message is displayed:

QUESR: ERROR: Failed to connect to NQS_SERVER at host[port]
obtaining UNIX environment failed
NETWORK: ERROR: Connect: Connection refused

Ensure that the NQS_SERVER environment variable is set. This must be set in each user's environment to contain the host name of the machine running the NQS server.

It also may be true that the NQS server is not running or that a networking problem exists between the workstation and the NQS server (see “Network Debugging”).

NQE clients are installed with set UID (suid), are owned by root, and use secure ports. This means that clients running at a specific NQE release level are rejected if they try to connect to an NQE server running at a different NQE release level. The following messages are displayed:

QUESRV: ERROR: Failed to retrieve status information
QUESRV: ERROR: Non-secure network port verification error at
transaction peer
QUESRV: ERROR: Received response NONSECPORT (01462) for
transaction NPK_QSTAT

If you receive these messages, you should upgrade your client software.

A request that remains in an NQS queue for a long time without executing usually indicates that NQS is not running or that the machine system itself is not running.

However, you should check the status of the queue in which the request is waiting to see whether the queue is currently stopped. Enter the qmgr command show queue and look under the column STS, which displays on when the queue is started. A stopped queue cannot process requests that are waiting in it.

You also can check any request attributes specified on the cqsub or the qsub command line. Ensure that they match the attributes of the batch queue.

The default validation type in NQS is file validation. File validation requires a .rhosts (or .nqshosts) file in the home directory of your account on all of the NQS server systems on which your request may run. This applies even if your target NQS server is your local machine.

If a client command returns the message No account authorization at transaction peer, or if a cqsub command results in the message being returned in a mail message, one of the following may be true:

Before you can use the NQE commands, you must add the NQE bin and etc directories to your search path. Before you can use the man pages (which tell you about the NQE commands and command options), you must add the NQE man directories to your search path. For a description of how to set these variables, see Introducing NQE, publication IN-2153.

If you submit requests by using the cqsub or qsub command and receive ctoken generation failure messages in the NQS log, it indicates that NQS tried to use FTA to deliver output files and did not find a user-supplied password, a .netrc file, or an NPPA S-key. The log also contains a message indicating that the FTA transfer failed.

When NQS returns output, it tries to use FTA. FTA checks first for a user-supplied password on the cqsub or qsub command. (To determine the syntax used to specify the FTA password, see the description of the -e option on the cqsub(1) or qsub man page.)

If no password was supplied, FTA tries to send the output to the host and user (with an associated password) by using the user's .netrc file on the NQS execution host. If no .netrc file exists, FTA tries to send the file by using NPPA. If you have not defined S-keys as described in “Configuring S-keys” in Chapter 13, you will receive ctoken generation failure messages.

NQS then tries to return the output by using rcp.

You can ensure that you do not receive the messages by using any of the following methods:

If your NQE Load display fails, ensure that your NLB_SERVER environment variable is set to a host that is running an NLB server. You do not have to specify the host port number unless the NLB server is configured with a NLB port number that is different from the default (604) provided during installation.

If NLB commands report that they cannot determine the server location, no information is available to locate the server. NQE may not have been configured on the host. To connect to the server, define the NLB_SERVER environment variable or use the -s option on the command line.

If a collector is running on a host, but no data appears in the NLB server for that host, check the following:

If you have modified the policies file and the nlbconfig -pol command reports an error, the policies file that you downloaded to the server may contain a syntax error. If this is true, the nlbconfig -pol command fails; however, you do not receive an explanation of the error. To see the error, stop the server (with nlbconfig -kill) and start it again (with nlbserver). Any errors in parsing the policy file will be reported to stderr. The server does not treat an error in the policy file as fatal, but load balancing will not work until you have a correct policies file.

Collectors on Solaris systems may report incorrect data under the following conditions:

If you are using a policy and getting unexpected results, probably the wrong policy is being used. If a policy name is not defined, a default policy is used. The policy name might be defined incorrectly if you misspell the policy name either in the NQS queue definition or in the nlbpolicy command.

If you try to modify the ACL for object type C_OBJ, you will receive the message No privilege for requested operation. You cannot modify the ACL for C_OBJ because it is fixed. It consists of the master ACL plus WORLD read permission. These permissions are necessary because, if a user cannot read the C_OBJ object type, most commands will fail.

A client trying to connect to the NQE database without the proper validation will result in an error such as the following:

NETWORK: ERROR: NQE Database connection failure:
         Connection disallowed.
latte$

If this occurs, verify that the user has an entry in the nqedbusers file. For additional information about the nqedbusers file, see Chapter 9, “NQE Database”.

If a user is trying to submit a request to the NQE database and the NQE database server is not up, the following message will be sent:

NETWORK: ERROR: NQE Database connection failure:
         Cannot connect to MSQL server on latte.
latte$

For additional information on checking network connectivity, see “Network Debugging”.

The first step in network debugging is to ensure that the machine that is being accessed can be reached by the local host.

To ensure that you can access a host through TCP/IP, use the ping command. This command sends a data packet to the destination host and does not rely on the presence of any specific service at the destination. For example, if the node name is rhubarb, enter the following command:

ping rhubarb

Entering the previous command can result in several replies:

If the host-to-host network connection is running, the next step is to examine the individual connections on your machine and the machine with which you are trying to communicate.

The main tool for examining TCP/IP connections is the netstat command, which examines kernel data structures and prints the current state of all connections to and from the host on which it is run. For more information on how to use this command, see the operating system manuals for your machine.

When you specify the netstat(1) command without any parameters, it reports each open connection on a machine; netstat -a also reports the connections offered by servers.

The most important information to check is the protocol type (Proto), your local address (Local Address), and the status of the connection (state).

If you receive connection failed messages, ensure that your NQS_SERVER environment variable is set to a host that is running an NQS server. You do not have to specify the host port number unless the NQS server is configured with an NQS port number that is different from the default (607) provided during installation.

If a transient network error condition exists that allows the connection to be retried, you will receive messages such as the following:

Retrying connection to NQS_SERVER on host ice (127.111.21.90) . . .
Retrying connection to NQS_SERVER on host ice (127.111.21.90) . . .
QUESRV: ERROR: Failed to connect to NQS_SERVER at ice [port 607]
NETWORK: ERROR: NQS network daemon not responding

These messages indicate that the command received a connection refused error from the connect () system call or that an address it is trying to use is temporarily in use. This could be true, for example, because the server is just coming up or is not listening, or the network is busy. NQS retries its connection to the server for 30 seconds.