To define a job, enter values for the fields on the General tab.
To define a job, you must give it a name and description, and assign an application, an agent, program information, and execution options. In order for a job to execute a program or run a process flow, you must define its program information (a library, program type, and program name). You enter program information on the General tab of the Jobs window.
For a job to execute a program, you must provide information about the program on the General tab of the Jobs window shown below. This information tells Applications Manager where to find the program the job will run and how to run it. Fields marked with an '*' to the right are required.
To define a job, enter values for the fields on the General tab.
You can define certain objects by clicking the icon to the right of their field. Applications Manager will display the selector window where you can define the new object. For example, you can click the Application icon to display the Application selector window.
Entering Job Header Information
All values in the job header are required. They are described in the table below:
| Field | Description |
|---|---|
|
Name |
The name may be up to 30 characters long. Job names can include letters, numbers, periods, colons, underscores, and hyphens. The first letter of a job name must be a letter or number. Do not name jobs 'SCHED-<process flow name>', unless they are process flow requestor jobs. |
|
Description |
The description may be up to 100 characters long. |
|
Applications are the general category to which jobs and process flows belong (for example: inventory, accounts payable). They are used on the Requests window to limit the list of jobs and process flows. For more information on defining applications, see Defining Applications. |
|
|
Agent/Group |
The agent where the program will execute. This field allows you to select agents and agent groups. To run the job on:
For information on which agents are assigned to what groups, or which agent groups are multi-execution, see your Applications Manager administrator. When agent groups are assigned to jobs, particular agents may be specified for process flows, process flow components, requests, or in schedules. For more information, see How Agent Assignments Are Handled for Process Flow Components. |
|
The job will run on this queue even when added to the process flow, unless the Insert components into process flow's queue automation engine option is set. For more information on setting automation engine options, see the Administration Guide. If the job is run using a schedule and that schedule includes a queue, that setting overrides the job's queue. If the job is submitted on an ad hoc basis, the user may have the option to change the queue on the Submit window. |
|
|
When selected, two instances of the job cannot run concurrently. The second instance will show a status of SELF WAIT until the first completes.. |
|
|
When selected, the job will run when scheduled or included in another process flow and be available from the Request window. If not selected, the job will not run when scheduled or included in another process flow, and it cannot be run from the Requests window. |
|
|
When selected, the aborted job remains in the Backlog so it can be examined, repaired, and reset. The queue is not blocked by this aborted job, unless the queue has only one thread and the Allow aborted task to block single threaded queue automation engine option is checked. When this option is not checked, and the job aborts and leaves the Backlog, it will satisfy any Success predecessors it may have with other tasks. Failure and Failure (skip on success) predecessors will not be satisfied. If this option is not selected and the job aborts, it leaves the Backlog and a record is written to History. The job may be examined from History to determine why it aborted, but because there is no longer a record in the Backlog, it cannot be repaired or reset. When this option is selected, and the Restart once on abort option is not selected, and the job aborts, you will see the original Run ID <run_id> in History and the current listing <run_id>.01 in the Backlog. This setting can be overridden with a condition. This is most commonly done for process flow components. |
Entering Program Information
In order for a job to execute a program or run a process flow, you must define its program information in the Program box on the General tab. Jobs created for some Applications Manager extensions such as OAE and PeopleSoft may have different fields in their Program box than what is shown in the image above for standard jobs. For more information, see your Applications Manager extension documentation.
The Program fields for standard jobs are described in the table below:
| Field | Description |
|---|---|
|
The path to the program source or executable. The program type defined in the Type field may supply a subpath. For information on defining libraries, see Defining Libraries. |
|
|
Library path |
This non edit field displays the path of the library selected in the Library field. |
|
This defines which type of program the job will run, such as shell scripts, host command, or SQL*Plus. Applications Manager comes with several program types already defined. For more information on defining program types, see Defining Program Types. |
|
|
The name of the program that will be executed by the job. Program names can be typed into this field, or selected based on the job's agent, library, and program type using the Select button. When you click the Select button, Applications Manager displays a list of valid file names in the path defined by the agent, library, and program type. If you use the Select button for a job assigned to an agent group, you will be able to search for the file on the agent you select. If you type in a program name, Applications Manager does not verify that it exists. |
|
|
Location |
As you enter the program information, Applications Manager displays the path and file name in this non-editable field. |