A job description file, or jdf for short, is a plain text file that contains a job description. Each job description file describes a single job. You can edit a jdf in the text editor of your choice. By convention, we use the .jdf extension to name all job description files.

A jdf file has two types of clauses in it: the job and the task clauses. You use the first type to specify common attributes for the entire job and the other one to specify particular attributes and commands to the tasks that comprise your parallel application.

A job clause contains a (possibly empty) list of sub-clauses. For instance, the requirements sub-clause encompasses the list of requirements that need to be fulfilled by a worker node, so that it can be selected to run tasks of the job, while the label sub-clause associates a name to the job. This sub-clause is useful for tracking the execution of the job and also to associate the name of the output files to the job that has generated it.
Below we present an example of a jdf, which defines a very simple job named myjob1. It requires worker nodes that have the os attribute set to "linux" and the mem attribute set to a number greater or equal to 100.

As we mentioned before, all sub-clauses of a job clause are optional. If the label sub-clause does not exist in the jdf, an internal job id is used to identify it. If there is no requirements sub-clause, the Broker assumes that all worker nodes in your grid are able to run the tasks of your job.
Besides label and requirements sub-clauses, you may define default descriptions for all tasks of a job. This is further explained below.

There is one task clause to describe each task of a job. The number of tasks in a job is determined by the number of task clauses in the jdf.
The task clause is used to describe all the phases of a task. A task is divided in initial, remote and final phases which are described by means of init, remote and final sub-clauses, respectively.
The init sub-clause is used to define which files will be transferred from the machine the user is submitting the job to the worker node, before the execution of the task, whereas the final sub-clause defines which files will be transferred from the worker node to the user's machine, after the execution of the task. Finally, the remote sub-clause is used to specify which command line will be invoked in the worker node.

OurGrid provides a useful set of abstractions that allow you to write BoT applications without knowing details of the worker node file system. The basic idea is that you can have OurGrid transferring and retrieving files to/from the worker nodes in a per task basis. OurGrid defines two virtual directories for each task, called playpen and storage. In the task description you can instruct OurGrid to copy files to these directories. This assures that the worker nodes will have all necessary files stored locally, before the tasks are run. Analogously, you can instruct OurGrid to copy files from those directories back to the user's machine after the successful execution of the task. This allows you to gather the results.
OurGrid offers three operations to be used in the init and final sub-clauses, namely: get, put and store. The operations put and store are used only in the init sub-clause, whereas get is used only in the final sub-clause.

The put command is used in init sub-clause to indicate files to be transferred to the worker node. As an alternative to the put command, you may use the store command. Both put and store perform conceptually the same operation: transfer a file from the home machine to a worker node. However, store checks whether the file already exists in the worker node (due to a previous transfer, for example) before transferring it. Therefore, we recommend using store for files that may be used many times, such as binaries and input files shared by multiple tasks. The general form of the put and store commands is:

In all above commands, localfile is the name of the file on the user's machine. If relative names are used, the Broker will consider the job description file directory as the base directory, whereas remotefile is the name of the file on the worker node. All remote file names are associated to the $PLAYPEN directory, if this is a put or get operation. In the case of store, the default directory is $STORAGE.

Additionally, OurGrid includes the $STORAGE directory in the worker node’s $PATH, since it is common to store executable files in this directory. By using get, put and store, we can rewrite the previous example as follows:

Using Environment Variables

OurGrid automatically defines the environment variables $JOB, $TASK, $PROC, $PLAYPEN and $STORAGE and they respectively contain a unique job number, a unique task number, the worker node chosen to run the task, the directory created as the playpen, and the storage directory name. These variables are useful to define unique names for the input and output files of each task. For instance:

job :

Appending the task number to a file is useful for the common case where the tasks that comprise the job produce output with the same name. Appending the task number ensures the uniqueness of each output.

It is easy to use OurGrid environment variables. You just need to refer to them as $PROC, $TASK, $JOB, $STORAGE and $PLAYPEN in init, remote and final sub-clauses. OurGrid transparently maps them accordingly to the operating system on which the task is going to run on (Microsoft Windows-like or Unix-like). Thus, with a single job description file, it is possible to run your job in heterogeneous grids. OurGrid environment variables are summarized in Table 1.

Table 1: Environment Variables

Using Defaults

Here, the first task copies the file alpha at the user's machine into file input at the worker node, and proceeds as before. The second task remains unchanged.

Attribute Matching

Table 2: Requirements Operators