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


Setting up 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.

Before you begin

A default Cloudscape database for the scheduler is created when the job scheduler host (deployment target) is selected, and a default Cloudscape database for the endpoint (a grid execution system application) is created when a grid application is first installed on a node. (customers don't select the deployment target for the GEE system application). A default Derby database is an embedded database So, for a real production environment (usually more than one scheduler and one endpoint) we require a network database. for a real production environment (usually more than one scheduler and one endpoint) we require a network database. Privileges for the long-running scheduler differ, depending on the various roles. Roles include monitor, operator, configurator, and administrator. If you are a user with either a monitor or an operator role, you can only view the long-running scheduler information. If you have the role of configurator or administrator, you have all the configuration privileges for the long-running scheduler.

About this task

WebSphere Extended Deployment provides DDL files to define thelong-running scheduler database in <WAS_install_root>/longRunning. 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. Refer to your database vendor's documentation for details on customizing DDL scripts and using the database tools to execute it.

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] For DB2 on z/OS, 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. 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.
  2. Select and create a directory to store the database files. The remainder of these instructions refer to this directory as <db_dir>.
  3. 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 the database to WebSphere Extended Deployment. To guarantee that the database is available for each application server that hosts the long-running scheduler, define the data source at the cell level.
  1. In the administrative console, select Resources > JDBC Providers.
  2. Clear the node, server and cluster fields, then click Apply.
  3. Select the JDBC provider that corresponds to the database system you used to create the long-running scheduler database previously. Note that you might need to define a new JDBC provider if the JDBC provider for your database vendor does not appear in the list. Consult the JDBC provider documentation for more information on defining a new JDBC provider. If you created the long-running scheduler database using embedded Cloudscape, select Cloudscape JDBC Provider (XA) from the list.
  4. Select Data sources.
  5. Click New.
  6. Type the following values:
    • Name: LRSCHED, or another name of choice.
    • JNDI name: jdbc/lrsched, or another JNDI name of choice for the data source.
    • Additional parameters: As required by the JDBC provider you selected. The Cloudscape data source does not require any additional parameters.
  7. Click OK.
  8. If you are using a Cloudscape database, click the name of the data source in the table, scroll to the bottom of the page, type <db_dir>/LRSCHED in the Database name field, then clickOK
    Note: Depending on where <db_dir>/LRSCHED was created, you might need to provide additional path information.
  9. In the navigation tree, expand System administration and select long-running scheduler
  10. In the Data source JNDI name menu, select the JNDI name of the data source you just created.
  11. If your job database requires authentication credentials and you do not want to store those credentials as custom properties on the data source, use the J2EE Connector Architecture (J2C) authentication data entries to create an authentication alias. Then, select it in the Data source alias menu. If you use a Cloudscape database, no authentication credentials are required.
  12. Click OK.
  13. Save your changes.



Related concepts
Configuring the long-running scheduler
Related reference
Administrative roles and privileges
Task topic    

Terms of Use | Feedback

Last updated: Nov 30, 2007 4:00:35 PM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=/com.ibm.websphere.xd.doc/info/scheduler/tbgsched.html