2.7.2 Troubleshooting problems related to standard jobs, action jobs, and custom jobs
This subsection describes how to troubleshoot problems that might occur when you execute standard jobs, action jobs, and custom jobs.
- Organization of this subsection
-
-
(1) Executing a standard job, action job, or custom job results in a startup failure
-
(2) Executing a standard job, action job, or custom job results in an abnormal end
-
(3) The status of a standard job, action job, or custom job does not change
-
(5) The shell does not read environment variables (AIX only)
-
(7) Automatic retry is not performed when the retry interval has elapsed
-
(8) A task is delayed because automatic retry is performed concurrently for jobs
-
(1) Executing a standard job, action job, or custom job results in a startup failure
Possible causes are as follows:
-
A directory mounted on NFS or a similar file system connected to a network is used in the following definition parameters:
-
Standard output file name for the job
-
Standard error output file name for the job
-
Work path for the job
-
Work directory for job environment settings
-
Home directory of the execution OS user
If a directory mounted on NFS or a similar file system connected to a network is used in any of the above definition parameters, a job might fail to start.
If a job fails to start, check whether you can access the file or directory specified in the above definition parameters by using the OS user who executes the job. If you cannot access the file or directory, change the permission for the file or directory so that you can use the OS user who executes the job to access the file or directory. Alternatively, move the file to a directory that you can access from the OS user who executes the job.
-
-
For queueless jobs (PC jobs, Unix jobs, and actions jobs for which Queueless Agent is specified in Exec. Service), host names specified in Exec-agent are case sensitive. Make sure that the host names specified on the hosts that execute queueless jobs are correctly specified in Exec-agent.
-
If the KAVU4571-W message (The user mapping (JP1-user-name) at the agent (agent-host-name) failed.) is output to the integrated trace log:
User mapping might not be specified correctly. For example, user mapping might not be specified on the host that executes a job, or the specified JP1 user or execution user might not be registered.
Check the user mapping settings, and re-execute (re-register) the job.
-
If the KAVU4580-W message (The user (user-name) does not have administrator permission at the agent (agent-host-name).) is output to the integrated trace log (for UNIX only):
An execution user without superuser privilege might have attempted to execute a job with job execution priority 4 or 5.
To execute a job with job execution priority 4 of 5 in UNIX, the execution user must have superuser privilege (root user).
In Windows, however, the execution user does not need to be a member of the Administrators group to execute a job with job execution priority 4 or 5.
-
If the KAVU4512-W message (The specified queue (queue-name) does not exist.) or the KAVU4511-W message (The specified agent (agent-host-name) does not exist.) is output to the integrated trace log:
The name of the specified execution host or queue for the QUEUE job or submit job might be invalid.
Check whether the execution environment has been created correctly for the QUEUE job or submit job.
To check, execute the jpqexport command and output the agent name (job execution host name) or queue name that is currently defined to a file. Agent names are not case sensitive. Queue names are case sensitive.
After checking the agent name and the queue name, re-execute (re-register) the QUEUE job or submit job.
-
If the KAVU4514-W message (The job cannot be registered because the entrance to queue (queue-name) is closed.) is output to the integrated trace log:
The queue might not be ready to accept the QUEUE job or submit job.
Execute the jpqqueshow command to check the status (ENTRYSTATUS) of the job entrance of the queue. To check the status of the job entrance of the default queue for an agent, specify the agent host name with the -ah option specified. To check the status of the job entrance of other queues, specify the queue name with the -q option specified.
If the job entrance is closed (when ENTRYSTATUS:CLOSE is specified), execute the jpqqueopen command to open the job entrance.
-
If the KAVU4515-W message (The job cannot be registered because the queue (queue-name) reached the maximum number of jobs (maximum-number).) is output to the integrated trace log:
The number of QUEUE jobs or submit jobs might have reached the maximum number that can be queued.
Execute the jpqqueshow command to check the maximum number (MAXQUEUE) for QUEUE jobs or submit jobs. During operation, make sure that the number of QUEUE jobs or submit jobs stays below the maximum number.
To change the maximum value for QUEUE jobs and submit jobs, use either the jpqquealt command to change the maximum number of jobs in a queue, or the jpqimport command to re-create the job execution environment database for QUEUE jobs and submit jobs. For details about how to re-create the database, see 2.12.2 Procedure for re-creating the execution environment database for QUEUE jobs and submit jobs.
-
If the KAVU4520-W message (The job cannot be registered because the system already reached the maximum number of jobs (maximum-number), as stipulated in environment setting (logical-host-name).) is output to the integrated trace log:
The number of QUEUE jobs or submit jobs might have reached the maximum number that can be queued in the system.
The maximum number of jobs allowed in the system is specified in the MaximumContentJob environment setting parameter.
During operation, make sure that the number of QUEUE jobs and submit jobs stays below the maximum number of jobs allowed in the system.
If you want to change the maximum number of jobs allowed in the system, see the Release Notes, and specify an appropriate value.
-
If the KAVU3586-W message (The privilege for service account was not set.) or the KAVU3571-W message (User mapping (JP1-user-name) failed.) is output to the integrated trace log (for Windows only):
The JP1/AJS3 service account might not be set up as a user account. In addition, the user account might not have the necessary permissions.
Set up the JP1/AJS3 service account as a user account and grant the necessary permissions. For details about setting up accounts for JP1/AJS3 services, see 4.2 JP1/AJS3 service settings in the Job Management Partner 1/Automatic Job Management System 3 System Design (Configuration) Guide. If you change the JP1/AJS3 service account, restart the JP1/AJS3 services.
-
If the KAVU4581-W message (The execution file (file-name) at the agent (agent-host-name) is not an executable file.) is output to the integrated trace log:
The application file name associated with the file type might contain a space character.
In Windows Explorer, click View and then Options to display the Options dialog box. On the File Types page of the dialog box, check the associated application. If the application name contains a space character, enclose the file name in double quotation marks (").
-
If the KAVU4531-W message (The agent (agent-host-name) host name might be invalid.) is output to the integrated trace log:
The agent host name might be invalid, or resolution of the agent host name to an IP address might not be possible.
Check whether the agent host name is valid. Also check the hosts file to make sure that the host name can be resolved to an IP address.
-
If the KAVU4530-W message (The agent (agent-host-name) might have stopped, or an obstacle might have occurred.) is output to the integrated trace log:
The JP1/AJS3 service on the agent (job execution host) or the computer itself might have stopped, or a network error might have occurred.
Check the status of the agent, JP1/AJS3 service, and network.
-
If the KAVU3521-W message (The job (job-number) process could not be generated. (reason code:reason-code)) is output to the integrated trace log:
An attempt to start the job might have failed because of insufficient memory.
Check the memory size estimate.
-
If the KAVU4597-W message (A missed job at the agent (agent-host-name) was forcibly terminated.) or the KAVU4538-W message (The status of job (job-number) missed at the agent (agent-host-name) was changed to recovered (status).) is output to the integrated trace log:
The above messages are output in the following cases:
-
When a job is being executed on JP1/AJS3 - Manager, the JP1/AJS3 - Manager host or a JP1/AJS3 process goes down, after which JP1/AJS3 - Manager is restarted.
-
When a job is being executed on a remote execution host (agent), the execution host or a JP1/AJS3 process goes down, after which JP1/AJS3 on the execution host is restarted.
-
When a job is being executed on a remote execution host (agent), the JP1/AJS3 - Manager host and then the execution host go down, after which the JP1/AJS3 - Manager host and the execution host are restarted.
For QUEUE jobs and submit jobs, if a job is forcibly ended without its end status being reflected in the job execution environment database, the end status of the job becomes unknown, and a KAVU4597-W message or a KAVU4538-W message is output.
Register the applicable jobnet or job for re-execution as needed.
-
-
If the KAVU4546-W message (The PATH variable could not be acquired at the agent (agent-host-name).) is output to the integrated trace log (for UNIX only):
Check the login script of the execution OS user for any condition that causes processing to end prematurely.
If the login script contains any entries unnecessary for job execution by JP1/AJS3, either delete them, or skip them by appropriately specifying the JP1JobID environment variable.
-
If the KAVU5282-W message (A system call error occurred during a database process. (module:reason-location[reason-code],reason code:reason-code)) is output to the integrated trace log:
The number of job information items regarding QUEUE jobs and submit jobs might have exceeded 200,000.
Use the following procedure to change the number of days for retaining job information, and re-create the job execution environment database for QUEUE jobs and submit jobs.
To re-create the job execution environment database:
-
Change the number of days for retaining job information.
Specify a number of days so that the number of job information items will not exceed 200,000.
Use the jajs_config command to specify the PreserveTerm environment setting parameter.
-
Use the jpqimport command to re-create the job execution environment database for QUEUE jobs and submit jobs.
-
-
If the KAVU3577-W message (A system call (function-name) error occurred in a job execution process. (reason code:reason-code)) is output to the integrated trace log (for UNIX only):
The directory specified in the work path for job execution might not be treated as the current directory. The directory specified in the work path is the directory that operates as the current directory.
-
If the KAVU4548-W message (The temporary file at the agent (agent-host-name) cannot be accessed.) or the KAVU4583-W message (The execution shell is missing at the agent (agent-host-name).) is output to the integrated trace log, the OS user mapped to the JP1 user might not be able to log in to the OS. If a message is output, check the following:
-
If the KAVU4548-W message is output
Check whether the home directory specified in /etc/passwd exists.
-
If the KAVU4583-W message is output
Check whether the login shell specified in /etc/passwd exists.
-
-
If the KAVU7533-E message (The execution user (user-name) mapped from JP1 user (host name = host-name,JP1 user = user-name) is invalid. (Reason code: 1326)) is output to the integrated trace log, in Windows, the access token of the OS user who executed the job might not have been obtained. Possible causes are as follows:
-
The access token could not be obtained because of a temporary error in the Win32API functions.
-
If the user who executed the job is a domain user, the domain user could not log on temporarily because the domain controller was not running or for another reason. During JP1/AJS3 operation, an access token is obtained when a job is executed. However, JP1/AJS3 is not aware of the number and status of domain controllers at that point. You must therefore be careful when you restart a domain controller while a job is being executed.
To avoid the above situations that temporarily prevent an access token from being obtained, you can specify settings to enable the reuse of access tokens. Doing so reduces the number of times required to obtain access tokens to a minimum and the number of such errors. For details, see 6.2.17 Reusing access tokens for job execution in the Job Management Partner 1/Automatic Job Management System 3 Configuration Guide 1.
Also note that when you reuse access tokens, the method of using the desktop heap changes.
Thoroughly verify operation of the entire system to avoid any problems. For details, see 6.2.17(3) Notes in the Job Management Partner 1/Automatic Job Management System 3 Configuration Guide 1. For details about access tokens, see 5.4.1 User account for job execution in the manual Job Management Partner 1/Automatic Job Management System 3 Overview as well.
-
-
If the KAVU4721-E message (The request was rejected. (job-number)) is output to the integrated trace log:
Check the KAVU3296-E message that is output to the integrated trace log on the host where the job was to be executed. If necessary, add any required IP addresses in the agent connection permission configuration file, and then execute the jajs_pmtcon command.
-
If the KAVS8029-E message (The request was rejected. (unit-name)) is output to the integrated trace log:
Check the KAVS8039-E message that is output to the integrated trace log on the host where the job was to be executed. If necessary, add any required IP addresses in the agent connection permission configuration file, and then execute the jajs_pmtcon command.
(2) Executing a standard job, action job, or custom job results in an abnormal end
Possible causes are as follows:
-
An environment variable used in executing the job might be invalid. There are two types of environment variables: those that are defined directly in a job and those that are specified in an environment variable file.
To check whether inappropriate environment variables are being used, see 1.4 Environment variables in the manual Job Management Partner 1/Automatic Job Management System 3 Command Reference 1.
-
A file name specified in a job might be invalid.
Check the following regarding file names:
-
Each job execution file name (execution file name for Windows and script file name for UNIX), environment variable file name, standard input file name, standard output file name, and standard error output file name must be unique. (An exception is that the standard output file name and the standard error output file name can have the same name).
-
The standard output file name and the standard error output file name must be different for jobs that are executed concurrently.
-
-
The standard output or the standard error output might have been competing for use of the redirect destination during processing of the executable file specified in a job. Check the following:
-
Make sure the standard output file or the standard error output file specified in the job is different from the redirect destination file for the standard output or the standard error output specified in the executable file.
-
If you concurrently execute multiple jobs with executable files specified, make sure different file names are specified as the redirect destinations for the standard output and the standard error output in the executable file.
-
-
The settings in /etc/logingroup might be invalid (when the execution host is HP-UX).
If an OS user who executes a job belongs to multiple groups and needs to access multiple groups, login groups must be specified in /etc/logingroup. If login groups are not specified in /etc/logingroup, only those group IDs defined in /etc/passwd are valid. Any group IDs not defined in /etc/passwd are invalid. For example, if an OS user named jp1user belongs to groups A and B (group A is defined in /etc/passwd and group B is not defined in /etc/passwd), the OS user cannot reference the files of group B. To enable access to multiple groups, copy the group definition in /etc/group to /etc/logingroup, or create a symbolic link between /etc/group and /etc/logingroup. For details, see the documentation for the OS.
-
The following commands might not operate correctly, as described below (when the execution host is Windows):
-
When a job containing the net use command is executed, an attempt to disconnect a network folder fails.
Two measures are available for handling this problem.
The first is to specify the net use command in a single batch file that is used to connect and disconnect network folders.
The second is to change the account for the applicable JP1/AJS3 service to a user account and execute the job containing the net use command with the new account for the JP1/AJS3 service (user account). For details about how to change the account for a JP1/AJS3 service to a user account, also see 4.2.3 Changing the JP1/AJS3 service settings (Windows only) in the Job Management Partner 1/Automatic Job Management System 3 System Design (Configuration) Guide.
-
When a job containing the ftp command is executed, standard output data is not output.
Two measures are available for handling this problem.
The first is to specify the -v option in the ftp command.
The second is to specify CON as the standard input file name, standard output file name, and standard error output file name when you define the job. If you specify CON for these file names, data is output to the standard output file and standard error output file. However, the standard error output messages related to the job are not output to JP1/AJS3 - View when you use JP1/AJS3 - View to display the detailed execution results. In addition, you cannot use the jpqjobget command to obtain information from the standard output file and the standard error output file.
Cautionary note
If the same problem occurs when you use a command other than the ftp command, specify CON as described above.
-
When a job containing a command other than those described above is executed, the job does not run correctly.
JP1/AJS3 jobs are executed as services that are independent of the logon session of OS users so that JP1/AJS3 jobs can be executed even if an OS user has not logged on to Windows. Accordingly, the execution results of jobs might not be the same when JP1/AJS3 is used to execute the jobs and when the Command Prompt window is used to execute the jobs.
You can use the AT command or Task Scheduler provided by Windows to check whether jobs are executed correctly from a Windows service (at this time, the Schedule service or the Task Scheduler service of Windows starts the jobs). If a job does not run correctly from a Windows service, it will not run correctly from a JP1/AJS3 service, either. In such cases, you must check the commands and programs used in the job, and correct them if necessary.
The verification procedure is as follows when the browser is Internet Explorer 4.0 or later.
When using Internet Explorer 4.0 or later
To check the commands and programs used in a job:
1. In Windows, open the Services dialog box, and clear the Enable Service to interact with Desktop check box for the Task Scheduler service.
2. Restart the Task Scheduler service.
3. On the desktop, click the My Computer icon and open the Scheduled Tasks folder.
4. Use the wizard to set up a task.
When you set up the task, specify the job to be executed and the account of the execution user.
5. Check the execution result of the job.
Note that the Schedule service, the Task Scheduler service, and the JP1/AJS3 service generate job processes in slightly different ways. Therefore, even if a job does not run correctly when JP1/AJS3 is used, it might run correctly when a Windows service is used. For example, JP1/AJS3 might not be able to reference the information about the printers and applications specified in the logon session of an OS user if the information is stored in the registry. This is so even if the account of the OS user is specified for the execution user of the job, (sometimes with result the printing to a printer from the job, or application startup is not done correctly). In such cases, the OS user who executes the job must log on to Windows (execution host of JP1/AJS3) and execute the job.
Alternatively, specify the necessary settings as described in 6.2.16 Executing a job that requires a user profile in the Job Management Partner 1/Automatic Job Management System 3 Configuration Guide 1.
If you want to grant only users of the local server the access permissions for execution users, specify OS users in server-name\user-name format.
-
-
Job startup might fail because memory is insufficient.
Check the memory size estimate.
-
If the following messages are output to the integrated trace log (for Windows only):
-
KAVU4254-E message (It cannot access the database (logical-host-name). (reason code:reason-code))
-
KAVU5287-E message (The database table is locked. (reason-location))
These messages appear if the ISAM files for the job execution environment cannot be accessed when a QUEUE job or a submit job is executed. Make sure that the following are not executed simultaneously:
-
Data collection tool of JP1/AJS3
-
A command that operates on the ISAM database, such as a command that verifies or condenses the ISAM database for JP1/Base or JP1/AJS3 (except for the jpqdbcond -L command)
-
A backup program
Additionally to the above, the same problem might occur if a program is executed to open the database file for the job execution environment for QUEUE jobs and submit jobs in exclusive mode or in share mode in which only reading of files is shared. When you schedule this type of task, schedule it so that it will not be executed while jobs are being run.
-
-
If the following messages are output to the integrated trace log (for UNIX only):
-
KAVU4547-W message (You are not authorized to access the temporary file at the agent (agent-host-name).)
-
KAVU4560-W message (You lack access permission for the standard output file (file-name) at the agent (agent-host-name).)
-
KAVU4563-W message (You lack access permission for the standard error output file (file-name) at the agent (agent-host-name).)
If the KAVU4547-W message is output, the owner group of the work directory might be the secondary group of the job execution user, and the permission for the work directory might be 770 (the work directory is specified in the WorkPath environment setting parameter in the [JP1_DEFAULT\JP1NBQAGENT\Process] definition key).
If the KAVU4560-W or KAVU4563-W message is output, the owner group of the directory containing the specified file (file-name in the messages) might be the secondary group of the job execution user, and the permission for the directory might be 770.
Take one of the following actions:
-
If the KAVU4547-W message is output, change the access permission for the work directory so that the secondary group can access the directory.
-
Change the permission for the directory containing the specified file to one that allows the secondary group to access the directory. Also, change the permission for the specified file to one that allows the secondary group to read and write to the file.
-
Change the owner group of the directory and the specified file from the secondary group to the primary group of the job execution user.
-
Enable the necessary options as specified in 15.2.18 Enabling the file access permission check for the ACL and secondary group settings during job execution in the Job Management Partner 1/Automatic Job Management System 3 Configuration Guide 1.
-
-
If the KAVU4551-W message (You are not authorized to access the execution file (file-name) at the agent (agent-host-name).) is output to the integrated trace log (for UNIX only):
The owner group of the directory containing the specified execution file (file-name in the message) might be the secondary group of the job execution user and the permission might be 770.
Take one of the following actions:
-
Change the permission for the directory containing the specified file to 771, and change the permission for the specified file to 774.
-
Change the owner group of the directory and the specified file from the secondary group to the primary group of the job execution user.
-
Enable the necessary options as described in 15.2.18 Enabling the file access permission check for the ACL and secondary group settings during job execution in the Job Management Partner 1/Automatic Job Management System 3 Configuration Guide 1.
-
-
Sometimes, the execution file name of a job cannot be correctly determined.
In UNIX:
When $0 (script file name) is referenced in a script file, $0 might be replaced by a script file name beginning with JPQ_EXEC_ instead of the script file name specified in the job definition.
This file name is the name of a script file that is temporarily created by JP1/AJS3 in the following cases (the script file is created in the work path that is used when the job is executed):
-
You execute a job containing the command that is specified in Command statement on the Definition page in the Define Details - [UNIX Job] dialog box of JP1/AJS3 - View.
-
You execute a script file whose name does not begin with #! shell-name in Script file name on the Definition page in the Define Details - [UNIX Job] dialog box of JP1/AJS3 - View#.
-
You execute a script file whose name does not begin with #! shell-name in the -sc option of the jpqjobsub command.
- #
-
If the name of the execution shell is not written on the first line of the script file specified in Script file name, JP1/AJS3 creates a temporary script file with the execution shell name added to the first line, and executes the file as a job.
If you specify a command in Command statement and a script file name in Script file name at the same time, the specified command and script file name are merged into a temporary file in the sequence command and then script file name. Therefore, when a command is specified in Command statement, a temporary file is created regardless of whether an execution shell name is written in a script file (a temporary file is also created if a tab or space character is specified in Command statement).
To avoid creating temporary script files, define jobs so that none of the above conditions arise.
In Windows:
When the first argument (%0 in a batch file) in an execution file for Windows is referenced, the first argument might not be replaced by the execution file name specified in the job definition. This is because execution file names are converted to short file names in 8.3 format when JP1/AJS3 starts jobs.
To start a job without converting the execution file name in 8.3 format, see 6.2.15 Executing a job by using a long file name in the Job Management Partner 1/Automatic Job Management System 3 Configuration Guide 1.
-
-
If the following message is output to the integrated trace log (for Windows only):
-
KAVU7533-E message (The execution user (user-name) mapped from JP1 user (host name = host-name, JP1 user name = user-name) is invalid. (reason code: 1792).)
If you execute a job with a user account that is different from the account for the JP1/AJS3 service and the Net Logon service is not running, this message might be output and the job might end abnormally. If this message appears, check whether the Net Logon service is running.
-
-
If either of the following error messages is displayed when a job ends abnormally (for Windows only):
-
The job ends abnormally with return code 259 or -1, and the following message is output:
KAVU3284-W message (A system call error occurred in the internal process (logical-host-name). (module:reason-location[reason-location], reason code = 0x2013000a))
-
The job ends abnormally, and the following message output to the standard error output for the job:
The process cannot access the file. The file is being used by another process.
The above might occur when both of the following conditions exist:
-
When you register a job, a standard output file or standard error output file is explicitly specified by using either of the following methods:
- The file is specified in the detailed definition of the job.
- The file is specified in the job execution control command when you register the job.
-
Either of the following occurs for the file specified in step 1:
- In the program to be executed as a job, the file is opened with a function when the object-sharing method is either read-protected or write-protected.
- In the batch file to be executed as a job, the file is opened by using redirection.
As the standard output file or standard error output file when you register a job, do not specify a file opened from within a program executed as a job or opened by redirection from a batch fie. However, if the file is opened from within the program by using a function call, you can get around the problem by opening the file with a setting that permits shared reading or shared writing.
-
-
If either of the following messages is output to the integrated trace log:
-
KAVU5290-E message (The database file size is larger than the limit, or memory could not be allocated. (reason location: reason-location [reason-location], reason number: reason-number))
An ISAM file might be invalid.
These errors might occur if you perform one of the following operations:
-
You forcibly shut down the system or turn off the power while the JP1/AJS3 service is still running.
-
You attempt to write to an ISAM file when there is insufficient disk space.
Check the status of the ISAM files. If an ISAM file is invalid, create the file again. For details about how to check the status of ISAM files and re-create them, see 2.12 Troubleshooting problems related to invalid ISAM files.
-
When you execute a job on an execution host running AIX or Linux, the resource limits defined for the user executing the job might not take effect. This could cause the job to end abnormally due to insufficient resources.
In AIX and Linux, when you define resource limits in /etc/security/limits (In Linux, /etc/security/limits.conf) for the user executing a job, the values will not take effect when the job is executed. Therefore, define the resource limits for the user (root) who starts JP1/AJS3.
For details, see Resource limits when Unix jobs are executed in 7.4 Notes on using Unix jobs in the Job Management Partner 1/Automatic Job Management System 3 System Design (Work Tasks) Guide.
(3) The status of a standard job, action job, or custom job does not change
Possible causes are as follows:
-
If the KAVU3531-W message (The manager (logical-host-name) host name might be invalid.) is output to the integrated trace log:
The host name of the manager might be invalid, or the host name might not be resolved to an IP address.
Check whether the host name of the manager is valid. Also check the hosts file to make sure that the host name can be resolved to an IP address. If a DNS server is used, specify settings so that FQDN-format host names will be resolved to IP addresses.
-
The number of currently running jobs might have reached the maximum number of concurrently executable jobs.
Execute the ajsagtshow command to check the number of currently running jobs (JOB) and the maximum number of concurrently executable jobs (CON-EXE).
Specify the maximum number of concurrently executable jobs taking into considering the execution time of jobs and the number of jobs to be executed per unit time. To change the maximum number of concurrently executable jobs, use the ajsagtalt command.
For details about this command, see ajsagtshow in 2. Commands in the manual Job Management Partner 1/Automatic Job Management System 3 Command Reference 1.
To determine whether the maximum number of concurrently executable jobs has been reached when job execution takes too much time or you cannot register a job, you can specify settings beforehand that output an appropriate message to the integrated trace log. For details about how to specify these settings, see 6.2.13 Outputting a message that reports that the maximum number of concurrently executable jobs has been reached in the Job Management Partner 1/Automatic Job Management System 3 Configuration Guide 1 (for Windows) or 15.2.13 Outputting a message that reports that the maximum number of concurrently executable jobs has been reached in the Job Management Partner 1/Automatic Job Management System 3 Configuration Guide 1 (for UNIX).
-
While JP1/AJS3 was running, a backup program might have been executed to make backup copies of files and directories used by JP1/AJS3.
Do not execute a backup program while JP1/AJS3 is running.
(4) Registering a standard job, action job or custom job, or manipulating a queue results in an access permission error
An invalid access permission has been set for the JP1/Base authentication server.
Specify the correct access permission for the JP1_Queue resource group. Registering jobs and manipulating queues require one of the following permissions: JP1_JPQ_Admin, JP1_JPQ_Operator, and JP1_JPQ_User.
(5) The shell does not read environment variables (AIX only)
In AIX, the information in /etc/environment is not inherited.
See the explanation in 13.4.2 Changing the login scripts in the Job Management Partner 1/Automatic Job Management System 3 Configuration Guide 1, and change the login script. The following example shows how to change the login script:
if [ "$JP1JobID" != "" ] ; then . /etc/environment export environment-variable-to-be-specified fi
After /etc/environment has been read, execute the export command for the environment variable to be specified.
- Cautionary notes
-
-
The above setting is valid only for sh and ksh (.profile). It is invalid for other shell scripts such as csh.
-
When you specify the above setting, /etc/environment is read into the login script, possibly causing and the setting sequence of the information to change. Therefore, when you add processing that reads /etc/environment into the login script, check whether the environment variables set in /etc/environment are also specified in the login script. In addition, be careful about where you add /etc/environment. We recommend that you set the login script to read /etc/environment at the beginning of the login script.
-
(6) A job ends normally without executing the job process
In UNIX, JP1/AJS3 executes the login script when it executes a job. When the login script contains a command that ends the login script, such as the exit command shown below, the job ends normally before the job process is executed.
/usr/bin/sh ; exit
To avoid premature ending of the job, change the login script so that the exit command is not executed.
For details about how to change the login script, see 13.4.2 Changing the login scripts in the Job Management Partner 1/Automatic Job Management System 3 Configuration Guide 1.
(7) Automatic retry is not performed when the retry interval has elapsed
Automatic retry might be delayed if there are a large number of jobs. Temporarily change the jobnet schedule or forcibly terminate the executing units to reduce the number of jobs that are executed simultaneously.
To set up automatic retry, you need to estimate the number of jobs, which also includes the number of retry executions. For details, see 1.3 Design considerations in the Job Management Partner 1/Automatic Job Management System 3 System Design (Configuration) Guide.
(8) A task is delayed because automatic retry is performed concurrently for jobs
If jobs being executed on an agent host have ended concurrently due to, for example, an error on the agent host, automatic retry is performed for these jobs concurrently, increasing the number of jobs.
If you detect that the task is delayed because automatic retry has caused the number of jobs to increase, execute the ajsagtalt command to restrict jobs from being accepted on the execution agent where the error occurred. After agent host recovery, execute the ajsagtalt command again to cancel the restriction on job acceptance.
If automatic retry occurs when an error that requires some time for recovery has occurred, the increasing number of jobs might affect job execution performance. Therefore, when setting up automatic retry, specify the smallest necessary range of return codes. For details about automatic retry, see 2.4.10 Automatic retry for abnormally ending jobs in the Job Management Partner 1/Automatic Job Management System 3 System Design (Work Tasks) Guide.