Occasionally, you might encounter behavior in the batch
component that is not expected.
Troubleshooting
Use this section to look
for solutions to problems when batch is not working, or not working
the way that you expect it to.
Job submission fails due to database failures with
the default Apache 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. Use
a shared RDBMS for cells configured with more than one scheduler.
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 that 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.
Job dispatching slowly when large number of jobs (hundreds
or thousands) 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 LRSCHED 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 LRSCHED database.
- Do not use default the Derby data source JNDI name (jdbc/lree)
with DB2. Create a data source
for non-default Derby databases.
- Check that the WebSphere® variable
of GRID_ENDPOINT_DATASOURCE is set to the newly created non-default
data source.
Jobs are creating files with the server identity
Set
the WebSphere variable
RUN_JOBS_UNDER_USER_CREDENTIAL to run jobs under the credential of
the submitter. Although jobs can run under the credential of the user
on distributed and z/OS®, they
work slightly differently. On distributed, files are created with
the identity of the server even if the thread has the credential of
the user. On z/OS, the Java™ thread synchronizes with the
operating system thread and files are created with the identity of
the user.
Batch applications not working with Java 2 Security
Set the WebSphere variable RUN_JOBS_UNDER_USER_CREDENTIAL
to run jobs under the credential of the submitter. Although jobs can
run under the credential of the user on distributed and z/OS, they work slightly differently. On distributed,
files are created with the identity of the server even if the thread
has the credential of the user. On z/OS,
the Java thread synchronizes
with the operating system thread and files are created with the identity
of the user.
- Ensure that application security is turned on.
- Grant permissions, SecOwnCredentials, and ContextManager.getServerCredential,
in the policy file of the application.
Job log viewing from the Job Management
Console fails with the following error: Unable to read the job log.
If administrative security is enabled, ensure that application
security is also enabled.
![[oct2010]](../../deltaend.gif)
oct2010