2.4.4 Executing an event-driven process (example of defining a jobnet that uses an event job)

(1) Executing a process on receipt of a JP1 event (Receive JP1 event job)

A JP1 event is an event managed by JP1/Base, issued whenever some event occurs in a JP1 program. Because JP1 events contain information such as a severity level (error, warning, or notice) or message, you can execute a succeeding job or jobnet on receipt of an error or warning, or only when a specific message is received. Using the JP1/Base event converter, you can also execute a succeeding job or jobnet at termination of an external application program.

To execute a Receive JP1 event job, you must first start the JP1/Base event service. (In the API settings file, set keep-alive for the JP1/Base event service.) If this service is inactive, the Receive JP1 event job is placed in the Now running status until the service starts.

The following figure shows an example of defining a jobnet that executes a certain job when the Receive JP1 event job receives a JP1 event from hostA, which differs from the host where the jobnet was defined.

Figure 2‒76: Example of defining a jobnet that uses a Receive JP1 event job

A Receive JP1 event job can link with a jobnet defined on another host.

On hostA, define a Send JP1 event job that sends an event with the event ID of 100. To monitor any JP1 events issued by hostA, set hostA in the Receive JP1 event job as the event-originating host name. In addition, to execute the succeeding job when an expected JP1 event is received, set 100 as the event ID.

After these settings have been made, if the Send JP1 event job in the jobnet is executed on hostA, the jobnet stops monitoring JP1 events and executes the succeeding job.

Note that the system will not detect any JP1 event occurring during the time lag after execution of the Receive JP1 event job until it is actually able to monitor for receipt of JP1 events. One solution to this problem is the find events prior to execution setting.

• Find events prior to execution

  This feature searches for events occurring before an executed Receive JP1 event job is in ready state. Any matching event is identified as having occurred.

  Figure 2‒77: Find events prior to execution

To Page Top

(2) Executing a process at file update (Monitoring files job)

Use a Monitoring files job when defining a jobnet in which file update or file creation triggers a job.

The monitoring options that you can specify for a Monitoring files job are described below.

Monitoring options

Specify the file status required as the condition to end monitoring and initiate the job. You can set any of the following four monitoring options:

• Creation of a file of the specified file name (Create)

• Deletion of a file of the specified file name (Delete)

• Change in size of a file of the specified file name (Change size)

• Change in last update time of a file of the specified file name (Final time write)

Supplementary notes

• When creation of a file with the specified name is being monitored, that file might already exist at the time the Monitoring files job starts. You can specify whether the job should assume that the monitoring condition has been satisfied if a file with the specified name already exists.

• You can specify more than one monitoring condition. For example, if you want to execute a succeeding job when a file is deleted or updated, you can specify the Delete and Final time write options. Note, however, that the Change size and Final time write options are mutually exclusive.

• For details on when a monitoring condition is or is not satisfied, see 7.6.2(1) Events monitored by the Monitoring Files job.

• If any of the Create, Change size, and Final time write monitoring conditions are satisfied, the system performs a close check to make sure the monitored file is not being accessed by any process other than the Monitoring files job. If another process is accessing the file, the condition is judged to be unsatisfied, and another close check is performed when the next monitoring interval occurs. If the file is not being accessed by a process other than the Monitoring files job, the condition is judged to have been satisfied.

  The close check prevents the job from assuming that the condition is satisfied before the transmission (for example, copying) of a monitored file has been completed.

• Files can be specified as monitoring targets over a network.

In the example below, a Monitoring files job is used to define a jobnet that monitors the write time to a particular file (file name: File1) and executes a succeeding job when the file is updated.

Figure 2‒78: Example of defining a jobnet that uses a Monitoring files job

Specify the file to monitor and the monitoring option in the definition of the Monitoring files job. In the Monitoring file field, enter the path for File1, and in the Monitoring option area, select Final time write.

In this example, the Monitoring files job ends and the triggering condition is satisfied when the monitored file closes (no further applications are accessing the file) and the last update time changes.

To monitor files via a network, set Y for the NetworkFilewatch environment setting parameter. For details about the settings for monitoring files via a network, see 6.3.19 Settings for monitoring a network file by using a file monitoring job in the JP1/Automatic Job Management System 3 Configuration Guide (in Windows) or 15.3.18 Settings for monitoring a network file by using a file monitoring job in the JP1/Automatic Job Management System 3 Configuration Guide (in UNIX).

Note that, for files to be monitored via a network, access permission settings must be specified as follows:

In Windows

Prepare a user account with permission to change the monitoring-target files, and then set the user account as the user account for starting the JP1/AJS3 service. For details about changing the user account for starting the JP1/AJS3 service, see 4.2.3 Changing the JP1/AJS3 service settings (Windows only) in the JP1/Automatic Job Management System 3 System Design (Configuration) Guide.

In UNIX

Settings must be made to ensure that view permissions can be used to access the network file specified as a monitoring target from the client.

If you monitor files on an NFS server in a Windows environment or monitor files via a network in a UNIX environment, we recommend that you set the system to monitor a file that is created to indicate processing completion when the monitoring-target file updating ends. Do not use a file monitoring job to directly monitor files to be updated. For notes on monitoring files on an NFS server in a Windows environment or monitoring files via a network in a UNIX environment, see 7.6.2 Notes on the Monitoring Files job.

To Page Top

(3) Executing a process at log file update (Monitoring log files job)

A Monitoring log files job utilizes the JP1/Base log file trapping facility. JP1/Base log file trapping converts the log file records output by an application into JP1 events, and registers them in an event database. By defining a Monitoring log files job, you can execute a job or jobnet when a log file is updated. For details on JP1/Base log file trapping, see the JP1/Base User's Guide. For notes about Monitoring log files jobs, see 7.6.4 Notes on the Monitoring Log Files job.

The following figure shows how a Monitoring log files job operates.

Figure 2‒79: Operation of a Monitoring log files job

A Monitoring log files job monitors for output of specific data to a log file on the host specified as the monitoring target. In this job, you specify the log file and the character string to be monitored. Regular expressions can be used to specify the character string (see the JP1/Base User's Guide for regular expressions in Windows, or your UNIX documentation for regular expressions in UNIX).

As the monitoring interval, you can specify a value from 1 to 86,400 (seconds). Only log files in text format can be monitored. You can monitor up to eight log files.

An example of setting a Monitoring log files job as the triggering condition is shown below.

In this example, the Monitoring log files job is used to define a jobnet that executes a succeeding job when log data containing a specific character string is written to the log file (file name: File1).

Figure 2‒80: Example of defining a jobnet that uses a Monitoring log files job

Specify the log file name and the character strings to be monitored in the definition of the Monitoring log files job. In the File to be monitored field, enter the path for File1. In the Data to be trapped area, enter the desired character strings as shown in the figure.

In this example, the Monitoring log files job ends when data matching any of three conditions (a string containing "abc" and "def", a string containing "ghi", or a string containing "jkl") is written to File1 and the log data is retrieved from the log file. This satisfies the triggering condition and the succeeding job is executed.

You can also configure a Monitoring log files job to monitor multiple log files and execute the succeeding job when log data containing a specific character string is written to any of the monitored files.

To Page Top

(4) Executing a process on receipt of a Windows event log record (Monitoring event log job)

A Monitoring event log job utilizes the JP1/Base event log trapping facility, which converts Windows event log records into JP1 events and registers them in an event database. By defining a Monitoring event log job, you can execute a job or jobnet when a Windows event is logged.

For details on JP1/Base event log trapping and the action definition file, see the JP1/Base User's Guide. For notes about Monitoring event log jobs, see 7.6.5 Notes on the Monitoring Event Log job.

The following figure shows how a Monitoring event log job operates.

Figure 2‒81: Event log trapping

A Monitoring event log job works as follows.

Log type

The types of logs that you can specify are listed below:

• Application

• Security

• System

• DNS Server

• Directory Service

• File Replication Service

• Any log type^#

#

For details about how to check the log types that can be specified for Any log type, see the JP1/Base User's Guide.

Event types

You can specify the following types of events:

• Verbose

• Information

• Warning

• Error

• Critical

• Success audit

• Failure audit

An example of defining a Monitoring event log job is shown below.

In this example, the Monitoring event log job is used in a jobnet that executes a succeeding job when a Windows event reporting successful authentication on the security system is logged to the Windows event log.

Figure 2‒82: Example of defining a jobnet that uses a Monitoring event log job

Before executing a Monitoring event log job, you must set the event log trapping behavior in the JP1/Base action definition file. In this example, the log type is Security, and the attribute name (with Type set) is Audit_success.

You must also set the log type and event type to be monitored. Set Security in Log type, and Success audit in Event type.

With these settings, the Monitoring event log job ends when the specified Windows event is output and the event log data is retrieved. This satisfies the triggering condition and the succeeding job is executed.

To Page Top

(5) Executing a process after a specified wait time (Interval control job)

Use an Interval control job when defining a jobnet in which a job is executed after a specified wait time.

In the example below, an Interval control job is used to define a jobnet that executes a recovery job 10 minutes later if the succeeding job ends abnormally.

Figure 2‒83: Example of defining a jobnet that uses an Interval control job

If the preceding job ends abnormally, the next process is executed 10 minutes later. Therefore, use an Interval control job to monitor the time period. Set 10 minutes in Waiting time. Because the Interval control job will be executed at abnormal termination, set Recovery in the job Type. Likewise, set Recovery in Type for standard job C (the Interval control job's succeeding job).

With these settings, if standard job A ends abnormally, the Interval control job (recovery job) monitors the time until 10 minutes has passed, then standard job C (the succeeding job) is executed. If standard job A ends normally, standard job B is executed.

The Waiting time specified in an Interval control job refers to the wait time of the interval control process, not the time required to execute the Interval control job. Depending on the communication status or other factors, there might be a difference between the specified wait time and the actual interval.

To Page Top

(6) Passing information received by an event job

The event information received by an event job can be defined as a variable (macro variable) that is inherited by the succeeding unit. This inherited information is called passing information.

To pass event information to a succeeding unit, you must define a macro variable in the event job and specify the same macro variable name in the succeeding unit.

In the event job, specify the macro variable in the following form:

Macro variable definition

macro-variable-name:passing-information-name

For macro-variable-name, specify a character string of no more than 64 characters in the format ?AJS2xxxxx?. In xxxxx, you can use uppercase alphabetic characters (A to Z), numerals (0 to 9), and periods (.). In passing-information-name, you can specify only the passing information supported for the particular type of event job. For details, see B. Information Passed by Event Jobs.

At execution of a macro variable, the passed information is expanded in the command line on the target host that executes the succeeding unit of the event job. You should define a macro variable only if you are sure that the information to be passed is of a form that can be handled as a command argument when the succeeding job is executed.

For details on macro variables, see 2.2.6 Considerations regarding the use of macro variables.

The following explains how the information received by event jobs is passed to the various types of succeeding units.

To make event job information available to an entire jobnet, use a start condition. (For details on start conditions, see 3.4 Defining a start condition in the manual JP1/Automatic Job Management System 3 Overview.)

To Page Top