stork_ submit

submit a Stork job

Synopsis

stork_ submit [-help | -version]

stork_ submit [-debug] [-stdin] [-name server_specification] [-lognotes "prose"] submit-descpription-file

Description

stork_ submit is used to submit a Stork data placement job. Upon job submission, an integer identifier is assigned to the submission, and it is printed to standard output. This job identifier is required by other commands that manage Stork jobs.

The name of the Stork submit description file is the single, required, command-line argument. Stork places no constraints on the submit description file name. See section 2.12, for a more complete description of Stork.

STORK SUBMIT DESCRIPTION FILE COMMANDS Stork submit description files use ClassAd syntax, different from Condor submit file syntax. See http://www.cs.wisc.edu/condor/classad/.

dap_type = transfer;

Required command identifying that there will be a transfer from source to destination.

arguments = "<argument_list>";

List of arguments to be supplied to the module on the command line. Arguments are delimited (separated) by space characters.

input = "<pathname>";

Stork assumes that its jobs are long-running, and that the user will not wait at the terminal for their completion. Because of this, the standard files which normally access the terminal, (stdin, stdout, and stderr), must refer to files. Thus, the file name specified with input should contain any keyboard input the program requires (that is, this file becomes stdin). If not specified, the default value of /dev/null is used for submission to a Unix machine.

stork_ submit will prepend the current working directory if the pathname is relative (does not start with a / character). This implies that the submit directory must be shared between stork_ submit and the Stork server host, when using relative paths. All local file paths passed to Stork must be valid on the Stork server host.

Note that this command does not refer to the command-line arguments of the program. The command-line arguments are specified by the arguments command.

output = "<pathname>";

The output file name will capture any information the program would normally write to the screen (that is, this file becomes stdout). If not specified, the default value of /dev/null is used for submission to a Unix machine. Multiple jobs should not use the same output file, since this will cause one job to overwrite the output of another. The output file and the error file should not be the same file as the outputs will overwrite each other or be lost.

Note that if your program explicitly opens and writes to a file, that file should not be specified as the output file.

stork_ submit will prepend the current working directory if the pathname is relative (does not start with a / character). This implies that the submit directory must be shared between stork_ submit and the Stork server host, when using relative paths. All local file paths passed to Stork must be valid on the Stork server host.

err = "<pathname>";

The err file name will capture any error messages the program would normally write to the screen (that is, this file becomes stderr). If not specified, the default value of /dev/null is used for submission to a Unix machine. More than one job should not use the same error file, since this will cause one job to overwrite the errors of another. The error file and the output file should not be the same file as the outputs will overwrite each other or be lost.

stork_ submit will prepend the current working directory if the pathname is relative (does not start with a / character). This implies that the submit directory must be shared between stork_ submit and the Stork server host, when using relative paths. All local file paths passed to Stork must be valid on the Stork server host.

log = "<pathname>";

Use log to specify a file name where Stork will write a log file of what is happening with this job cluster. For example, Stork will log into this file when and where the job begins running, when the job is checkpointed and/or migrated, when the job completes, etc. Most users find specifying a log file to be very handy; its use is recommended. If no log entry is specified, Stork does not create a log for this job.

stork_ submit will prepend the current working directory if the pathname is relative (does not start with a / character). This implies that the submit directory must be shared between stork_ submit and the Stork server host, when using relative paths. All local file paths passed to Stork must be valid on the Stork server host. log file paths should not use NFS file systems.

log_xml = "True"; | "False";

If log_xml is true, then the log file will be written in ClassAd XML. If it isn't specified, XML is not used. Note that it's an XML fragment, and is missing the file header and footer. Also note that you should never mix XML and non-XML in a single file: if multiple jobs write to a single log file, it is up to you to make sure that all of them specify (or don't specify) this option in the same way.

src_url = <protocol-name:URL>

A (required) URL to identify the data source, as well as the protocol to be used at the source. file:/// URLs must refer to valid paths on the Stork server host.

dest_url = <protocol-name:URL>

A (required) URL to identify the data destination, as well as the protocol to be used at the destination. file:/// URLs must refer to valid paths on the Stork server host.

x509proxy = <path-to-proxy>

The path to and file name of an X.509 proxy when needed for GSI authentication. A value of "default" directs Stork to search in the standard Globus GSI proxy locations.

cred_name = <credential-handle>

Alternatively, a X.509 proxy may be managed via the Stork credential manager. The cred_name specifies the name by which the credential was stored in the credential manager. See the stork_store_cred manual on page .

alt_protocols = <sourceprotocol-desinationprotocol, sourceprotocol-desinationprotocol, ...>

A comma separated list of alternative protocol pairings to be used when a data transfer fails. For each pair, the protocol to use at the source of the transfer is followed by a - (dash) and the protocol to be used at the destination of the transfer. The list is used (together with the original src_url and dest_url protocols) in a round robin fashion. The source and destination URLs are unchanged; only the protocols to be used are changed.

Options

-help

Display usage information

-version

Display version information

-debug

Show extra debugging information.

-stdin

Read commands from stdin instead of from a file.

-name server_specification

Specification of stork_ server using machinename:port or <a.b.c.d:port>.

-lognotes "prose"

The string given within quote marks is appended to the data placement ClassAd before the job is submitted.

Exit Status

stork_ submit will exit with a status value of 0 (zero) upon success, and it will exit with the value 1 (one) upon failure.

Author

Condor Team, University of Wisconsin-Madison

Copyright

Copyright © 1990-2006 Condor Team, Computer Sciences Department, University of Wisconsin-Madison, Madison, WI. All Rights Reserved. No use of the Condor Software Program is authorized without the express consent of the Condor Team. For more information contact: Condor Team, Attention: Professor Miron Livny, 7367 Computer Sciences, 1210 W. Dayton St., Madison, WI 53706-1685, (608) 262-0856 or miron@cs.wisc.edu.

U.S. Government Rights Restrictions: Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of The Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 or subparagraphs (c)(1) and (2) of Commercial Computer Software-Restricted Rights at 48 CFR 52.227-19, as applicable, Condor Team, Attention: Professor Miron Livny, 7367 Computer Sciences, 1210 W. Dayton St., Madison, WI 53706-1685, (608) 262-0856 or miron@cs.wisc.edu.

See the Condor Version 6.8.3 Manual for additional notices.