|
|
ldasJob { -name {} -password {} -email {} } { userCmd -opt1 {} ... }
Which is in the format of a Tcl command, ldasJob, with two required arguments:
Calling convention (all on a single line):
ldasJob { -name "username" -password "********" -email "user@foobar.edu" } { dataStandAlone -inputprotocol {Tcl list} -returnprotocol URL -outputformat {Tcl list} -framequery {Tcl list} -aliases {Tcl list} -algorithms {Tcl list} -subject "freeform string" -responsefiles {Tcl list} -tarball {http or ftp URL} }
Option Descriptions:
-inputprotocol:
http ftp file port
NOTE: Embedded spaces in the argument to the -inputprotocol
option will cause the request to fail.
-returnprotocol:
http ftp gridftp mailto file port
Default Value: ${jobid}_wrapperdata.ilwd (local filename)
The argument to -returnprotocol resembles the usual
browser conventions for URL's, and is used to control the
naming and disposition of output data from a user request,
however the range of supported protocols is severlely limited
for the dataStandAlone user command.
This is a special protocol used by the dataStandAlone user
command for interaction with a GLOBUS/GRID system.
This returnprotocol is only interpreted by the datacond API
for use on output data formatted for ingestion by a stand alone
wrapper API.
The file will be written to the local gridftp home directory
or a subdirectory of it which is writable by the user which
LDAS runs as.
Several modified forms of the gridftp URL are available:
as a useful shorthand notation for producing a directory
hierarchy of dataStandAlone results which maps directly to
the job directories normally produced by LDAS, allowing
simple correlation of output data with other job resuts or
messages from the LDAS system.
Then the directory hierarchy will be created as required
and unique job-specific default filenames will be assigned
to the datacond API's output for the wrapper, i.e.:
NOTES:
-subject: "freeform string"
The value of the -subject option is used as the subject field
in the email returned to the user after successful completion
of an LDAS job
The argument to the -inputprotocol option conforms
to the usual browser conventions for URI's for determining
the location of the results of the user request.
When the URI is of type http or ftp
the LDAS system will attempt to retrieve the data referred
to by the URI description, and will make a local copy of
it in the result directory assigned to the user command.
On completion or failure of the user command, the local copy
of the input data will be removed.
When the URI is of type port, the system will attempt
to read ilwd binary data from the referenced port.
When the URI is of type file, the data is locally
available, and will be read from the local file system if it
exists and is readable.
The possible formats of the argument are:
Optional
Currently any attempt to use the -returnprotocol option
to cause data to be sent by LDAS via anonoymous ftp will be
ignored, and only a local directory and filename will be returned.
The same result will be seen for http type URL's.
For the time being the onus of determining the http URL which
can be used to retrieve the results of a dataStandAlone command
that is NOT interacting with gridftp is with the user.
Support for remote anonymous ftp for remote push, and the
return of a fully qualified http URL for remote pull will be
available in the next release of LDAS.
The LDAS writable subdirectory should be defined in the
LDASapi.rsc resource file as the
::GRID_FTP_WRITABLE_SUBDIRECTORY, which will be joined
to the grid home directory when calculating output filenames.
-returnprotocol gridftp
-returnprotocol gridftp://here/there/mydir/mysubdir/
LDAS-TEST1234567_wrapperdata.ilwd
Optional: Defaults to
results when the
-returnprotocol spec is not gridftp, and
grid_output when the
-returnprotocol option is gridftp.
The user specified subject will be overridden and grid_output
will be used under all circumstances when gridftp is the
-returnprotocol to conform with the LDAS/GRID interface.
The result of this job is an ilwd file which can be used by a standalone wrapper with the tfcluster dso. The ilwd file will normally be found in the job directory, which can be determined by the returned email message.
Return to Top