Requirements-based job scheduling

Batch provides both implicit and explicit job scheduling requirements, which match against endpoints based on an application name.

Implicit requirement matching

An implicit scheduling requirement determines which applications a job runs. In Java EE applications, the application name of all Java EE applications installed in the scheduling domain is known through the product configuration, because all Java EE applications are installed into this environment through product administrative interfaces.

For batch utility applications, this information cannot be assumed. By default the information is unavailable, since batch utility applications are installed outside the control of product administrative interfaces. For these applications, the batch administrator can optionally enable application-name based endpoint selection for particular nodes by setting the grid.apps node custom property.

Through this property, the administrator establishes configuration knowledge of the grid utility applications available on that node. When the grid.apps node custom property is set for a node, that node is an eligible endpoint for job dispatch if and only if all the batch utility applications named in a given xJCL are present in the grid.apps list. If the grid.apps node custom property is not set on a node, then application names are not considered during the endpoint selection process for that node. When there is a combination of nodes that either specify or do not specify the grid.apps node custom property, an order of precedence governs endpoint selection. The following code shows the order of precedence.

if any node published grid.apps then  attempt to match job using app names  if there is a match then   if job has required-capabilities then    candidate-nodes= $(apply  required-capabilities to the set of nodes that have matching apps)
     else
  candidate-nodes= $(nodes that have matching apps)
     endif
else (no match based on grid.apps)
   if job has required-capabilities then   candidate-nodes= $(apply  required-capabilities to all nodes)
     else
  candidate-nodes= $(all nodes)
     endif
  endif
else (no nodes publish grid.apps)
   if job has required-capabilities then        candidate-nodes= $(apply  required-capabilities to all nodes)
   else
       candidate-nodes= $(all nodes)
   endif
endif

Java EE type applications always use application name matching during endpoint selection.

Explicit requirement matching

Explicit requirement matching enables a job to specify particular requirements that must be met by eligible endpoints. These requirements are specified in the batch job xJCL on the < required-capability> attribute. When required capabilities are specified, only endpoints that advertise matching capabilities are eligible to receive the job. The match expressions can specify any of the following node properties:

1. Node custom properties

2. Node metadata properties. For example, com.ibm.websphere.xdProductVersion

3. Node name and node host name

Requirements matching precedence

Implicit and explicit matching work together to determine eligible endpoints. For Java EE type jobs, the implicit requirement, application name, is treated as an additional required capability; it is logically appended with any explicitly specified requirements.

For batch utility jobs, an application name is a conditional requirement that applies only for batch utility nodes that advertise their installed applications through the grid.apps property. The batch utility jobs for which no application name match exists and that do not specify explicit requirements are eligible for dispatch to any batch utility node that does not advertise its applications.

Related concepts

Configure the batch environment

XML schema for a native execution job

WSGrid command-line utility

Related tasks

Configure the job scheduler

CommandRunner utility job step