Batch common problems
Occasionally, we 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 when submitting the job definition file
The following message is returned:
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 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.
Connection contention in Batch Grid Endpoint
Currently, the grid container is using unshared connections during transactions. Because connections are not released until the end of a transaction, this can cause contention for connections, leading to a drop in performance and in some cases, deadlock.
To use shared connections on the Batch Grid Endpoint, create the GRID_ENDPOINT_USE_SHARED_CONNECTIONS variable at the cell scope, and set the value to true. The default is to not use shared connections.
Related:
Batch frequently asked questions Troubleshoot batch applications Diagnose batch problems using job logs Add log and trace settings to the batch environment