This chapter describes how output files are returned to you and the options you have to control their location and content. The following topics are discussed:
Naming output files (“Naming Output Files”)
Redirecting output (“Redirecting Output”)
Merging output files (“Merging Output Files”)
Finding lost output (“Finding Lost Output”)
For a summary of the cqsub or qsub command options that you can use to control output, see the cqsub(1) or qsub(1) man page.
For information about viewing output files as requests are executing and writing messages to output files, see Chapter 7, “Communicating with Requests”.
After your batch request has completed execution, NQS returns the standard output, standard error, and job log files that the request produced. Your NQE administrator configures whether job log files are returned by default. If you do not receive a job log by default, you can specify that you want one by setting NQE GUI options or by using the appropriate cqsub or qsub command options.
The standard output file is referred to as stdout. This file contains output produced by your request and other system-generated information.
The standard error file is referred to as stderr. This file contains any error messages that the request generates.
The job log file contains a record of all of the events NQS processed for your request.
The output files are named as follows:
| Standard output file: | name.onumber | |
| Standard error file: | name.enumber | |
| Job log file: | name.lnumber |
 | Note: NQS supports DFS path name formats for the standard output file, standard error file, and job log options so that job output can be returned to DFS. |
The strings shown in italics can take the following values:
| String | Value |
| name | The request name. If you submitted the request as standard input, the name is STDIN. If you submitted a script file, name is the first 7 characters of the file name. To change these defaults by using the NQE GUI, open the Submit window and select Output Options from the Configure menu. Enter the alternative name (use the full path name) after the appropriate output file option (Alt STDOUT Path, Alt STDERR Path, and/or Alt JOBLOG Path). To change these defaults by using the command line interface, use the cqsub command or the qsub command -r, -o, -e, and -j options. If you use the -r option, name is the first 7 characters of the string you specified. For more information on redirecting output, see “Redirecting Output”. |
| number | The number that NQE assigns when the request is submitted. For a job going through the NQE database, the number is the task ID; for a job that is not going through the NQE database, the number is the request ID. |
For example, you submitted a request that has the file name mytestjob, and you specified that you want to receive a job log. Successful submission and execution of the request would produce a standard output file that has the name mytestj.o406, a standard error file that has the name mytestj.e406, and a job log file that has the name mytestj.l406.
Request 406.coal submitted to queue: nqenlb. % ls mytestjob mytestj.e406 mytestj.o406 mytestj.l406 |
If UNICOS MLS or UNICOS/mk security enhancements are enabled on the execution system, the output file returned to a remote host is created at the job execution label. You must specify a remote host directory that has either a wildcard label or a label that matches the job execution label, or that is a multilevel directory.
By default, your output files are returned to the directory from which you submitted the request. To specify another location and name for the files, use the cqsub or the qsub command options.
You can specify a location for stdout, stderr, and your job log file.
If you use the NQE GUI, to change these defaults, select Submit -> Configure -> Output Options. Enter the alternative name (use the full path name) after the appropriate output file option (Alt STDOUT Path, Alt STDERR Path, and/or Alt JOBLOG Path).
If you use the cqsub or the qsub command, the following commands or options place your files in the locations described:
| Command or option | |
Location of output | |
| cqsub or qsub | |
Directory from which you submitted the request. Its file name is STDIN.orequestid_number. | |
| -o filename | |
Directory from which you submitted the request. Its file name is filename.orequestid_number. | |
| -o host:filename | |
Specified server and file name. The directory is your home directory on host. The file name is filename. | |
| -o "%[user[/password]@]host[/domain]:pathname" | |
Specified user, host, and path name. The pathname can be a simple file name or an absolute path. If the pathname is a simple file name, the file is placed in your home directory on the specified host. The domain specifies an FTA domain name that uses network peer-to-peer authorization (NPPA) rather than a password. If you do not use NPPA, you can provide a password. | |
The following three DCE/DFS file name formats are supported:
/:/your_file /.:/fs/your_file /.../your_cellname/fs/your_file |
You can merge the standard error file and the standard output file in the following ways:
If you use the NQE GUI, select the Merge STDOUT and STDERR option in the Output Options window of the Configure menu and apply your change (click on the Apply button).
If you use the cqsub or qsub command, the following options let you merge your output files into one file:
Option Description
-eo Appends stderr to stdout.
-J m Appends the job log to stdout.
To merge your output into a single file, use these options with either the cqsub or qsub command; for example:
cqsub -eo -J m
If your output is not in the directory you were in when you submitted the request or in a location you specified, you first should check electronic mail. If NQS has tried to write your output to a directory different from the one you specified, it sends you mail.
The mail message indicates where your output files were actually placed, as shown in the following example:
From [email protected] Mon, 5 Jan 34:41 CST 1998 Date: Mon, 5 Jan 1998 12:34:41 -006 From: [email protected] Subject: NQS request: 2172.coal ended Message concerning NQS request: 2172.coal ended. Request name: testjob Request owner: jane Mail sent at: 11:39:04 CDT Request exited normally. _Exit() value was: 0. Stdout file staging event status: Destination: -o coal:/home/usr/jane/testjob.o2172 Output file could not be returned to primary destination. Output file successfully returned to backup destination in user home directory on the execution machine. Transaction failure reason at primary destination: No account authorization at transaction peer. Stderr file staging event status: Destination: -e coal:/home/usr/jane/testjob.e2172 Output file could not be returned to primary destination. Output file successfully returned to backup destination in user home directory on the execution machine. Transaction failure reason at primary destination: No account authorization at transaction peer. |
Usually, the reason your output files could not be written to your directory is because your home directory does not contain a suitable validation file entry authorizing NQS to write the output files. See Chapter 2, “Preparing to Use NQE”.
If NQS cannot return the files to the requested directory and host, it tries to place it in the following directories:
Your home directory on the NQS execution server. This is the server at which your request executed, not necessarily the one defined by NQS_SERVER. If this placement is successful, NQS sends you a mail message indicating that it used an alternate (secondary) output destination. The From: line of the mail message includes the name of the host that received the output file.
If you submitted the request by using a different user name, NQS tries to send the output to the home directory of that user name and sends the mail message to you.
A special failed directory on the NQS execution server. If you receive a mail message telling you that this has occurred, contact your NQE administrator.
When using DCE/DFS, note the following:
After a request completes, NQS uses kdestroy to destroy any credentials obtained by NQS on behalf of the request's owner.
Caution: On UNICOS systems, do not put a kdestroy within a request's job script; it will destroy the credentials obtained by NQS and prevent NQS from returning request output files into DFS space. On UNIX platforms, there is not an integrated login system feature available. NQS on UNIX platforms obtains separate DCE credentials for request output return. Therefore, a kdestroy placed within a request's job script running on an NQE UNIX server will not affect the return of request output files into DFS space.