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.