Configuring the job scheduler

The job scheduler accepts job submissions and determines where and when to run them. As part of managing jobs, the job scheduler persists job information in an external job database. Configurations for the job scheduler includes the selection of the deployment target, data source JNDI name, database schema name, and endpoint job log location to be configured for the scheduler.

Before you begin

See Creating the job scheduler database for information about how to create a non-default job scheduler database.

About this task

Stand-alone application servers, dynamic clusters, or static clusters can host the job scheduler. WebSphere® Virtual Enterprise is required to host the job scheduler in a dynamic cluster. The first time a server or cluster is selected to host the grid scheduler, an embedded Derby database is automatically created, and configured to serve as the scheduler database if the default data source JNDI name (jdbc/lrsched) is selected.

If you are using Compute Grid with Virtual Enterprise, the dynamic application placement function with the job scheduler is supported. The application placement controller, along with the scheduler and autonomic request flow manager, provides overload protection of servers if both online and batch workloads are on dynamic clusters. This overload protection is not supported for static clusters member. Since batch jobs can use much CPU and run for a long time, utilization limit might be exceeded.

When Virtual Enterprise is installed with Compute Grid, the application placement controller is consulted by the job scheduler during its endpoint selection process. The custom property, UseAPCEndpointSelection; value = false, can be configured on the job scheduler to disable the application placement controller/job scheduler integration. Use this custom property to disable the application placement controller during the endpoint selection process for the job scheduler.

If there are multiple active editions of the Compute Grid application running in the cell, you can specify the custom property, default.edition.AppName=Edition, where AppName is the application name and Edition is the application edition which is specified during installation. For example, default.edition.TestBatchApplication=1.0. The value Base is used if the application edition is not defined. The job scheduler directs the job to the endpoint which hosts the default edition of that application if the xJCL does not specify the edition, as shown in the following code:

<job-scheduling-criteria>
	<required-capability expression="application_property$edition=1.0" /> 
</job-scheduling-criteria>

The job scheduler can be configured using the administrative console or by scripting. To configure the job scheduler using scripting language, use the link to the job scheduler configuration administrative tasks provided in the related links section at the bottom of this page. To configure the job scheduler using the administrative console, see the following procedure.

Procedure

  1. Choose the environment to host the job scheduler. A stand-alone application server host is recommended for test environments and can use the default Derby database. A cluster host is recommended for production environments. Although Derby is used as the default job scheduler database, you might want to use your own database. See Creating the job scheduler database for more information.
  2. Log on to the administrative console.
  3. Expand System Administration > Job Scheduler. The job scheduler panel opens.
  4. In the Scheduler hosted by list, select the deployment target.
  5. Type the database schema name. The default is LRSSCHEMA.
  6. Select the data source JNDI name from the list. If the default jdc/lrsched is selected, the default embedded Derby job scheduler database is created.
  7. Type the directory where the job scheduler and the grid execution environment write the job logs. The default is ${GRID_JOBLOG_ROOT}/joblogs
  8. Optionally, check a usage data check box.
    1. Specifies if the scheduler records job usage data for charge-back purposes in the scheduler database.
    2. Specifies if job usage data for jobs are to be written in SMF. This is a z/OS® only option
  9. Click OK and save the configuration.
  10. If administrative security is enabled, the recommendation is to enable application security also and secure the job scheduler. See Securing the job scheduler for more information. Only authorized users who are granted the lrmonitor, lrsubmitter, and lradmin roles, or a combination of the roles, through the WebSphere Extended Deployment administrative console are allowed access to the job management console.