WebSphere Extended Deployment, Version 6.0.x
             Operating Systems: AIX, HP-UX, Linux, Solaris, Windows, z/OS


Creating the long-running scheduler database

The long-running scheduler stores job information in a relational database. The first step in setting up the long-running scheduler is to create this database if the default Derby database is not used.

Before you begin

During the WebSphere Extended Deployment business grid installation, one Derby JDBC provider is created. The Derby JDBC provider contains two datasources. One is the default Derby datasource, JNDI name jdbc/lrsched, that points to the default Derby long-running scheduler database. The other, JNDI name jdbc/lree, is the grid execution environment datasource. You do not need to create the long-running scheduler database if you decide to use the default datasource. Thelong-running scheduler datasource JNDI name is specified in the WebSphere administrative console under the long-running scheduler panel. If you decide to use a different database for the long-running scheduler, you must manually create the database and assign a database datasource JNDI name in the long-running scheduler panel. The default Derby database for thelong-running scheduler is created when the long-running scheduler host (deployment target) is selected through the administrative console. The default Derby database for the endpoint is created when a grid application is first installed on a node. Note that embedded Derby databases cannot be shared by multiple processes and are unsuitable for environments where thelong-running scheduler needs to move from one node to another. For example, high availability scenarios. long-running scheduler.

About this task

WebSphere Extended Deployment provides DDL files to define the long-running scheduler database in <WAS_install_root>/longRunning directory. The DDL files for creating the long-running scheduler database are named CreateLRSCHEDTablesXxx.ddl and CreateLRSCHEDTablespaceXxx.ddl where Xxx indicates the type of database manager that the scripts are intended for. WebSphere Extended Deployment supports Cloudscape®, DB2, Oracle, and Informix. Not all database managers have corresponding tablespace DDL files.

The following steps can be used to configure the long-running scheduler database using the WebSphere embedded Cloudscape database. Note that embedded Cloudscape databases cannot be shared by multiple processes and are unsuitable for environments where the long-running scheduler needs to move from one node to another (for example, high availability scenarios).

[For z/OS operating system] SPUFI scripts are provided in WAS_install_root/longRunning.

For DB2 Version 7, the long-running scheduler SPUFI is SPFLRSV7. The long-running execution environment SPUFI is SPFLREV7.

[For z/OS operating system] For DB2 Version 8, the long-running scheduler SPUFI is SPFLRS, the long-running execution environment SPUFI is SPFLREE, and the Postings Sample SPUFI is SPFPOST.

[For z/OS operating system] For both DB2 Versions 7 and 8, the Postings Sample SPUFI is SPFPOST. There are two versions of long-running scheduler and long-running execution environment SPUFIs for DB2 on z/OS because of restrictions on the size of the character data columns which comprise the primary key in DB2 Version 7 for z/OS.

[For z/OS operating system] The following steps show you how to define the schema name of your choice, as a post-application installation step. As an example, use D1LREESM:
  • Update the shipped SPFLREE file (the DDL for DB2 on z/OS) by replacing the default schema name LREESCHM with D1LREESM.
  • Create the new database schema on your DB2 for z/OS database based on the modified SPFLREE using SPUFI.
  • Install the long-running execution environment application as usual. These instructions are the same for the PostingSample application.

To migrate the long-running scheduler from WebSphere Extended Deployment 6.0 to 6.0.1, do the following:

Procedure

  1. Refer to your database vendor's documentation for details on customizing DDL scripts and using the database tools to execute it.
  2. If you migrate from WebSphere Extended Deployment 6.0 to 6.0.1, use the MigrateLRSCHEDTablesXXXXX.ddl file to migrate the existing LRSCHED database and reinstall the long-running scheduler application,LongRunningScheduler.ear as well as the long-running execution environment, LREE.ear.
  3. Select and create a directory to store the database files. The remainder of these instructions refer to this directory as <db_dir>.
  4. Change the current directory to <db_dir> and issue the following command:<WAS_install_root>/java/jre/bin/java -Djava.ext.dirs=<WAS_install_root>/cloudscape/lib -Dij.protocol=jdbc:db2j: com.ibm.db2j.tools.ij <was_install_root>/longRunning/CreateLRSCHEDTablesCloudscape.ddl

What to do next

After creating the database, define its JDBC provider and datasource in the administrative console. To guarantee that the database is available for each application server that hosts the long-running scheduler, the definition of the data source at the cell level is recommended. Consult the JDBC provider documentation for more information on defining a new JDBC provider. The next step is Configuring the long-running scheduler .




Related tasks
Configuring the long-running scheduler
Creating the execution environment database
Related reference
Administrative roles and privileges
setupLongRunning.py
Task topic    

Terms of Use | Feedback

Last updated: Oct 16, 2009 11:08:29 AM EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=/com.ibm.websphere.xd.doc/info/scheduler/tbgsched.html