Jobs are expressed using an Extensible Markup Language XML dialect called XML xJCL Job Control Language. This dialect has constructs for expressing all of the information needed for both compute-intensive and batch jobs, although some elements of xJCL are only applicable to compute-intensive or batch jobs. See the xJCL provided with the Sample applications, the xJCL table, and xJCL XSD schema document for more information about xJCL. The xJCL definition of a job is not part of the batch application, but is constructed separately and submitted to the job scheduler for to run. The job scheduler uses information in the xJCL to determine where and when to run the job.
The following table summarizes the xJCL elements:
Element | Jav Platform, Enterprise Edition (Java EE) Compute- intensive | Java EE Batch | Sub-element | Attributes | Description |
---|---|---|---|---|---|
job | Y | Y | Scopes the description of a batch job. | ||
Y | Y | name | Name of the job. This name must match the name of the batch application | ||
Y | Y | accounting | Optional accounting information attribute. | ||
Y | Y | class | Optional job class attribute, which identifies the job class under which the job runs. | ||
Y | Y | default-application-name | The application name to be used when no job step application-name attribute is found. | ||
Y | Y | jndi-name | JNDI name that is given to the job controller stateless session bean when the batch application is deployed into WebSphere® Application Server. | ||
Y | Y | job-scheduling criteria | required-capability | The required-capability of the job, which must be defined on an endpoint for the job to be dispatched to that endpoint. | |
Y | Y | step-scheduling criteria |
See step-scheduling-criteria element | ||
N | Y | checkpoint algorithm | See checkpoint-algorithm element | ||
N | Y | results-algorithm | See results-algorithms element | ||
Y | Y | substitution-props++ |
See prop element | The required-capability of the job, which must be defined on an endpoint for the job to be dispatched to that endpoint | |
job-step | Y* | Y | name | Optional name of the step. This information is returned on operational commands. | |
Y* | Y | application-name | Optional name of the application run by the step. The attribute name is used if application-name is omitted and the job level attribute default-application-name is omitted. | ||
N | Y | step-scheduling | See step-scheduling element | Allows for conditional logic based on return codes of steps that determines whether the batch step is invoked. | |
Y | Y | classname | Fully-qualified name of class that implements the compute intensive job. | ||
Y | N | checkpoint-algorithm-ref | Specifies the checkpoint algorithm to use for the batch job step. | ||
N | Y | results-ref | See results-ref element | Specifies the results algorithm to use for the conditional batch job step execution. | |
N | Y | batch-data-streams | See batch-data-streams element | A sequence of bds elements. Each bds is the configuration information necessary to create a batch data stream. | |
Y | Y | props | See props element | Name-value properties to pass to the step. | |
N | N | exec | See exec element | Identifies the executable associated with the job step. | |
N | N | env-entries | See env-entries element | Identifies the environmental properties associated with the job step. | |
prop | Y | Y | Single instance of a name value pair, that serves as a property. | ||
name | Name of the property. | ||||
value | Value of the property. | ||||
props | Y | Y | prop | See prop element | |
env-entries | N | N | Series of prop elements that are used to pass name-value pair properties to steps, bds, checkpoint algorithms and results algorithms. | ||
env-var | See env-var element | ||||
exec | N | N | Series of prop elements that are used to pass name-value pair properties to steps, bds, checkpoint algorithms and results algorithms. | ||
executable | The name of the executable associated with the job step. | ||||
arg | See line element | ||||
line | N | N | Command-line arguments passed to the job step executable. | ||
bds | N | Y | Single instance of a batch data stream implementation made available to the batch job. | ||
logical-name | A string that is embedded in batch step, which uses it to query the batch runtime environment for a specific batch data stream instance. | ||||
impl-class | Fully- qualified class name of the batch data stream implementation class. | ||||
props | See props elements | List of properties that are passed to the batch data stream implementation class. | |||
batch-data-streams | N | Y | Series of bds elements | ||
bds | See bds element | ||||
step-scheduling | N | Y | Applies to job-steps to create return code-based conditional flows for a batch job. Compares values of return codes defined for this batch job to decide whether a step is invoked or not while processing a batch job. The values of return codes are compared using the returncode-expression element. | ||
returncode- expression | see returncode-expression | Returncode- expression to evaluate. | |||
condition | If there is more than one returncode-expression element in the step-scheduling element, conditional operators are applied to them. Conditional operators supported are: AND, OR. | ||||
returncode-expression | N | Y | Used under step-scheduling tags to decide whether a batch job step runs based on return codes of other job steps. | ||
step | Name of step whose return code is to be compared in this expression. | ||||
operator | Operator to use for the return code expression. The supported operators are eq for equals, lt for less than, gt for greater than, le for less than or equal to, and ge for greater than or equal to. | ||||
value | The value with which to compare the return code. | ||||
step-scheduling-criteria | N | Y | Describes the sequence in which the job steps are processed. Currently sequential scheduling is supported; for example, steps get invoked in the order in which they exist in xJCL. | ||
scheduling-mode | Sequence in which to invoke steps, only possible value is sequential right now. | ||||
checkpoint-algorithm | N | Y | Declares a checkpoint algorithm that can be used for a batch job step. | ||
name | Name of algorithm. | ||||
classname | Class that implements this algorithm. | ||||
props | See props element | Sequence of prop elements for the checkpoint algorithm. | |||
checkpoint-algorithm-ref | N | Y | Reference to a checkpoint algorithm element. | ||
name | Name of checkpoint algorithm to which you are referring. | ||||
props | see props element | Sequence of prop elements for the checkpoint algorithm. |
++ The xJCL element substitution-props is discussed in the following section.
<checkpoint-algorithm-ref name="${checkpoint}" />
<substitution-props> <prop name="wsbatch.count" value="5" /> <prop name="checkpoint" value="timebased" /> <prop name="checkpointInterval" value="15" /> <prop name="postingsDataStream" value="${was.install.root}${file.separator}temp${file.separator}postings" /> </substitution-props>
Substitution for symbolic variables occurs at run time. At run time, the string ${variable-name} is replaced with the value of the property when the xJCL is submitted for execution. Using the properties in the previous example, the string ${checkpoint} is replaced with the string time-based before the job is submitted.
Symbolic variables can be indirect. For example: name=FILENAME value=${${filename}} used with the name/value pair filename=postingsDataStream yields the same result as specifying name=FILENAME value=${postingsDataStream}.
Symbolic variables can also be compound. For example, name=postingsDataStream value=${was.install.root}${file.separator}temp${file.separator}postings.
The name/value pairs do not have to be defined in the job document substitution-props element. The props name and value pairs defined in the substitution-props element are default values for the named variables. If not defined in the substitution-props element, name/value pairs must be either passed in via the job scheduler APIs when the job is submitted or defined in the system properties for the JVM. Every symbolic variable defined in the body of a job document must be resolved for the xJCL to be considered valid. Every name/value pair defined in the job document must resolve to a symbolic variable which is found in the body of the xJCL for the xJCL to be considered valid.
If name/value pairs are both defined in the xJCL document and passed to the job scheduler APIs at job submission time, the name/value pairs passed via the Job Scheduler APIs override the default values defined in the xJCL document. If name/value pairs are neither passed in via the job scheduler APIs nor defined as defaults in the xJCL document, name/value pairs for the symbolic variables must be defined in the system JVM properties for the xJCL to be considered valid.