Job Management Partner 1/Automatic Job Management System 3 Overview

3.1.1 Units

This section describes the various units.

Organization of this subsection

(1) Jobs

(2) Jobnets

(3) Jobnet connector

(4) Job group

(5) Planning group

(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

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.3 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 8.2 Settings for restricting access to units.

• Hold
  By setting this attribute, you can hold a job so that it will not be executed until its held status is released.
  
• Type
  You can specify whether to use a unit as a recovery unit. Select either Normal or Recovery as the unit type. The default is Normal.
  A job whose type is set to Recovery is called a recovery job and is executed if a preceding unit has terminated abnormally. A jobnet whose type is set to Recovery is called a recovery jobnet. Recovery jobs and recovery jobnets are collectively called recovery units.
  
• Execution service
  You can specify a service on which the job is to be executed. Specify either Standard or Queueless Agent. The default is Standard. For a queueless job, usually use Standard for the execution service. If Queueless Agent is specified, an execution agent or execution agent group cannot be used.
  For details about execution agents, see 5. Job Execution Environments. For details about queueless jobs, see 10.5 Queueless jobs.
  
• Timeout period
  By setting a timeout period, you can cancel execution based on the elapsed time since the job began execution. For example, if you set a timeout period of 10 minutes, the job will be canceled if it has not ended 10 minutes after it started. Set the timeout period in the range 1 to 1,440 (minutes).
  
• End delay monitoring
  By setting the time required to run a job, you can monitor for end delays based on the elapsed time since the job began execution. Set the time required for execution in the range 1 to 1,440 (minutes). For example, if you set a time required for execution of 10 minutes, an end delay will be detected if the job has not ended 10 minutes after it started. On detection of an end delay, the job is placed in Running (end-delay) status. When the job terminates, its status becomes Ended normally (end-delay) or other status as appropriate. Message KAVS0248-I is output on detection of a delay. For the message text, see 2.2 Messages beginning with KAVS (Messages about the scheduler) in the manual Job Management Partner 1/Automatic Job Management System 3 Messages 1. For the output destination and the output conditions, see 1.3(2) Output destinations of messages beginning with KAVS in the manual Job Management Partner 1/Automatic Job Management System 3 Messages 1.
  End delay monitoring cannot be specified for OR jobs or judgment jobs.
  For details about monitoring end delays in job execution, see 5.1(3) End delay monitoring based on time-required-for-execution in the Job Management Partner 1/Automatic Job Management System 3 System Design (Work Tasks) Guide.
  

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:

• Standard job
• OR job
• Judgment job
• Event job
• Action job
• Custom job

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 three types of standard jobs:

• Unix job
• PC job
• QUEUE 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	Process executed on a UNIX host.	Executable file Shell script
2	PC job	Process executed on a Windows host.	.exe file .com file .cmd file .pif file .bat file .spt file# (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/NQSEXEC or JP1/OJE.	Executable file Shell script .exe file .com file .cmd file .pif file .bat file .spt file# (script file created with JP1/Script) Data file that has a file type (extension) associated with the application

#

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

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

(b) OR job

For an OR job, you define a number of jobs (event jobs) which will monitor the system for a specific event. You define these 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 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

When one of the defined event jobs detects an event, that job terminates and the other 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 Job Management Partner 1/Automatic Job Management System 3 System Design (Work Tasks) Guide

(c) Judgment job

A judgment job checks whether a given condition is satisfied. A dependent job of a judgment job is called a dependent job, and the results of the judgment determine whether the dependent job is executed. In a judgment job, you can set a condition for executing a dependent job. If the condition is true, the dependent job is executed, followed by the succeeding job. If the condition is false, the succeeding job runs without execution of the dependent job. However, if the dependent job ends abnormally, the succeeding job is not executed.

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

Figure 3-5 Example of a jobnet that uses a judgment job

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 job 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
• Judgment based on the presence of a file
  Determine whether to execute the dependent job according to whether or not a specified file exists on the manager host.
  The following conditions can be set:
  
  • File exists
    Execute the dependent job if the file exists.
    
  • File does not exist
    Execute the dependent job if the file does not exist.
    
  When you specify a network file, the file is assumed to be non-existent if access to the network is not possible.
  
• Judgment based on variable comparison
  Determine whether to execute the dependent job 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
  • The passing information set with macro variable values 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?
  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 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 subordinate 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 value was specified during registration for execution
• When no macro variable has been defined in an 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 Job Management Partner 1/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-6 Example of a jobnet that uses an event job

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 TP1/Message Queue or 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 Job Management Partner 1/Automatic Job Management System 3 Linkage Guide.

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) in the Job Management Partner 1/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 on passing event information, see 2.4.4(6) Passing information received by an event job in the Job Management Partner 1/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 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-7 Example of a jobnet that uses an action job

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 TP1/Message Queue or 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 Job Management Partner 1/Automatic Job Management System 3 Linkage Guide.

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 Job Management Partner 1/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	JP1/AJS3 for Enterprise Applications	Works in conjunction with JP1/AJS3 for Enterprise Applications to automatically execute the background jobs of an R/3 (R) system.
3	JP1AMR3BW	JP1/AJS3 for Enterprise Applications	Works in conjunction with JP1/AJS3 for Enterprise Applications to execute the Info Package of a BW system.
4	JP1AMOAP	JP1/AJS2 for Oracle E-Business Suite	Works in conjunction with JP1/AJS2 for Oracle E-Business Suit to automatically execute the requests of an Oracle E-Business Suite system.

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 Job Management Partner 1/Automatic Job Management System 3 Linkage Guide.

(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. Thus, in the root jobnet, you must define the information required to schedule the jobnets for execution in JP1/AJS3. 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. However, you can set schedule information separately for a specific nested jobnet. For example, 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 Job Management Partner 1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

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

• Concurrent executions
• Number of logs to keep
• Priority^#
• Timeout period
• Schedule option
• Jobnet monitoring
• Execution sequence control

#

Can also be set for a nested jobnet.

The number of logs to keep, priority, timeout period, and jobnet monitoring 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 Job Management Partner 1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

• Number of logs to keep
  When a jobnet is defined and automated (registered for execution) in JP1/AJS3, it is managed as an object with a specific execution schedule, based on its schedule information. This object is called a jobnet generation. For details about generations, see 4.2 Managing jobnet generations.
  Number of logs to keep is a setting that specifies how many generations of execution results to save. The setting applies only to a root jobnet. Once you set the number of logs to keep, you can view the execution results for the set number of generations (root jobnet executions) in the Daily Schedule window or Monthly Schedule window. Alternatively, you can view past execution results by running the ajsshow command. For the command syntax, see ajsshow in 2. Commands in the manual Job Management Partner 1/Automatic Job Management System 3 Command Reference 1.
  As the number of logs to keep, you can set any number from 1 to 99. However, the extended feature for this setting supports a maximum of 999 generations, depending on the environment settings for the Manager's scheduler service. For details about setting the Manager's scheduler service environment, see the MAXSAVEGEN environment variable in 2.2 Setting up the scheduler service environment in the Job Management Partner 1/Automatic Job Management System 3 Configuration Guide 2.
  Past execution results are automatically deleted when they exceed the number of generations set in the number of logs to keep. For example, if you set 1, you will only be able to check the results of the latest run, even if the jobnet executes two or more times a day. Therefore, for a jobnet that is executed several times a day depending on the start conditions, you need to set a sufficient number of generations. For details on the number of logs to keep, see 4.2.3 Jobnet generation management.
  
• Priority
  You can set a process priority for jobs executed in a jobnet. The priority set for the root jobnet is handled as the default for all lower jobs and nested jobnets. Alternatively, you can set a separate priority for a specific standard job or for a specific nested jobnet.
  The following table shows the correspondences between priority settings in JP1/AJS3 and their meaning in Windows and UNIX.
  

  Table 3-5 Priority settings and their meaning in Windows and UNIX

  Priority	Execution priority in Windows#1	Execution priority in UNIX#2
  1	Lower than interactive processing	JP1/AJS3 service's nice value +20
  2		JP1/AJS3 service's nice value +10
  3	Same as interactive processing	JP1/AJS3 service's nice value
  4	Higher than interactive processing	JP1/AJS3 service's nice value -10
  5		JP1/AJS3 service's nice value -20

#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 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 2. Commands in the manual Job Management Partner 1/Automatic Job Management System 3 Command Reference 1.

• Timeout period
  Once registered, a root jobnet is placed in Waiting for start time status until execution begins. The timeout period specifies how long after the base time on the scheduled start day to cancel the root jobnet's Waiting for start time status if it fails to start at the scheduled start time because the scheduler service is inactive or a hold setting is in effect. When the Waiting for start time status is cancelled, the jobnet is placed in Skipped so not executed status. The following timeout settings are supported:
  
  • Use system settings
  • 1 day
  • 2 days
  • Unlimited
  If you set a timeout period of 1 day or 2 days, the Waiting to execute or Being held status will be canceled when 1 or 2 days have elapsed from the base time on the scheduled start day. The jobnet will then be placed in Skipped so not executed status.
  When the root jobnet is defined in a 48-hour time format in the schedule definition, and its scheduled start time is the next day, the timeout period will be taken as 2 days even is specified as 1 day.
  The default is Use system settings. This means that the value set in the environment variable EXECDEFER (by default, oneday) will apply.
  
• Jobnet monitoring
  By setting the time required for execution for a jobnet, you can monitor for end delays based on how much time has passed since the jobnet started execution. For example, if you set 30 minutes as the time required for execution, an end delay will be detected if the jobnet has not terminated 30 minutes after it started. Set the time required for execution in the range 1 to 2,879 (minutes).
  

  Cautionary note

  Jobnet monitoring is not supported if you are using version 06-71 or earlier of JP1/AJS2 - View or JP1/AJS2 - Manager.

(3) Jobnet connector

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

• Waits for the preceding root jobnet to end
  The jobnet connector waits for the root jobnet to terminate normally. If it terminates abnormally, the root jobnet enters Running + Abend status and waits without ending.
  
• Synchronizes execution of the associated root jobnet with its own startup process (optional function)
  When the jobnet connector starts, it activates the associated root jobnet.
  

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

Figure 3-8 Functions of a jobnet connector

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 Job Management Partner 1/Automatic Job Management System 3 System Design (Work Tasks) Guide.

(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-9 Job group

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.

(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-10 Example of using a planning group

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 10.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.

[Contents][Back][Next]

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