Batch jobs and their environment

The product provides ways of managing the scheduling and execution control of background activities in a grid computing environment.

The various ways that you can manage your batch environment include using the job management console, analyzing job logs, specifying job classes, and by using classification rules.

Through the job management console, you can:
  • Submit jobs
  • Monitor job execution
  • Perform operational actions against jobs
  • View job logs
  • Manage the job repository
  • Manage job schedules

Job logs

A job log is a file that contains a detailed record of the execution details of a job. It is composed of both system and application messages. Job logs are stored on the endpoints where the job runs and on the application server that hosts the job scheduler.

Job logs are viewable through the job management console and from the command line.

Job classes

A job class establishes a policy for a set of batch jobs to use resources. You can control the execution time, number of concurrent jobs, job log, and job output queue storage through this policy. Each job is assigned to a job class. A default job class is provided for jobs that do not specify a class.

Job classification

Classification rules are saved in the gridclassrules.xml configuration file under the configuration directory of WebSphere® Application Server. In batch, one gridclassrules.xml file exists per cell. Rules are ordered based on the priority element.

Audit string

You can successfully save jobs to the repository using an audit string. The audit string is stored in a database, but is not displayed in the job management console. You can retrieve the audit string through standard database reporting facilities. In order to provide history, the audit string is saved each time you save a job to the repository.

The database contains 1 to N versions of the audit string. N is the oldest save of the audit string and 1 is the current save of the audit string.