Job Management Partner 1/Automatic Job Management System 3 System Design (Work Tasks) Guide

[Contents][Glossary][Index][Back][Next]


8.1 Checking definitions before live JP1/AJS3 operation

JP1/AJS3 allows you to check whether job definitions are valid before you deploy them, to prevent failures in a production environment.

The following figure shows the sequence of operations involved in a definition pre-check, up to the point when you begin live operation.

Figure 8-1 Flow of system design and definition pre-check up to commencing operation

[Figure]

Use the ajschkdef command to run a definition pre-check. When you execute the ajschkdef command, the check results are output to the pre-check result file. You can see the results of the pre-check by viewing the file. The pre-check result file is output to the following location by default:

In Windows Server 2008:
%ALLUSERSPROFILE%\HITACHI\JP1\JP1_DEFAULT\JP1AJS2\log\ajscheckfile.txt
(The default location of %ALLUSERSPROFILE% is system-drive\ProgramData.)

In Windows Server 2003:
JP1/AJS3 - Manager-installation-folder\log\ajscheckfile.txt

In UNIX:
/var/opt/jp1ajs2/log/ajscheckfile.txt

For details on the ajschkdef command, see ajschkdef in 2. Commands in the manual Job Management Partner 1/Automatic Job Management System 3 Command Reference 1.

Before you run a definition pre-check, you must set up the definition pre-check function. For details on how to set up the function and its environment, see 6.5.1 Setting up the JP1/AJS3 definition pre-check function in the Job Management Partner 1/Automatic Job Management System 3 Configuration Guide 1 (for Windows systems) or 14.5.1 Setting up the JP1/AJS3 definition pre-check function in the Job Management Partner 1/Automatic Job Management System 3 Configuration Guide 1 (for UNIX systems).

Organization of this section
(1) Checked items
(2) Pre-check sequence
(3) Cautionary notes
(4) Notes on definition pre-checks in a cluster system

(1) Checked items

The following table lists the items checked by the definition pre-check function.

Table 8-1 Items checked by the definition pre-check function

Category Description
Job execution order
  • Checks whether the execution order creates a loop.
  • Checks whether a subordinate job is connected to a judgment job by a condition.
  • Checks whether relations other than conditions are defined for subordinate jobs.
Detailed definition of a jobnet Jobnet connector Connection range
  • Checks whether the connection range matches that specified for the connection-destination jobnet
Connection host
  • Checks whether the specified host is accessible.
Connection service
  • Checks whether the specified scheduler service exists.
Connect destination Performs the following:
  • Checks whether a connection-destination jobnet is specified.
  • Checks whether the specified unit is a root jobnet or a planning group.
  • Checks whether the specified unit exists.
  • Checks whether the specified unit is subject to execution order control.
  • Checks whether the specified unit specifies a different host.
  • Checks whether the specified unit specifies a different scheduler service.
  • Checks whether the specified unit specifies a different jobnet connector.
Empty job definition For a Unix job, checks whether a Script file name or Command statement is specified.
For a PC job, checks whether a File name is specified.
For a Receive JP1 event job, checks whether a Event ID is specified.
Execution agent name
  • Unix job
  • PC job
  • Action job
When Standard is specified as the Exec. service#1 Performs the following:
  • Checks whether the agent host is registered with the manager.
  • Checks whether the manager can resolve the execution host name (agent host name) set for the execution agent.
  • Checks whether the agent can resolve the host name of the manager.
When Queueless Agent is specified as the Exec. service Performs the following:
  • Checks whether the manager can resolve the host name of the agent.
  • Checks whether the agent can resolve the host name of the manager.
Event job Performs the following:
  • Checks whether the agent host is registered with the manager.
  • Checks whether the manager can resolve the execution host name (agent host name) set for the execution agent.
  • Checks whether the agent can resolve the host name of the manager.

  • Jobnet#1
  • Custom job#1
Performs the following:
  • Checks whether the execution agent is registered with the manager.
  • Checks whether the manager can resolve the execution host name (agent host name) set for the execution agent.
  • Checks whether the agent can resolve the host name of the manager.
User mapping Checks whether user mapping can be performed correctly on the agent. This check uses the same method for JP1 users, execution source hosts, and OS users as when normal jobs are executed. Note that JP1/AJS3 does not check whether the OS user mapped to a JP1 user actually exists.
Detailed definition of a job Unix job Script file name
  1. Checks whether the file exists on the Agent.#2, #3
  2. Checks the access permission for the file.
Environment file
  1. Checks whether the file exists on the Agent.#4
  2. Checks the access permission for the file.
Working path
  1. Checks whether the path exists on the Agent.#2
  2. Checks the access permission for the path.
Standard input
  1. Checks whether the file exists on the Agent.#4
  2. Checks the access permission for the file.
Standard output
  1. Checks whether the directory containing the file exists on the Agent#4
  2. If the file exists, checks the access permission for the file.
Standard error
  1. Checks whether the directory containing the file exists on the Agent#4
  2. If the file exists, checks the access permission for the file.
User name Checks the user by user mapping.
File to transfer
  1. Checks whether the file exists on the Manager#2.
  2. Checks the access permission for the file.
Destination file
  1. Checks whether the file exists on the Agent.#2
  2. Checks the access permission for the file.
PC job File name Checks whether the file exists on the Agent.#2, #3
Environment file Checks whether the file exists on the Agent.#4
Working path Checks whether the path exists on the Agent.#2
Standard input Checks whether the file exists on the Agent.#4
Standard output Checks whether the directory containing the file exists on the Agent.#4
Standard error Checks whether the directory containing the file exists on the Agent.#4
User name Checks the user by user mapping.
File to transfer Checks whether the file exists on the Manager.#2
Destination file Checks whether the file exists on the Agent.#2
Receive JP1 Event job Event ID Checks whether the event ID confirms to the proper format.
Find events prior to execution Checks whether the pre-search time is within the specified range.
Monitoring File job Monitoring file Checks the format of the file name.
Receive Mail job Platform Checks whether the OS matches that of the execution destination host.
Common to action jobs Platform Checks whether the OS matches that of the execution destination host.
Permission for executing files#5 Checks whether the OS user who executes the job has execution permission for the target file. This check uses the same method as when normal jobs are executed. However, for queueless jobs executed in UNIX, execution permissions are not checked when the root user executes the job (in this case, no execution permission is required).
Note that JP1/AJS3 checks execution-file permissions only for the primary group of the OS user who executes the job.

#1
This item is not checked if the name of an execution agent group is specified.

#2
This item is not checked if a relative path or a UNC path is specified.

#3
For items that can take macro variables, there is no way to determine the actual data that will be used at execution. Therefore, the values resulting from macro variables are not checked.

#4
Relative paths are not checked when an invalid work path is detected.

#5
PC jobs (on a Windows host) are not checked.

(2) Pre-check sequence

The following figure shows the flow of a definition pre-check.

Figure 8-2 Flow of the definition pre-check process

[Figure]

(3) Cautionary notes

Note the following when performing a definition pre-check:

  1. Do not run a definition pre-check while the system is being used to perform business tasks. Doing so can lead to the following problems:
    • Access contention for the scheduler database reduces job processing performance.
    • The system load might temporarily spike, causing errors during job execution processing.
  2. To run a definition pre-check, the JP1/AJS3 service must be started on the manager.
  3. You cannot perform multiple definition pre-checks simultaneously.
  4. If you also specify parameters in the Script file name field for a Unix job, the definition pre-check detects an error.
  5. Information passed from events is not checked.
  6. Macro variables are not checked.
  7. Environment variables are not checked.
  8. Job runtime variables are not checked.
  9. In UNIX, JP1/AJS3 Check Manager service does not use the port number for the jp1ajs2chkman service specified in the services file.
  10. JP1/AJS3 checks the access permissions for a script file in a different way from that used during actual operation. Therefore, the definition pre-check may detect an error for a job that would end normally.
  11. Messages KAVS3400 to KAVS3431 are output only to the integrated trace log or the standard output.
  12. In Windows, when you specify a folder as an environment variable file, a standard input file, a standard output file, or a standard error output file, and execute the queueless agent service, the job ends normally but the pre-check detects an error.
  13. In UNIX, if you specify a directory as an environment variable file and execute the job by using the queueless agent service, the job ends normally but the pre-check detects an error.
  14. When you specify the -A option in the ajschkdef command, information about the OS user who executes the job is required in order to check the permissions for the executable file. Therefore, user mapping must also be checked. However, in a Windows system, the OS does not check the account details of the user who is specified in User name in the Define Details - [PC Job] dialog box.
  15. When both of the following conditions exist, temporary files are created before the definition pre-check:
    • In the definition of a Unix job, a non-existent file is specified for the Standard output, Standard error, or Destination file.
    • A definition pre-check is executed for this job with the -D option specified.
    The temporary files are created in the location specified for the Standard output, Standard error, or Destination file of jobs that meet these conditions. As a result, the update time for the parent directory of the specified file might change. The temporary files are deleted when the check is finished.
  16. The JP1/AJS3 Check Manager service performs communication processing according to the communication settings of the JP1/Base physical host. Therefore, to use definition pre-checking in a multi-LAN environment, the appropriate communication settings (in the jp1hosts and conf files) must be specified on the JP1/Base physical host. For details about how to specify the communication settings for JP1/Base, see the Job Management Partner 1/Base User's Guide.

(4) Notes on definition pre-checks in a cluster system

Note the following when performing a definition pre-check in a cluster system:

  1. In a cluster system, when you perform a definition pre-check for units in a logical host, run the check on the primary node of the logical host. You cannot check unit definitions on the standby node.
  2. If a failover occurs while you are checking units on the primary node of the logical host in a cluster system, the checking process is interrupted. Pre-checks are not resumed after a failover to the standby node.
  3. If failover of an agent host in a cluster system environment occurs after the agent host is requested to perform pre-checks, pre-checks are retried according to the values of the environment setting parameters. However, if JP1/AJS3 cannot connect to the previous agent host, the message KAVS3410-I The connection with the check agent service (agent-name) was closed. : maintenance-information is output and pre-checks are performed on another agent host.

[Contents][Back][Next]


[Trademarks]

Copyright (C) 2009, 2010, Hitachi, Ltd.
Copyright (C) 2009, 2010, Hitachi Solutions, Ltd.