Note: This version of the VDT (1.3.7) is no longer supported. Feel free to look through the documentation and install it, but we cannot guarantee support for it. The current stable release is 2.0.0.

Submitting Jobs to Web Service GRAM

Submitting jobs to Globus Toolkit 4's Web Service GRAM (or WS-GRAM) is similar to submitting jobs to the pre-web services. However, there are enough differences that it is worthwhile pointing out how to do it.

First of all, you will always need to have a GridFTP server running on the server side (the location to which you are submitting jobs). You will almost always need a GridFTP server running on the client. You don't if you are transferring no files or if you are just using globusrun-ws to get back stdout. In all other cases you will need a GridFTP server running on the client. The following examples assuming that you have GridFTP set up appropriately.

Note: VDT 1.3.7 runs Globus web services on a non-standard port. Examples 1 and 2 will not work exactly as described: see example 3 for the small change you need to make.

Example 1: A trivial fork job

You can submit a job to WS-GRAM on the same computer that you are using with this command:

> globusrun-ws -submit -c /bin/date
Submitting job...Done.
Job ID: uuid:cb680b32-350a-11da-956e-0002b3ea4fa0
Termination time: 10/05/2005 19:12 GMT
Current job state: Active
Current job state: CleanUp
Current job state: Done
Destroying job...Done.

Notice that you didn't see the output from the job (and therefore didn't need a GridFTP server running anywhere). Never fear, just add another option, -s (stream), to see the output (and make sure you're running GridFTP on the server--localhost in this case.):

> globusrun-ws -submit -s -c /bin/date
Delegating user credentials...Done.
Submitting job...Done.
Job ID: uuid:7002e8ee-350e-11da-9bfd-0002b3ea4fa0
Termination time: 10/05/2005 19:38 GMT
Current job state: Active
Current job state: CleanUp-Hold
Tue Oct  4 14:38:29 CDT 2005
Current job state: CleanUp
Current job state: Done
Destroying job...Done.
Cleaning up any delegated credentials...Done.

If you prefer to have the output go to a file, specify it with -so:

> globusrun-ws -submit -s -so job.out -c /bin/date
Delegating user credentials...Done.
Submitting job...Done.
Job ID: uuid:98bd69c0-350f-11da-ac76-00304853176e
Termination time: 10/05/2005 19:46 GMT
Current job state: Active
Current job state: CleanUp-Hold
Current job state: CleanUp
cat Current job state: Done
Destroying job...Done.
Cleaning up any delegated credentials...Done.

> cat job.out
Tue Oct  4 14:45:55 CDT 2005

Example 2: A trivial fork job on another computer

You can submit a job to WS-GRAM on another computer named foo.example.com:

globusrun-ws -submit -F foo.example.com -c /bin/date

Note that the order of the parameters is important: the -c argument must be last. If you put other parameters after the -c argument, they will be ignored by globusrun-ws and given to the job you are trying to run.

Example 3: A trivial fork job on another computer with non-standard port

You can submit a job to WS-GRAM on another computer named foo.example.com that is running WS-GRAM on an alternate port:

globusrun-ws -submit -F foo.example.com:9443 -c /bin/date

In the following examples, we'll assume that you are submitting to the localhost, just to highlight the essentials.

Example 4: A fork job that wants delegation

By default, your job will not have access to a proxy credential unless you specifically request that your proxy is delegated. To do so, add the -job-delegate or -J option.

> globusrun-ws -submit -job-delegate -c /bin/date
Delegating user credentials...Done.
Submitting job...Done.
Job ID: uuid:9eb14364-350b-11da-a4ff-0002b3ea4fa0
Termination time: 10/05/2005 19:18 GMT
Current job state: Active
Current job state: CleanUp
Current job state: Done
Destroying job...Done.
Cleaning up any delegated credentials...Done.

Example 5: Submitting your job with an XML description

Some options for submitting your job (like staging files, see below) are only accessible if you specify your job in an XML document. Although XML is most convenient for computers to create and parse, you will have the joy of writing XML files. To submit a basic fok job that delegates its credentials--just like Example 4, you could have written the following XML file:

<job>
  <executable>/bin/date</executable>
</job>

Then submit the job with -job-description-file:

> globusrun-ws -submit -s -job-description-file job.xml
Delegating user credentials...Done.
Submitting job...Done.
Job ID: uuid:a683e92c-350e-11da-95dc-0002b3ea4fa0
Termination time: 10/05/2005 19:40 GMT
Current job state: Active
Current job state: CleanUp-Hold
Tue Oct  4 14:40:00 CDT 2005
Current job state: CleanUp
Current job state: Done
Destroying job...Done.
Cleaning up any delegated credentials...Done.

Note that this did credential delegation even though it wasn't requested. Streaming (with the -s option) requires delegation.

Example 6: Submitting your job to a batch system

Most jobs will be submitted to a batch system like Condor or PBS. To specify that it should be done, you need to specify the factory type. For example, for Condor:

> globusrun-ws -submit -Ft Condor -s -c /bin/date
Delegating user credentials...Done.
Submitting job...Done.
Job ID: uuid:498cc2e6-351a-11da-959f-00304853176e
Termination time: 10/05/2005 21:03 GMT
Current job state: Pending
Current job state: Active
Current job state: CleanUp-Hold
Tue Oct  4 16:02:42 CDT 2005
Current job state: CleanUp
Current job state: Done
Destroying job...Done.
Cleaning up any delegated credentials...Done.

Note that Condor is capitalized and "condor" will not work. The names you can use for factory types are:

Fork
Condor
PBS
LSF

Example 7: Submitting a job with Condor-G

Condor-G definitely requires a GridFTP server to be running on both the server and the client. To submit a job, you'll need a submit file. Details can be found in the Condor manual, but here is an example submit file:

Universe        = grid
Grid_Type       = gt4
Jobmanager_Type = Fork
GlobusScheduler = https://foo.example.com:9443
Executable      = myhostname
Output          = job.output
Error           = job.error
Log             = job.log
Queue

where myhostname is a simple script:

#!/bin/sh

hostname

Submit this job with condor_q. When the job is finished, you'll see a record of the job in job.log:

000 (006.000.000) 10/05 15:48:27 Job submitted from host: <198.51.254.203:37580>
...
017 (006.000.000) 10/05 15:48:41 Job submitted to Globus
    RM-Contact: https://vdt-rhas3-ia32.cs.wisc.edu:9443
    JM-Contact: https://198.51.254.212:9443/wsrf/services/ManagedExecutableJobService?65e59770-35e1-11da-8810-a04185b6c7ae
    Can-Restart-JM: 0
...
001 (006.000.000) 10/05 15:48:48 Job executing on host: vdt-rhas3-ia32.cs.wisc.edu
...
005 (006.000.000) 10/05 15:48:55 Job terminated.
        (1) Normal termination (return value 0)
                Usr 0 00:00:00, Sys 0 00:00:00  -  Run Remote Usage
                Usr 0 00:00:00, Sys 0 00:00:00  -  Run Local Usage
                Usr 0 00:00:00, Sys 0 00:00:00  -  Total Remote Usage
                Usr 0 00:00:00, Sys 0 00:00:00  -  Total Local Usage
        0  -  Run Bytes Sent By Job
        0  -  Run Bytes Received By Job
        0  -  Total Bytes Sent By Job
        0  -  Total Bytes Received By Job
...

and the output in job.output:

vdt-rhas3-ia32.cs.wisc.edu