Common problems

Occasionally, you might encounter behavior in the WebSphere Extended Deployment Compute Grid component that is not expected.

Troubleshooting

Use this section to look for solutions to problems when WebSphere Extended Deployment Compute Grid is not working, or not working the way that you expect it to.

Job submission fails due to database failures with the default Derby database

  • Check for the successful creation of the LRSCHED database in the <user_install_root>/gridDatabase directory.
  • Check the file permissions of the database.
  • Derby is only supported on a single scheduler configuration. Cells configured with more than one scheduler should use a shared RDBMS. For example, DB2.

Job submission fails with the following message: Unable to submit the job definition <xJCL file> because the application that it runs has not been deployed to an endpoint

  • Ensure the application is installed on an endpoint server.
  • Ensure the job name or the application name specified in the XJCL matches the name of the application.
  • Check for ODC exceptions in the logs on the job scheduler and endpoint servers.

Job dispatching slowly when large number of jobs (100s or 1000s) are submitted

Increase the number of dispatcher threads by setting the MaxConcurrentDispatchers custom property in the job scheduler custom properties panel in the administrative console.

Job execution fails due to database failures with the default Derby database

  • Check for the successful creation of the LREE database in the <user_install_root>/gridDatabase directory
  • Check the file permissions of the database.

Database errors during the execution of batch jobs with DB2

  • Check for the successful creation of the LREE database.
  • Default derby datasource JNDI name (jdbc/lree) should not be used with DB2. Create a new datasource for non-default Derby databases.

Native execution job submission fails on z/OS

Native execution jobs are not supported on z/OS.

Jobs are creating files with the server identity

Set the WebSphere variable RUN_JOBS_UNDER_USER_CREDENTIAL to execute jobs under the submitter's credential. Although jobs can run under the user's credential on distributed and z/OS, they work slightly differently. On distributed, files are created with the server's identity even if the thread has the user's credential. On z/OS, the Java thread synchronizes with the operating system thread and files are created with the user's identity.

Batch applications not working with Java 2 Security

Set the WebSphere variable RUN_JOBS_UNDER_USER_CREDENTIAL to execute jobs under the submitter's credential. Although jobs can run under the user's credential on distributed and z/OS, they work slightly differently. On distributed, files are created with the server's identity even if the thread has the user's credential. On z/OS, the Java thread synchronizes with the operating system thread and files are created with the user's identity.
  • Ensure application security is turned on.
  • Grant permissions, SecOwnCredentials and ContextManager.getServerCredential, in the application's policy file.