Job Management Partner 1/Automatic Job Management System 3 System Design (Work Tasks) Guide
This section gives notes on using event jobs.
- Event jobs do not support operations that use execution agent groups. If an event job without a specified execution agent is included in a root jobnet or nested jobnet for which an execution agent group is specified, JP1/AJS3 will attempt to use the agent group specified for the jobnet as the execution agent for the event job. If an execution agent with the same name as the agent group exists, the event job will be executed by that execution agent. If there is no execution agent with the same name as the agent group, an error occurs and the following message is output to the integrated trace log: KAVT0403-E The specified agent is not defined in the job execution environment. (host=exec-agent, maintenance-information). Therefore, if you want to specify an execution agent group for a root jobnet or nested jobnet, make sure that an execution agent is explicitly specified for the event job in the jobnet.
- You cannot specify the name of an execution agent group in the Exec-agent field of the detailed definition of an event job.
- JP1/AJS3 cannot correctly detect events issued by the JP1/AJS3 program itself, including JP1 events, events logged to the Windows event log or syslog, or events recorded in HNTRLib and Scheduler log files. For details about the events that can be monitored by an event job, see 7.6.9 Monitoring events or messages issued by JP1/AJS3.
- For an event job waiting for a start condition to be satisfied, if JP1/AJS3 - Manager stops during start condition monitoring, you can resume event monitoring after JP1/AJS3 - Manager restarts. If multiple events were being monitored for a start condition, you can hold the reception information of the events that satisfy the condition even after JP1/AJS3 - Manager restarts.
- When an event job is defined at the beginning of a jobnet, the jobnet is executed after the condition is satisfied, in the same way as a jobnet with a start condition. A jobnet with a start condition stays in Wait for start condition status while event reception is being monitored. A jobnet with an event job defined at the beginning is kept in Now running status while event reception is being monitored. When you define an event job at the beginning of a jobnet, we recommend that you use the event job to wait for events you expect to occur.
- When you monitor multiple events, you can improve performance by using regular expressions to create an event job that monitors all of them in a batch.
For example, if you use the Receive JP1 Event job to monitor JP1 events in the form of messages KAVS0272-E and KAVS00273-E with event ID 00004131, group the event jobs by specifying only the event ID or by specifying 00004131 for the event ID and KAVS for the message. You can identify the contents of events by using passing information.
- A timeout period specified for an event job is counted at the execution agent. If the execution agent goes down during monitoring due to power failure or other problem, and then restarts and resumes monitoring events, the execution agent starts counting the timeout period again from the moment it restarts. This is called monitoring of the timeout period according to relative time. You can check whether counting of the timeout period has been restarted and the time at which the count was restarted in the execution result details for the event job.
If you want monitoring to time out based at an absolute time from job registration, regardless of the status of the execution agent, define a start condition for the monitored event so that a JP1 event is sent to the manager when the start condition is satisfied. Then use a Receive JP1 Event job on the manager to specify the timeout time and start monitoring. This is called monitoring of the timeout period according to absolute time.
- In Windows, JP1/AJS3 event jobs do not depend on the settings of the JP1 users that run them. Rather, they depend on the account permissions for the JP1/AJS3 service.
The following permissions must be granted to the accounts associated with the JP1/AJS3 service:
If a required permission is not granted, the following will occur:
- Write permission for monitoring target files and folders when a Monitoring Files job is used. The monitoring target files must not be read-only.
- Write permission for message queues during MQSeries linkage
- Write permission for message queues during TP1/Message Queue linkage
- Event jobs (Monitoring Files jobs and Receive MQ Message jobs) end abnormally.
- Events do not occur.
- JP1/AJS3 event jobs are independent of the permissions set for JP1 users defined in the JP1/Base environment settings and in the respective jobs.
- Sometimes there is a time lag between the execution of an event job and the actual time when event monitoring begins in the execution agent. The system detects only events that occur after event monitoring begins. Therefore, you must provide some leeway when executing an event job, to allow the system to be ready and monitoring when a target event occurs.
- When you execute event jobs (including those with a start condition), definition data for the executed event jobs and information about events that satisfy monitoring conditions is transmitted between processes such as the event/action control manager and the event/action control agent. If transmission fails due to some problem such as a temporary network error or because the remote process is busy, the information is saved to a file and transmission is attempted again after a predetermined interval. In JP1/AJS3, this is referred to as an unreported information file. At successful re-transmission, the information is deleted.
- When using JP1/AJS3, in the API settings file for the JP1/Base event service, set keep-alive for the communication type of the server parameter. Setting close as the communication type can result in operational problems, including JP1/AJS3 being unable to issue JP1 events at startup, causing message KAVT1040-E to be output to the integrated trace log. This in turn renders Receive JP1 Event jobs, Monitoring Log Files jobs, Monitoring Event Log jobs, and Send JP1 Event jobs unable to detect events, and causes Send JP1 Event jobs to end abnormally. For details about the API settings file and how to set parameters, see the Job Management Partner 1/Base User's Guide.
- In a manager/agent configuration, if the event/action control manager and the event/action control agent are unable to communicate due to a network error or other problem, inconsistencies in event job monitoring (including event jobs defined as start conditions) can occur if you perform any of the operations listed below. In this case, the event job will continue monitoring on the agent despite having ended on the manager.
These operations can result in problems such as failure to restart the event job where the inconsistency occurred, and delays to processing of other normal event jobs.
- Killing an event job
- Killing a jobnet that has a start condition
- Changing the status of an event job to Ended
For this reason, if you perform one of the above operations in a system affected by a network error or similar problem, execute the jpomanjobshow command on the manager host, and the jpoagtjobshow command on the agent host. Compare the results of the commands to see whether any event jobs that have ended on the manager are still monitoring on the agent.
If you discover an event job that is in Now monitoring status only on the agent host, restart the JP1/AJS3 service on the agent host, and then terminate the event job that is still monitoring on the agent.
- Organization of this section
- 7.6.1 Notes on the Receive JP1 Event job
- 7.6.2 Notes on the Monitoring Files job
- 7.6.3 Notes on the Receive Mail job
- 7.6.4 Notes on the Monitoring Log Files job
- 7.6.5 Notes on the Monitoring Event Log job
- 7.6.6 Notes on the Interval Control job
- 7.6.7 Notes on defining passing information
- 7.6.8 Notes on restarting the JP1/AJS3 service while event jobs are running
- 7.6.9 Monitoring events or messages issued by JP1/AJS3
Copyright (C) 2009, 2010, Hitachi, Ltd.
Copyright (C) 2009, 2010, Hitachi Solutions, Ltd.