WebSphere Extended Deployment Compute Grid, Version 6.1
             Operating Systems: AIX, HP-UX, Linux, Solaris, Windows, z/OS


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, datasource 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 on how to create a non-default job scheduler database.

About this task

Standalone application servers, dynamic or static clusters can host the job scheduler. The Operations Optimizer component 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 datasource JNDI name (jdbc/lrsched) is selected.

[Version 6.1.0.1 and later] If you are using the Compute Grid component with the Operations Optimization component, 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 as long as both online and batch workloads are on dynamic clusters. This overload protection is not supported for static clusters member. Since batch jobs can consume a lot of CPU and run for a long period of time, utilization limit might be exceeded.

[Version 6.1.0.1 and later] When the Operations Optimization component is installed with the Compute Grid component, 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 job scheduler's endpoint selection process.

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 utilize 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 in to the administrative console.
  3. Expand System Administration > Job Scheduler. The job scheduler panel opens.
  4. In the Scheduler hosted by drop-down list, select the deployment target.
  5. Type the database schema name. The default is LRSSCHEMA.
  6. Select the datasource 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 will write the job logs. The default is ${GRID_JOBLOG_ROOT}/joblogs
  8. Optionally, check a usage data check box.
    1. Specifies if the scheduler will record 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 lrsubmitter and/or lradmin roles through the WebSphere Extended Deployment administrative console are allowed access to the job management console.



Related concepts
xJCL elements
[Version 6.1.0.1 and later] Middleware agent
[Version 6.1.0.1 and later] xJCL sample for a job with specified application edition
Related tasks
Developing Compute Grid applications
[Version 6.1.0.1 and later] Rolling out an edition
Related information
[Version 6.1.0.1 and later] Job scheduler configuration AdminTasks
[Version 6.1.0.1 and later] Planning your Compute Grid environment
[Version 6.1.0.1 and later] Configuring grid endpoints
[Version 6.1.0.1 and later] Job scheduler custom properties
Task topic    

Terms of Use | Feedback

Last updated: Oct 30, 2009 6:22:31 PM EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1/index.jsp?topic=/com.ibm.websphere.gridmgr.doc/info/scheduler/tcgconf.html