Hitachi

JP1 Version 13 JP1/Automatic Job Management System 3 Overview

3.1.1 Units

This section describes the various units.

Organization of this subsection

(1) Jobs

A job is the smallest of the units in an automated application. In JP1/AJS3, you define an application by arranging a number of processes in order of their execution. Each of these processes corresponds to a job.

Each job is arranged in execution sequence as shown in the following figure.

Figure 3‒3: Preceding job and succeeding job

[Figure]

In this example, job A is the preceding job, and job C is the succeeding job, of job B. For details on sequencing jobs, see 3.1.4 Creating a job flow.

You can set a hold attribute, a type, an execution service, a timeout period, information about the end delay monitoring of a job, an owner, a JP1 resource group, and an execution-user type. Hold attributes, types, execution services, timeout periods, and end delay monitoring are described below. For details about owners, JP1 resource groups, and execution-user types, see 7.2 Settings for restricting access to units.

Because there are many different types of jobs, you must sequence the jobs that you are defining according to the type of process required. JP1/AJS3 provides the following job types:

The characteristics of each type of job are described below.

(a) Standard job

For a standard job, you define an executable file and specify the host on which the job is to run. There are four types of standard jobs:

  • Unix job

  • PC job

  • QUEUE job

  • Flexible job

The following table outlines each standard job type and the processes (specifiable files) that you can define.

Table 3‒1: Standard jobs and definable processes

No.

Job type

Description

Definable processes

1

Unix job#1

Process executed on a UNIX host.

  • Executable file

  • Shell script

2

PC job#1

Process executed on a Windows host.

  • .exe file

  • .com file

  • .cmd file

  • .pif file

  • .bat file

  • .spt file#2 (script file created with JP1/Script)

  • Data file that has a file type (extension) associated with the application

3

QUEUE job

Process executed by submitting a job to a specified queue.

Used when linking with another system such as JP1/OJE.

  • Executable file

  • Shell script

  • .exe file

  • .com file

  • .cmd file

  • .pif file

  • .bat file

  • .spt file#2 (script file created with JP1/Script)

  • Data file that has a file type (extension) associated with the application

4

Flexible job#3

  • Process executed on an agent host that is not directly managed by the manager host.

  • Job broadcast to multiple execution agents.

  • Flexible jobs can be used to execute processing in a cloud environment. Load balancers are supported.

  • Executable file

  • Shell script

  • .exe file

  • .com file

  • .cmd file

  • .bat file

#1

For details on defining a jobnet that uses Unix jobs and PC jobs, see 2.4.1 Executing a process in a specified file (example of defining a jobnet consisting of standard jobs) in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

#2

To execute an .spt file, JP1/Script must also be installed on the host running the job.

#3

For details on defining a jobnet that uses flexible jobs, see 2.4.10 Executing jobs in a cloud environment (example of defining a jobnet that uses flexible jobs) in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide, and 2.4.11 Executing a job on multiple execution agents simultaneously (example of defining a jobnet that uses flexible jobs) in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

Cautionary note

You can define flexible jobs on any manager host regardless of its OS. However, for the execution host of flexible jobs, you can specify only manager or agent hosts that run on Windows or Linux.

(b) OR job

For an OR job, you define a number of jobs (event jobs and custom event jobs) which will monitor the system for a specific event. You define these event jobs and custom event jobs as the preceding jobs of the OR job. If any one of the monitored events occurs, the OR job executes its succeeding job. Only event jobs and custom event jobs can be defined as preceding jobs of an OR job.

The following figure shows an example of a jobnet containing an OR job.

Figure 3‒4: Example of a jobnet containing an OR job

[Figure]

When one of the defined event jobs or custom event jobs detects an event, that job terminates and the other event jobs or custom event jobs are set to Bypassed status. Event monitoring ends at this point.

For details on defining a jobnet that uses an OR job, see 2.4.2 Executing a process when one of multiple conditions is satisfied (example of defining a jobnet that uses an OR job) in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

(c) Judgment job

A judgment job checks whether a given condition is satisfied. A job that depends on the results of a judgment job is called a dependent job, and the results of a judgment determine whether a dependent job is executed. If there are two or more dependent jobs for a judgment job, define these jobs as a nested jobnet. A nested jobnet consisting of multiple dependent jobs is called a dependent jobnet. Dependent jobs and dependent jobnets are generically called dependent units. In a judgment job, you can set a condition for executing a dependent unit. If the condition is true, the dependent unit is executed, followed by the succeeding unit. If the condition is not true, the job executes the succeeding unit without executing the dependent unit, placing the dependent unit in Bypassed status. However, if the dependent unit ends abnormally, the succeeding unit is not executed.

The following figure shows an example of a jobnet that uses a judgment job.

Figure 3‒5: Jobnet example 1 (only one judgment job used)

[Figure]

You can also create a jobnet in which multiple judgment jobs run in parallel. If multiple judgment jobs evaluate to true, their dependent jobs are executed individually.

Figure 3‒6: Jobnet example 2 (multiple judgment jobs used)

[Figure]

Three judgment conditions can be used in a judgment job:

  • Judgment based on the return code of the preceding job

    Determine whether to execute the dependent unit by comparing the return code of the preceding job with a set judgment value.

    The following conditions can be set:

    • Return code > judgment value

    • Return code > judgment value

    • Return code < judgment value

    • Return code < judgment value

    • Return code = judgment value

    • Return code ≠ judgment value

    • Return code within judgment value range

    • Return code not within judgment value range

  • Judgment based on the presence of a file

    Determine whether to execute the dependent unit according to whether or not a specified file exists on the manager host.

    The following conditions can be set:

    • File exists

      Execute the dependent unit if the file exists.

    • File does not exist

      Execute the dependent unit if the file does not exist.

    If the specified file is a network file, judgment based on the presence of the file is possible only when the file satisfies the following conditions:

    In Windows:

    The file can be accessed with an address in UNC format by setting the JP1/AJS3 service account as the user account.

    In UNIX:

    The file can be accessed by mounting a file system (such as an NFS file system) via a network.

    Note, however, that if the network cannot be accessed, the system assumes that the file does not exist. In such cases, judgment based on file presence might not be performed correctly due to a communication error or similar problem.

    If you want to determine whether a network file that is not on the manager host is present, we recommend that in the preceding job, you define processing that will copy the file to the manager host if the file exists. This processing will allow the judgment job following the preceding job to correctly judge file presence.

  • Judgment based on variable comparison

    Determine whether to execute the dependent unit according to the information inherited from the root jobnet or preceding job.

    The passing information usable for judgments is as follows:

    • The passing information set in event jobs or custom event jobs

    • The passing information set with macro variable specified during registration for execution

    You can select whether the value is to be treated as a numeric value or character string, for the variable value inherited from the preceding job, and for the condition value to be evaluated by the judgment job.

    The conditions that can be set are as follows.

    When numeric is selected:

    • Is the variable value greater than the condition value?

    • Is the variable value equal to or greater than the condition value?

    • Is the variable value smaller than the condition value?

    • Is the variable value equal to or smaller than the condition value?

    • Is the variable value equal to the condition value?

    • Does the variable value differ from the condition value?

    • Is the variable value within the condition value range?

    • Is the variable value outside the condition value range?

    When string is selected:

    • Is the variable value equal to the condition value?

    • Does the variable value include the condition value?

    • Does the variable value differ from the condition value?

    • Is the condition value not contained within the variable value?

    • Is the variable value present?

    • Is the variable value absent?

When judgment is based on the return code of the preceding job, the judgment job requires a single preceding job and a single dependent unit.

When a jobnet is defined as the preceding unit, the judgment result is always the same because the jobnet's return value is treated as zero. This is why, for a judgment based on the return code, the preceding unit must be a job.

When the judgment is based on the presence of a file or on variable comparison, the preceding unit does not have to be a job. You can define a judgment job at the beginning of a jobnet, or a nested jobnet as the preceding unit. However, when a judgment job that uses a variable comparison is defined at the beginning of a jobnet, the judgment result will always be false in the following cases because there is no value to be judged:

  • When no macro variable was specified during registration for execution

  • When no macro variable has been defined in an event job or a custom event job that is used as a start condition for a jobnet

For details on defining a jobnet that uses a judgment job, see 2.4.3 Dynamically changing a process depending on the result of a preceding job (example of defining a jobnet that uses a judgment job) in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

(d) Event job

An event job monitors an event occurring in the system. You can define an event job as the start condition for a job flow or jobnet, so that the particular job or jobnet will be executed only when the monitored event occurs. For details on jobnet start conditions, see 3.4 Defining a start condition.

The following figure shows an example of a jobnet that uses an event job.

Figure 3‒7: Example of a jobnet that uses an event job

[Figure]

There are eight types of event jobs:

  • Receive JP1 event job

  • Monitoring files job

  • Receive mail job

  • Receive MQ message job

  • Receive MSMQ message job

  • Monitoring log files job

  • Monitoring event log job

  • Interval control job

The following table outlines each of these event jobs.

Table 3‒2: Types of event jobs

No.

Event job name

Description

1

Receive JP1 event job

This job terminates when it receives a specific event from JP1/Base.

2

Monitoring files job

This job terminates when a specific file is created, deleted, or updated.

3

Receive mail job

This job terminates when it receives a specific email.

4

Receive MQ message job#

This job terminates when it receives a specific message from MQSeries.

5

Receive MSMQ message job

This job terminates when it receives a specific message from MSMQ.

6

Monitoring log files job

This job is linked with the log file trapping of JP1/Base, and terminates when specific information is written to the specified log file.

7

Monitoring event log job

This job is linked with the log file trapping of JP1/Base, and terminates when specific information is written to the Windows event log file.

8

Interval control job

This job terminates when the specified time period elapses.
Note

JP1/AJS3 must be linked with the appropriate program to use a Receive mail job. For details, see the JP1/Automatic Job Management System 3 Linkage Guide.

#

Does not apply to Linux.

Operation of event jobs is independent of JP1 user permissions and the authority level defined for the job (by owner, JP1 resource group, or by the user executing the job). In Windows, because event job operation is governed by the account rights to the JP1/AJS3 service, JP1/AJS3 service rights must be set in advance.

For details on defining a jobnet that uses an event job, see 2.4.4 Executing an event-driven process (example of defining a jobnet that uses an event job and a custom event job) in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

The event information received by an event job can be defined as a variable (macro variable) inherited by the succeeding job. For details about macro variables, see 2.2.6 Considerations regarding the use of macro variables in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide. For details about passing event information via macro variables, see 2.4.4(6) Passing information received by an event job and a custom event job in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

(e) Action job

An action job executes a specific process. You can combine an action job with an event job or a custom event job to execute a process (action) when an event occurs. Typical actions might be to send a JP1 event, an email message, or a status notification.

The following figure shows an example of a jobnet that uses an action job.

Figure 3‒8: Example of a jobnet that uses an action job

[Figure]

There are seven types of action jobs:

  • Send JP1 event job

  • Send mail job

  • Send MQ message job

  • Send MSMQ message job

  • OpenView Status Report job

  • Local power control job

  • Remote power control job

The following table outlines each of these action jobs.

Table 3‒3: Types of action jobs

No.

Action job name

Description

1

Send JP1 event job

Sends a JP1 event to the event service of JP1/Base.

2

Send mail job

Sends an email message.

3

Send MQ message job#

Sends a message to MQSeries.

4

Send MSMQ message job

Sends a message to MSMQ.

5

OpenView Status Report job

Sends a status to HP NNM.

6

Local power control job

Powers on/off or restarts the host on which the local power control job was executed, working in conjunction with JP1/Power Monitor.

7

Remote power control job

Powers on a remote host or shuts down a system on the network, working in conjunction with JP1/Power Monitor.
Note

JP1/AJS3 must be linked with the appropriate program to use a Send mail job, OpenView Status Report job, Local power control job, or Remote power control job. For details on program linkage, see the JP1/Automatic Job Management System 3 Linkage Guide.

#

Does not apply to Linux.

For details about defining a jobnet that uses an action job, see 2.4.5 Sending a JP1 event at completion of the preceding job or when an event occurs (example of defining a jobnet that uses a Send JP1 event job) in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

(f) Custom job

A custom job defines a process that is executed in conjunction with JP1/AJS3 by a program other than JP1/AJS3. By using the custom job registration facility in JP1/AJS3 - View, you can define the non-JP1/AJS3 process as a job in JP1/AJS3, represented as a custom job icon.

Several types of standard custom jobs are provided as standard in JP1/AJS3, to enable linkage with the Windows version of the JP1 series.

Standard custom jobs are listed below.

Table 3‒4: Standard custom jobs

No.

Custom job name

Works with

Custom job functions

1

JP1FTP

JP1/FTP

Transfers files in linkage with JP1/FTP.

2

JP1AMR3, JP1AMR3UX

JP1/AJS3 for Enterprise Applications

Works in conjunction with JP1/AJS3 for Enterprise Applications to automatically execute the background jobs of the SAP system.

3

JP1AMR3BW, JP1AMR3BWUX

JP1/AJS3 for Enterprise Applications

Works in conjunction with JP1/AJS3 for Enterprise Applications to execute the Info Package of a BW system.

4

JP1AMR3CP, JP1AMR3CPUX

JP1/AJS3 for Enterprise Applications

Works in conjunction with JP1/AJS3 for Enterprise Applications to copy the background jobs of the SAP system.

5

ADSHPC, ADSHUX, ADSHAPPEXEC

JP1/Advanced Shell

Works in conjunction with JP1/Advanced Shell to execute the script file of JP1/Advanced Shell.

6

DHAJEW

JP1/DH - AJE

Works in conjunction with JP1/DH - AJE to exchange data with JP1/DH - Server.

7

CPALINK

JP1/CPA

Works in conjunction with JP1/CPA to start a job that is registered in JP1/CPA.

In addition to these standard custom jobs, you can create a custom PC job or custom Unix job by redefining the icon of a PC job or Unix job.

Setup is required to use custom jobs in JP1/AJS3. For details, see 3. Adding Custom Jobs in the JP1/Automatic Job Management System 3 Linkage Guide.

(g) Passing information setting job

A passing information setting job is used between a preceding job and a succeeding job. After the preceding job has output information to the standard output file, the passing information setting job extracts the necessary information from the file, and passes it to the succeeding job. This mechanism allows a succeeding job to receive dynamically changing information that cannot be known when the job is defined from the standard output file of the preceding job.

A passing information setting job uses macro variables to pass information to the succeeding job. For details about macro variables, see 2.2.6 Considerations regarding the use of macro variables in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

The following figure shows an example of a jobnet that uses a passing information setting job.

Figure 3‒9: Example of a jobnet that uses a passing information setting job

[Figure]

For details about defining a jobnet that uses a passing information setting job, see 2.4.9 Passing information that changes dynamically to a succeeding unit (example of defining a jobnet that uses a passing information setting job) in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

Note that the unit type of passing information setting jobs is standard custom job.

(h) HTTP connection job

HTTP connection jobs are jobs that send requests and receive responses via the HTTP protocol. For example, by using an HTTP connection job, you can call the REST API or another web API that is available on a cloud or web server in JP1/AJS3. In other words, HTTP connection jobs allow linkage between a JP1/AJS3-based business system and a business system on the web.

The following figure shows an example of a jobnet that uses an HTTP connection job.

Figure 3‒10: Example of a jobnet that uses an HTTP connection job

[Figure]

For details about defining a jobnet that uses an HTTP connection job, see 2.4.12 Linking with a business system on the web (example of defining a jobnet that uses HTTP connection jobs) in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

Cautionary note

You can define HTTP connection jobs on any manager host regardless of its OS. However, for the execution host of HTTP connection jobs, you can specify only manager or agent hosts that run on Windows or Linux.

(i) Custom event job

A custom event job has the functionality of both an event job and custom job. A custom event job links with a non-JP1/AJS3 program to monitor occurrence of events. In the same way as an ordinary event job, by defining a custom event job in a job flow or as a jobnet start condition, the job or jobnet can be started when a specific event occurs. For details on jobnet start conditions, see 3.4 Defining a start condition.

The function of a custom event job differs depending on the program with which the job links. For details about the function, see the applicable manual of the program.

For details on defining a jobnet that uses a custom event job, see 2.4.4 Executing an event-driven process (example of defining a jobnet that uses an event job and a custom event job) in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

The event information received by a custom event job can be defined as a variable (macro variable) inherited by the succeeding job. For details about macro variables, see 2.2.6 Considerations regarding the use of macro variables in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide. For details about passing event information via macro variables, see 2.4.4(6) Passing information received by an event job and a custom event job in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

To Page Top

(2) Jobnets

A jobnet is a collection of ordered jobs. The top-level jobnet is called the root jobnet and the jobnets defined below the root jobnet are known as a nested jobnet.

In JP1/AJS3, automated applications are executed by root jobnet. Therefore, in each root jobnet, the information necessary for scheduling executions needs to be defined. For details about schedule information, see 3.3 Defining a schedule.

When schedule information has been defined for a root jobnet, all lower units are scheduled according to that information. If some processes require a different execution schedule from the other processes defined in a jobnet, you can group those processes into a nested jobnet and define a separate schedule for the nested jobnet. For details on scheduling a nested jobnet, see 3.5.3 Defining a different schedule for some jobs in a jobnet in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

For a root jobnet, you can also set the following scheduling-related information:

#

Can also be set for a nested jobnet.

The number of logs to keep, priority, timeout period, jobnet monitoring, hold, and type are explained below. For details about concurrent execution and the schedule option, see 3.3.3 Concurrent execution and schedule option in this manual. For details about execution order control, see 2.2.4 Using jobnet connectors to control the order of root jobnet execution in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

Note:

You can set None for the priority of a job or of a jobnet. If None is set, you can specify a default priority to be used for each scheduler service. For details, see 20.4.2(108) DEFAULTPRIORITY in the JP1/Automatic Job Management System 3 Configuration Guide.

#1

There are three levels of priority in Windows. The job processes are started according to one of the following three priority classes.

  • With priority setting 1 or 2, the processes are executed when the system is idle.

    (The Windows setting IDLE_PRIORITY_CLASS applies.)

  • With priority setting 3, the processes are executed as normal processes.

    (The Windows setting NORMAL_PRIORITY_CLASS applies.)

  • With priority setting 4 or 5, the processes are executed before any process threads that were assigned priority 1, 2, or 3.

    (The Windows setting HIGH_PRIORITY_CLASS applies.)

#2

In UNIX, JP1/AJS3 service's nice value used when jajs_spmd command is executed is used as the default (base) nice value. When the JP1/AJS3 service's nice value has not been set, 20 is assumed as the nice value.

For example, when the priority setting is 1 and the nice value is 20, the priority value is calculated as shown below.

39 [Figure] 20 (default) + 20 (increment)

If the resulting value is not within the possible nice value range (0-39), the maximum value is 39 and the minimum value is 0.

If Queueless Agent is selected as the execution service, you can set only 39, 30, 20, 10, or 0 as a nice value, according to the job execution priority; 0 corresponds to the highest execution priority. When you change the nice value, you must specify the job execution priority corresponding to the nice value.

For the jajs_spmd command syntax, see jajs_spmd in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

To Page Top

(3) Jobnet connector

A jobnet connector is a unit that controls the execution sequence of root jobnets. It has the following two functions:

The following figure illustrates how a jobnet connector can be used.

Figure 3‒11: Functions of a jobnet connector

[Figure]

A jobnet connector can be defined as a unit in a jobnet. It is used to control the execution sequence of a root jobnet that is defined directly under a root jobnet or under a planning group.

For details about jobnet connectors, see 2.2.4 Using jobnet connectors to control the order of root jobnet execution in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

To Page Top

(4) Job group

A job group is a unit for sorting and grouping jobnets so that they can be managed systematically. A job group can be created under another job group.

The following figure illustrates the job group concept.

Figure 3‒12: Job group

[Figure]

In a job group, you can define calendar information for JP1/AJS3 operation (open/closed days, base day/time, and so on). For details on calendar information, see 3.2 Defining a calendar for JP1/AJS3 operation.

Note that job groups are jobnet management units and cannot be executed in their own right.

To Page Top

(5) Planning group

In JP1/AJS3, you can automatically switch execution from one jobnet (root jobnet) to another by specifying an execution period for each jobnet. A planning group is a unit that provides for this type of system operation.

The following figure shows an example of using a planning group.

Figure 3‒13: Example of using a planning group

[Figure]

Suppose that you want to execute jobnet A from August 1 to August 5, and jobnet B from August 6 to August 10. First, you would create a planning group, and then create jobnets A and B directly under it. Execute the two jobnets, specifying the execution periods as August 1-5 for jobnet A, and August 6-10 for jobnet B. Execution will automatically switch from one jobnet to the other without interruption.

For details on planned jobnet switching using a planning group, see 11.1 Using a planning group to change the plans for root jobnets.

You can create a planning group immediately below the scheduler service (AJSROOT) or under a job group. Only root jobnets and remote jobnets can be created in a planning group.

You can also define JP1/AJS3 calendar information for a planning group. For details on calendar information, see 3.2 Defining a calendar for JP1/AJS3 operation.

To Page Top

Copyright (C) 2023, 2024, Hitachi, Ltd.

Copyright (C) 2023, 2024, Hitachi Solutions, Ltd.