Batch job classification

The classification rules are composed of Boolean expressions composed of the operands listed in this topic.

Classification rules are saved in a configuration file named gridclassrules.xml under the profile config directory. The rules are ordered based on the priority element.

The batch runtime implementation iterates through these rules until it finds a matching rule. When a match is found, the transaction class corresponding to that rule is applied to that job.

The following operands comprise the Boolean expressions in job classification rules:

submitterid

The submitter of a given job is obtained from com.ibm.ws.longrun.Job.getUser() API. It must match the value of this operand for the rule to match.

submittergroup

The submitter group for a job is a list of strings obtained by iterating through the set of credentials for that job submitter. If the value of this operand exists in the list, then the rule is matched and the corresponding transaction class is assigned to the job.

jobname

The name attribute of the job element in xJCL specifies the job name. It must match the value of this operand for the rule to match.

jobclass

The optional class attribute of the job element in xJCL specifies the job class. It must match the value of this operand for the rule to match.

appname

The optional default-application-name attribute of the job element in xJCL specifies this name. If this attribute is not specified, then appname defaults to job name. The application name of a given job must match the value of this operand for the rule to match.

apptype

Valid values for this operand are GridUtility and J2EE. If the application type of the job matches the value of this operand, then this rule is matched. The corresponding tx class of the rule is assigned to the job.

platform

Valid values for this operand are zos, distributed, and mixed. If the platform composition of the eligible endpoints for a given job matches the value of this operand, then the rule matches.

time

Use the time operand to define the date and time of day that a given request must be honored. Two optional fields are StartTime and EndTime. If a request is received outside of the defined window, the request is not processed. The format for both fields is dayOfWeek/day/month/year::hour:min:sec,, for example, Sat/01/Jan/2011::08:00:00.

dayOfWeek

Specifies one of the days of the week: Sun for Sunday, Mon for Monday, Tue for Tuesday, Wed for Wednesday, Thu for Thursday, Fri for Friday, and Sat for Saturday.

day

Day of the month.

month

Specifies one of the 12 months: Jan for January, Feb for February, Mar for March, Apr for April, May for May, Jun for June, Jul for July, Aug for August, Sep for September, Oct for October, Nov for November, Dec for December.

year

Four-digit year.

hour

Two-digit hour of the 24 hour clock.

min

Two-digit value for minutes.

sec

Two-digit value for seconds.

Sample classification rules

<matchRules xmi:id="MatchRule_1159377240783" matchAction=SimpleCI_TC" matchExpression="apptype='j2ee'"
priority="1"/>

<matchRules xmi:id="MatchRule_1159377240783" matchAction="CompletionTime_TC"
matchExpression="appname='MandlebrotCI" priority="2"/>

<matchRules xmi:id="MatchRule_1159377240783" matchAction="${default_iiop_transaction_class}"
matchExpression="submitterid='admin'" priority="3"/>

Default classification rules and precedence

The default classification rule assigns any job to the default transaction class, DEFAULT_TC.

The default rule can be edited and deleted. User-defined classification can be added. The job scheduler evaluates the list of classification rules in order and assigns the transaction class specified by the first matching rule. Only one classification rule set per cell is supported. A default configurable transaction class, named DEFAULT_TC by default, is associated with this set. If none of the classifications rules match a job, then the default transaction class is applied to that job. GUI support for choosing a transaction class from a list while building a rule is available only when Intelligent Management is installed. When only batch exists in the environment, there is a text field where a transaction class name is specified.

Avoid trouble: Assign transaction classes to batch work on the Job scheduler Classification rules console page, not on the Resources > Asynchronous beans > Work managers > BatchWorkManager page.gotcha

Related concepts

Job classes

Job logs

Job scheduler classification rule settings