You can communicate with your request as it executes. This chapter discusses the communication methods available to you. The following topics are covered:
Monitoring the job log or event history (“Monitoring the Job Log or Event History”)
Writing messages to output files (“Writing Messages to Output Files”)
Monitoring output during execution (“Monitoring Output during Execution”)
You can use one of the following methods to view the contents of a request's job log file or event history at any time that the job is running.
If you use the NQE GUI, use the Actions menu of the NQE GUI Status window. To use the Actions menu, first position the pointer on the desired job line in the job summary area and highlight it by pressing the left mouse button, then select Job Log on the Actions menu.
For an NQS request, use the cqstatl or qstat command; for example, you can use the following command on the server on which the request is executing (specified by NQS_SERVER):
cqstatl -d nqs -j requestid
The output is the job log file and it will look similar to the following example:
11/03 10:17:48 Arrived in <[email protected]> from <latte>. 11/03 10:17:53 Arrived in <[email protected]> from <latte>. 11/03 10:17:54 Arrived in <[email protected]> from <[email protected]>. 11/03 10:17:56 Started, pid=<20624>, jid=<8215>, shell=<>, umask=<23>. 11/03 10:17:56 Running in queue <express>.
If your request is running on a server other than the one specified by NQS_SERVER, you can change the value of your NQS_SERVER environment variable or you can use the cqstatl -h or qstat -h command to specify that host name, as in the following example:
cqstatl -d nqs -h ice -j requestid
For an NQE database request, use the following command (the qstat command cannot be used for an NQE database request):
cqstatl -d nqedb -j tid
The output includes an event history of the NQE database tasks, as shown in the following example:
carob$ cqstatl -d nqedb -j t1 Event History for NQE Task: t1 07/25/96 07:57:42 t1: NEW_STATE state=Pending (ack=1) 07/25/96 07:57:53 t1: NEW_STATE state=Scheduled owner=lws.carob (ack=1) 07/25/96 07:58:01 t1: NEW_STATE state=Submitted (ack=1) 07/25/96 07:58:01 t1: SUBMIT NQS Request ID 9.carob (ack=1) 07/25/96 07:59:07 t1: NEW_STATE state=Completed owner=scheduler.main (ack=1) 07/25/96 07:59:08 t1: NQS exit.status=0 (ack=1) 07/25/96 07:59:13 t1: NEW_STATE state=Completed owner=monitor.main (ack=1) |
You can write messages to the job log file as described in “Writing Messages to Output Files”.
If an event has occurred, or will occur, that could affect your executing request, you can write a message to record that event to the output files produced by the request. To write this message, use the following command:
qmsg |
 | Note: You must issue the qmsg command from the NQS server on which the request is running. |
By default (or if you use the qmsg -j command), the qmsg command writes the message to the job log file of the request.
| Note: You cannot write job log messages to requests in the NQE database; you can write job log messages only to requests running on NQS. |
To send a message to the standard output file of a request, use the qmsg -o command. To send a message to the standard error file of a request, use the qmsg -e command.
If your NQE administrator configures the default return of the job log files as off, and your qmsg command provides no specific destination, the message is written to the standard error file.
After entering the qmsg command line, you can enter the lines that make up the message. To end each line, press RETURN. When you have typed in all of the lines of the message, press CONTROL-d to end the message.
The following example shows a message being written to the standard output file of a request:
% qmsg -o 407.coal An important event occurred a few seconds ago. George made the coffee. CONTROL-d |
If qmsg successfully writes the message to the request's output file, you do not receive a message.
You can send messages to the standard output and standard error files of only those requests that are executing under your own user name (unless you are defined as an NQS operator or manager). You also must be logged on to the NQS server on which your request is executing.
If you get the following message, it means that your request has not yet started to execute:
Request's stderr file does not exist |
Wait a few seconds and try again.
If you get the following message, it means that the request completed execution or was sent to another system for execution:
Request 407.coal does not exist |
Therefore, you cannot write to the request's output files.
By default, the standard output and standard error files generated by your request are not available to you until the request completes execution. You can use the NQE GUI or the command options described in this section to examine the standard output and standard error files as your request executes. If you cannot find your standard output and standard error files, see “Output Files Cannot Be Found” in Chapter 16.
Through command options, NQS supports the writing of standard output and standard error files that a request produces to a directory on the server at which the request is executing. If the destination files are at an NQS server other than the execution server, these options are ignored.
You must submit your request to the server on which the output files will be written. If you do not know the server on which the output files will be written or do not specify the server, the options described in this section are ignored, and you cannot view your output during execution.
| Note: If the UNICOS MLS feature or the UNICOS/mk security
enhancements are enabled on your system, the job output files
are labeled
with the job execution label. For jobs that are submitted locally, the return
of the job output files may fail if the job submission directory label does
not match the job execution label. For example, if a job is submitted from
a level 0 directory, and the job is executed at a requested level 2, the job
output files cannot be written to the level 0 directory. If the home directory
of the UNICOS user under whom the job ran is not a level 2 directory, does
not have a wildcard label, or is not a multilevel directory, the job output
files cannot be returned to that directory either. The job output files will
be stored in the NQS failed directory.
If the UNICOS MLS feature or the UNICOS/mk security enhancements on are enabled on your system and you submitted a job remotely, the Internet Protocol Security Options (IPSO) type and label range that are defined in the network access list (NAL) entry for the remote host affect the job output file return. |
You can indicate a specific execution server when submitting your request in the following ways:
If you use the NQE GUI, open the Config window and change the NQS Server field of the NQE User Preferences menu (the NQE User Preferences menu is the default Config window).
If you use the cqsub or qsub command, use the -q queue option; queue designates a batch or a pipe queue that has a destination batch queue on the execution server that will run your request.
Set the NQS_SERVER environment variable to the execution server name.
The file name you specify for the output can include the name of an NQS server and a directory path. A simple file name indicates that the file will be written to the directory you were in when you submitted your request.
To examine the standard output and standard error files as your request executes, use the NQE GUI Submit window and select Output Options on the Configure menu. Ensure that the following options are selected, and apply your change (click on the Apply button) if you need to select any of them:
Write STDOUT during execution
Write STDERR during execution
To save your changes, use the Save Current Job Profile menu option on the Configure menu.
You also can merge STDOUT and STDERR by selecting the Merge STDOUT and STDERR option and applying your change (click on the Apply button). For additional information about working with output files, see Chapter 6, “Working with Output Files”.
To examine the standard output and standard error files as your request executes, you must submit your request to your local server only. Use the following command when you submit the request:
qsub -o ofile -ro -e efile -re |
The -ro and -re options specify that the standard output and standard error files will be written as they are produced (rather than after the request completes execution). NQS supports these options only for output files that are being written to the system at which the request is being executed.
If you use the -ro and -re options, the output is placed in the file (ofile or efile) as the request executes. The file name you specify for ofile and efile can include the name of an NQS host and a directory path. A simple file name indicates that the file will be written to the UNICOS directory that was current when you submitted the request.
Path names specified by the -o and -e options that are not complete are interpreted on the originating machine. Ensure (by using the complete path name, if necessary) that the output file names are valid on the execution machine. This is true whether or not the -ro or -re options are used.
If the -ro and -re options are used, the output may not appear immediately in the output files due to stdio buffering (as much as 4Kb may be buffered). If the job output is small, it may not appear until the job completes.
For UNICOS systems, do not modify or remove the files until the request has completed execution; if a system shutdown occurs, they will be needed for request recovery.
To ensure that your request has completed execution, use the cqstatl -a command or the qstat -a command to display summary details of your requests; for example:
qstat -a |
To display the request's job log file at any time, use the cqstatl -j command or the qstat -j command; for example:
qstat -j requestid |
To merge the standard error file and the standard output file, use the cqsub -eo command or the qsub -eo command. For example, to combine the files and to write the output file to a specific file, you can use the following qsub options:
qsub -ro -o ofile -eo |
In the following example, jane submits the request test to the queue gust, which is a pipe queue that has a destination batch queue on the NQS server gust. She specifies that she wants the standard output and standard error files merged, and that the output file that has the name TESTOUT will be placed in the tmp directory.
If jane uses the NQE GUI, she would to the following:
To set her server to be her local server gust, jane would open the Config window and change the NQS Server field of the NQE User Preferences window to be gust, apply her change, and cancel the Config window. (The NQE User Preferences window is the default Config window.)
Open the NQE GUI Submit window.
Select General Options on the Configure menu, and do the following:
Enter test in the Request Name field.
Enter gust in the Queue Name field.
Apply the changes and cancel the General Options menu.
Select Output Options on the Configure menu, and select the following options:
Write STDOUT during execution
Merge STDOUT and STDERR
Keep STDOUT on execution host
Change the output directory path and name of the output file by entering /tmp/TESTOUT in the Alt STDOUT Path field.
Apply the changes and cancel the Output Options menu.
Submit her request test, as described in Chapter 4, “Submitting Requests”.
To save all of the changes made so she can use them in the future, jane would use the Save Current Job Profile option on the Configure menu.
If jane uses the cqsub or qsub command, she can do the following:
Ensure that NQS_SERVER is set to gust.
Enter the following command line, for example:
cqsub -eo -o gust:tmp/TESTOUT -ro -q gust test
After the request has been submitted, jane can log in to the server gust, change to the directory she specified, and view the file, as follows:
Request 4636.ice submitted to queue: gust. snow% rlogin gust Sun Microsystems Inc. Solaris 2.5 gust% cd tmp % tail TESTOUT job start /gust/u1/jane Wed Feb 18 12:32:43 CST 1998 gust gust% |