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


Creating the execution environment database

The execution environment uses a separate database to track the progress of a long-running job. Storing this information in a database gives the execution environment a transactional datastore that it can use to recover from failures. A particular instance of the execution environment can have its own dedicated database, or share a database with other instances of the execution environment.

About this task

WebSphere Extended Deployment provides Data Definition Language (DDL) files in the <install_root>/longRunning directory that you can use to define the long-running execution environment database. The DDL files for creating the execution environment database are CreateLREETablesXxx.ddl and CreateLREETablespaceXxx.ddl where Xxx indicates the type of database manager. WebSphere Extended Deployment supports Cloudscape®, DB2, Oracle, and Informix. Not all database managers have corresponding table space DDL files. Refer to your database vendor documentation for details on customizing DDL scripts and using the database tools.

[For z/OS operating system] For DB2 on z/OS, SPUFI scripts are provided in the <install_root/longRunning> directory.

For DB2 Version 7, the long running scheduler SPUFI is SPFLRSV7. The long running runtime 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 thePostings Sample SPUFI is SPFPOST .

[For z/OS operating system] For both DB2 Version 7 and Version 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.

To use D1LREESM as the schema name for the long-running execution environment application, complete the following steps:
  1. In the SPFLREV7 file, replace the default schema name LREESCHM with D1LREESM.
  2. [For z/OS operating system] Create the new database schema on your DB2 for z/OS database based on the modified SPFLREV7 in step 1.
  3. Use the SPUFI to install the long-running execution environment application as before. Do the same action for the PostingSample application.

To configure the execution environment database in a WebSphere Cloudscape database, complete the following steps. Do not use Cloudscape databases in high availability scenarios. These instructions assume that you use the embedded Cloudscape database. Because the embedded Cloudscape database can only be accessed by a single Java Virtual Machine (JVM), each execution environment requires its own database. Repeat these steps on each machine that hosts the execution environment and use node-specific data sources in the next step.

[For z/OS operating system] To use DB2 as a grid endpoint database, the custom property currentSQLID of the datasource must be set to an appropriate value.

Procedure

  1. Select and create a directory to store the database files. The remainder of these instructions refer to this directory as <db_dir>.
  2. Change the current directory to <db_dir> and issue the following command: <install_root>/java/jre/bin/java -Djava.ext.dirs=<install_root>/cloudscape/lib -Dij.protocol=jdbc:db2j: com.ibm.db2j.tools.ij <install_root>/longRunning/CreateLREETablesCloudscape.ddl.

What to do next

Define the database to WebSphere Extended Deployment. To have multiple execution environments share a single database, define the database at the cell level. Define the data source for databases used by a single execution environment at the node level.
  1. In the administrative console, select Resources > JDBC Providers.
  2. To define the data source at the cell level, clear the node, server, and cluster fields. To define the data source at the node level, click Browse Nodes, select the appropriate node and click OK.
  3. Click Apply.
  4. Select the JDBC provider that corresponds to the database system with which you create the execution environment database. If the JDBC provider for your database vendor is not in the list, define a new JDBC provider. Consult the JDBC provider documentation for more information. If you create the job database using Cloudscape, select Cloudscape JDBC Provider (XA) from the list.
  5. Select Data sources, and click New.
  6. Use the following values:
    • Name: Type LREE, or another name of your choice. If you define per-node data sources, then each node must have a unique name.
    • JNDI name: Type jdbc/lree, or another JNDI name of your choice for the data source. If you define per-node data sources, then each node must have a unique JNDI name.
    • Additional parameters: This value is required by the JDBC provider you select. The Cloudscape data source does not require additional parameters.
  7. Click OK.
  8. If you use a Cloudscape database, click the name of the data source in the table and scroll to the end of the page. Type <db_dir>/LREE database in the Database name field, and click OK.
  9. Save your changes.



Related concepts
Sample Compute Grid applications
Related tasks
Installing the long-running application
Verifying the long-running scheduler installation
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/tbgexe.html