Network Deployment (Distributed operating systems), v8.0 > Reference > Troubleshoot tips
Batch common problems
Occasionally, you might encounter behavior in the batch component that is not expected.
Troubleshoot
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 admin 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 operating systems, they work slightly differently. On distributed operating systems, 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 operating systems, they work slightly differently. On distributed operating systems, 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.
Batch frequently asked questions
Troubleshoot batch applications
Related
Diagnosing problems using job logs
Add log and trace settings to the batch environment