Chapter 30: Maintaining Highly-Available Environments

Chapter 30: Maintaining Highly-Available Environments 

How to Maintain Highly-Available Environments 

As an operator, it is your responsibility to monitor the environment and address 

problems that occur. In highly-available environments, scheduler and database failures 

adversely affect, and sometimes disable, high-availability. You can ensure that you 

maintain a properly functioning highly-available environment by resolving database and 

scheduler failures. 

In highly-available cluster environments, use the monitoring tools provided by your 

cluster management software and database vendor to monitor the state of the cluster 

and the state of the database. We recommend that you also monitor the scheduler log 

on the active node. When your cluster or clustered database is not functioning properly, 

consult the documentation for your cluster management software or your database 

vendor and follow the instructions to restore the environment. 

In high-availability and dual event server modes, monitor the scheduler logs for 

database and scheduler failures and take appropriate action to return to 

high-availability mode when failures occur. 

Note: For more information about monitoring tools provided by your cluster 

management software and database vendor, see the documentation for those products. 

 How to Maintain Highly-Available Environments

The following diagram demonstrates how you can maintain a highly-available 

environment: 

Follow these steps: 

1. Monitor the scheduler log ( . 

2. Restore the failed scheduler. 

■ On UNIX    

■ On Windows 

3. Recover the failed database. 

■ On UNIX   

■ On Windows   

 How to Maintain Highly-Available Environments 

Chapter 29: Monitoring and Reporting on Workflow

Chapter 29: Monitoring and Reporting on Workflow 

Monitoring Tools 

Monitoring workflow helps you to identify problems with the current or predicted 

workflow, so that you can resolve those problems. You can use the following CA 

Workload Automation AE tools to monitor workflow: 

Forecast Reports 

Generate reports that display information about the predicted workflow to identify 

problems before they occur. 

Note: You can also use forecast reports to plan changes to your workflow in a test 

environment. 

Monitors 

Track events to identify problems as they occur. 

Browsers 

Generate reports that display information about past events to identify recurring 

problems. 

You can solve problems before they occur or as they occur when you can identify the 

issue that is associated with the problem. When you cannot determine the cause of a 

problem, notify the administrator. 

To solve a problem that you identify in real time using a monitor, correct the associated 

issue and restart the job. To address recurring problems or problems with predicted 

workflow that you identify using browsers and forecast reports, correct the associated 

issues and use monitors to track the progress of the workflow. 

Correcting issues that cause jobs to fail requires modifying workflow objects (job 

definitions, machine definitions, and calendar object definitions). You can modify 

workflow objects only when you have write access to those objects. When you cannot 

solve a problem without modifying a workflow object and you do not have write access 

to the problematic object, notify the scheduler. 

Important! Modifying workflow objects sometimes has unexpected impacts on the rest 

of the workflow. We recommend that you plan changes to the workflow in a test 

environment before you implement the changes in the live instance.

Chapter 28: Cross-Instance Scheduling

Chapter 28: Cross-Instance Scheduling

Bi-Directional Scheduling 
CA Workload Automation AE supports bi-directional scheduling, which lets you start jobs
from remote machines (inbound) or submit jobs on remote machines (outbound).
With inbound job scheduling, CA Workload Automation AE acts as an agent and accepts
job submissions from remote machines or other scheduling managers (such as CA
Jobtrac Job Management and CA Workload Automation SE). The jobs are defined and
run on the CA Workload Automation AE instance that is acting as an agent.
With outbound job scheduling, CA Workload Automation AE acts as a scheduling
manager and sends job submissions to remote machines. The jobs are defined on the CA
Workload Automation AE instance that is acting as a scheduling manager. The jobs run
on the remote machine or other scheduling manager.
 CA Workload Automation AE Cross-Instance Job Dependencies




For example, a Linux Oracle instance can initiate jobs in a Windows Microsoft SQL Server
instance, or a Windows Microsoft SQL Server instance can initiate jobs in a Solaris
Oracle instance. You can add additional instances, such as Solaris Sybase, AIX Oracle, or
HP Oracle instance, to the environment.
The CA Workload Automation AE cross-platform interface controls the bi-directional
scheduling mode. You can configure the cross-platform interface to enable the following
modes:
■ Outbound job scheduling
■ Inbound and outbound job scheduling (bi-directional scheduling)
■ No cross-platform scheduling (the default)
Note: There are no restrictions on platforms, event servers, or number of instances
when running in bi-directional scheduling mode.

Chapter 27: Working with Binary Large Objects (Blobs)

Chapter 27: Working with Binary Large Objects (Blobs) 

Binary Large Objects 

Binary Large Objects (blobs) are binary data of variable length. CA Workload Automation 

AE supports blobs in job definitions, and after they are defined, they are stored in the 

database. This allows the blob data to be shared by jobs running on multiple computers. 

To understand the advantages of using blobs in CA Workload Automation AE 

environment, refer to the following example, which explains the process that is used to 

share data amongst the jobs that are running on a single computer: 

1. When the jobs are running on a single computer, you can define a command job to 

run a program that outputs the data to a file using the std_out_file attribute. 

2. When the job is completed, a file is created in the location specified by the 

std_out_file attribute. 

3. All the other jobs that depend on this output data can access this file. 

4. You can also define a second command job to run a program that reads the output 

data of the previous job, by specifying the file name in the std_in_file attribute. 

5. This second command job opens the file specified by the std_in_file attribute and 

passes the data to the program, allowing it to complete successfully. 

Based on this example, as the output data is stored in a file on one computer, it is not 

available to all the other jobs that are scheduled to run on other computers. However, 

the use of blobs allows the data that is saved as output by a job on one computer to be 

shared by all the other jobs that are running across multiple computers. 

Also, you can define a command job to run a program that uploads the output data to 

the database as a blob using the std_out_file attribute. You can also define a second 

command job to run a program that reads the blob data of the previous job using the 

std_in_file attribute. The second command job downloads the blob data specified by 

the std_in_file attribute from the database and passes the data to the program, allowing 

it to complete successfully. 

 Types of Blobs 

Blob data can be of the following types: 

Binary Data 

Requires a program that understands the format of the data to interpret the bytes 

in binary data. For example: 

Multimedia files which include the following: 

■ Images 

■ Video files 

■ Audio files

Chapter 26: Working with Resources

Chapter 26: Working with Resources 

Real Resources 

Real resources are system conditions that are directly tied to a physical system (for 

example, physical memory). Real resources are predefined to CA Workload Automation 

AE and are managed by external resource managers such as CA Automation Suite for 

Data Centers. You cannot define or update real resources using CA Workload 

Automation AE. If the required resources are not available, the job goes into a RESWAIT 

state and is not submitted until the resources are available. 

You can specify real resources as dependencies to jobs. A job with resource 

dependencies is submitted only when the resources required are available. If the 

required resources are not available, the job goes into a RESWAIT state and is not 

submitted until the resources are available. 

You can specify the following supported real resource types as dependencies: 

CPU_IDLE_PCT 

Defines the percentage of time over the sample period that the system's CPUs were 

idle. 

Example: (CPU_IDLE_PCT, VALUE=50, VALUEOP=GT) indicates that the system's 

CPUs were idle for at least 50% of the sample period. 

Corresponding metric in the CA SystemEDGE agent: cpuTotalIdlePercent 

 Real Resources 

CPU_LOAD_AVG_15MIN 

Defines the load average in the last 15 minutes. 

Example: (CPU_LOAD_AVG_15MIN, VALUE=50, VALUEOP=LT) indicates that the 

load average was less than 50 in the last 15 minutes. 

Corresponding metric in the CA SystemEDGE agent: loadAverage15Min 

CPU_LOAD_AVG_5MIN 

Defines the load average in the last 5 minutes. 

Example: (CPU_LOAD_AVG_5MIN, VALUE=50, VALUEOP=LT) indicates that the load 

average was less than 50 in hte last 5 minutes. 

Corresponding metric in the CA SystemEDGE agent: loadAverage5Min 

MEM_INUSE_PCT 

Defines the percentage of the system’s active memory that is in use. 

Example: (MEM_INUSE_PCT, VALUE=30, VALUEOP=LTE) indicates that 30% or less 

of the system's active memory is in use.

Chapter 25: Working with User-defined Job Types

Chapter 25: Working with User-defined Job Types

User-Defined Job Types 
CA Workload Automation AE lets you define simple user-defined jobs. A user-defined
job type is similar to a command job except that each user-defined job type is
associated with a custom program/script/adaptor. For example, a new job type can be
defined to perform FTP. For this to work, a custom program/script/adaptor has to be
provided which does FTP by taking a few arguments. Jobs using the user-defined job
type may optionally specify arguments to the command defined in the user-defined job
type. For example, if we define FTP job type as '2', a custom program, script, or adaptor
must be provided as part of the definition of type 2.
insert_job_type: 2
command: /home/scripts/myftp
When jobs of type 2 are defined, all of them execute /home/scripts/myftp when those
jobs are run.
insert_job: ftp_test
job_type: 2
machine: localhost
std_in_file: /tmp/ftp_params
When a new version of FTP script is used, only the definition of job type has to be
modified.
You can use the following jil commands to create, update, and delete user-defined job
types.
■ insert_job_type
■ delete_job_type
■ update_job_type
 User-Defined Job Types

Chapter 24: z/OS Jobs

Chapter 24: z/OS Jobs 

z/OS Jobs 

You can use z/OS jobs to run mainframe workload. 

Note: To run these jobs, your system requires CA WA Agent for z/OS. 

CA WA Agent for z/OS submits and tracks the z/OS jobs. You can define the following 

three types of z/OS jobs: 

z/OS Regular 

Schedules z/OS jobs. 

z/OS Manual 

Creates dependencies on z/OS jobs that are submitted outside of the scheduling 

manager. 

z/OS Data Set Trigger 

Creates dependencies on data set activities. You can customize trigger conditions to 

define the conditions in which the z/OS Data Set Trigger job completes. You can 

specify trigger conditions for the following data set activities: 

■ When a data set is created or updated 

■ When a specific job, group of jobs, or user ID creates a data set 

■ When an explicit data set notification is received (used when the data set 

activity does not generate an SMF record) 

■ When an FTP file is sent or received successfully 

Note: Each data set must have its own individual z/OS Data Set Trigger job. To 

create dependencies on multiple data sets, you must create multiple z/OS Data Set 

Trigger jobs. 

Define a z/OS Data Set Trigger Job 

You can define a z/OS Data Set Trigger job to create dependencies on data set activities. 

Note: To run these jobs, your system requires CA WA Agent for z/OS. 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: ZOSDST 

Specifies that the job type is z/OS Data Set Trigger. 

machine 

Specifies the name of the machine on which the job runs. 

zos_dataset 

Specifies the Job Control Language (JCL) library name. The JCL library or JCLLIB 

contains the JCL for the z/OS job. The JCLLIB is a z/OS data set name. 

2. (Optional) Specify optional z/OS Data Set Trigger attributes: 

■ zos_dsn_renamed 

■ zos_dsn_updated 

■ zos_explicit_dsn 

■ zos_ftp_direction 

■ zos_ftp_host 

■ zos_ftp_userid 

■ zos_trigger_by 

■ zos_trigger_on 

■ zos_trigger_type

Chapter 23: Web Services Jobs

Chapter 23: Web Services Jobs 

Web Service Jobs 

The term web service describes a standardized method for exchanging data between 

applications and systems. Web services use XML to code and decode the data and 

Simple Object Access Protocol (SOAP) to transfer it. 

Web Service Description Language (WSDL) is an XML-based language that describes a 

web service and how to access it. A WSDL document specifies the location of the service 

and the operations the service exposes. 

Universal Description, Discovery and Integration (UDDI) is an XML-based registry for 

businesses to list their available web services on the Internet. You can use the UDDI to 

access the WSDL. 

Web services provide access to applications written in Java and Microsoft©

.NET. A web 

service lets you invoke operations such as currency conversion, stock exchange quotes, 

or product pricing. In an enterprise workload automation environment, a web service 

might be used to invoke a business process such as posting accounts payable to the 

General Ledger. Some scheduling manager functions are also available as web services. 

The following are the web service job types: 

Web Service RPC/Encoded 

Lets you call an operation within a web service and pass parameters to the 

operation using RPC/encoded style binding. The parameters can be actual values or 

a serialized Java object passed by another job. 

Web Service Document/Literal 

Lets you call an operation within a web service and pass parameters to the 

operation using document/literal style binding. The parameters represent a 

flattened view of the XML document the agent constructs. The values passed into 

the XML document can be literal values or a serialized Java object passed by 

another job. 

Chapter 22: Wake on LAN Jobs

Chapter 22: Wake on LAN Jobs

Wake on LAN Jobs 
You can save energy using the agent's Wake on LAN (WOL) feature to automate the
startup and shutdown of your computers. WOL lets you define and schedule WOL jobs
to send a signal to a server to turn it on. When the server is no longer needed, you can
schedule a different command job to power it down.
Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or
Windows. Your agent administrator must configure the agent to support WOL. For more
information about configuring the agent to support WOL, see the CA Workload
Automation Agent for UNIX, Linux, or Windows Implementation Guide.
Wake on LAN (WOL) is a hardware and software solution that lets you wake up a
computer remotely. The solution requires an ACPI-compliant computer and a special
software program that sends a signal to the computer's network card to wake it up. The
agent provides the AMD magic packet to broadcast the signal to a computer that has
been soft-powered-down (ACPI D3-warm state).

Define a Wake on LAN Job 
You can define a Wake on LAN (WOL) job to send a signal to a server to turn it on. The
job can wake up a remote computer that has been soft-powered-down (ACPI D3-warm
state).
Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or
Windows. Your agent administrator must configure the agent to support WOL. For more
information about configuring the agent to support WOL, see the CA Workload
Automation Agent for UNIX, Linux, or Windows Implementation Guide.

Chapter 21: SNMP Jobs

Chapter 21: SNMP Jobs 

SNMP Jobs 

The agent supports a built-in SNMP manager capability. You can enable the agent to act 

as an SNMP manager to emit and listen for SNMP traps in addition to its other roles. The 

agent supports SNMP v1, v2, and v3. After the agent is configured, you can define and 

run SNMP job types on the agent. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or 

Windows. 

You can define the following types of SNMP jobs: 

■ Simple Network Management Protocol Value Get (SNMPGET) 

■ Simple Network Management Protocol Value Set (SNMPSET) 

The SNMP Value Get job queries a network device for the value of a variable that is 

assigned to a Management Information Base (MIB) address. You can use the SNMP 

Value Get job to retrieve information about a network device to determine whether an 

administrator is required to be notified. 

The SNMP Value Set job modifies a variable on a network device. The variable is 

assigned to the MIB address that you specify. You can use the SNMP Value Set job to 

update a variable that reports on the failure or success of a mission-critical policy. 

Define an SNMP Value Get Job 

You can define a Simple Network Management Protocol Value Get (SNMPGET) job to 

retrieve the value of an SNMP variable. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or 

Windows. Your agent administrator must configure the agent as an SNMP manager. For 

more information about configuring the agent as an SNMP manager, see the CA 

Workload Automation Agent for UNIX, Linux, or Windows Implementation Guide. 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: SNMPGET 

Specifies that the job type is SNMP Value Get. 

machine 

Chapter 20: Secure Copy Jobs

Chapter 20: Secure Copy Jobs

Secure Copy Jobs 
You can define a Secure Copy job to transfer binary files between an agent computer
and a remote computer. The Secure Copy job can upload data to or download data from
a remote server. The data is encrypted during the transfer. By default, a Secure Copy job
uses the SFTP protocol. However, you can define the job to use the SCP protocol.
Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, Windows,
or i5/OS. The agent must be configured as an FTP client using the Secure Copy Protocol
or the Secure File Transfer Protocol.

Define a Secure Copy Job 
You can define a Secure Copy (SCP) job to transfer binary files using the Secure Copy
Protocol.
Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, Windows,
or i5/OS.

Follow these steps: 
1. Insert a job and specify the following attributes in the definition:
job_type: SCP 
Specifies that the job type is Secure Copy.
machine
Specifies the name of the machine on which the job runs.
scp_local_name 
Specifies a file on the agent computer to be downloaded or uploaded.




scp_remote_dir 
Specifies the file's remote source directory (if downloading) or the file's remote
destination directory (if uploading).
scp_remote_name 
Specifies the file's source location (if downloading) or the file's destination (if
uploading).
scp_server_name 
Specifies a remote server name.
2. (Optional) Specify optional Secure Copy attributes:
■ job_class
■ scp_local_user
■ scp_protocol
■ scp_server_port
■ scp_target_os
■ scp_transfer_direction

Chapter 19: SAP Jobs

Chapter 19: SAP Jobs

SAP Jobs 
SAP jobs let you run SAP workload.
Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows
and CA WA Agent for SAP.
You can define the following SAP jobs:
SAP Batch Input Session
Imports data from external systems to the SAP system.
SAP Business Warehouse (BW) InfoPackage
Transfers data from a data source to an SAP Business Warehouse system.
SAP Business Warehouse (BW) Process Chain
Creates Process Chains on the SAP system.
 SAP Connection Attributes


SAP Data Archiving 
Stores information in an SAP Archiving Object.
SAP Event Monitor
Monitors and triggers SAP events.
SAP Job Copy
Copies an existing SAP R/3 job.

SAP Process Monitor 
Monitors for a specific SAP process status.
SAP R/3
Schedules an SAP R/3 job on your SAP system.

SAP Connection Attributes 
The following connection attributes are common to SAP job types and may be required
in your job definitions:
sap_rfc_dest 
Specifies the SAP system to connect to. This value corresponds to the
destination@properties agent configuration file name containing the SAP
connection information. The sap_rfc_dest value overrides the
sap.default.destination configuration value in the agentparm.txt file.

Chapter 18: Remote Execution Jobs

Chapter 18: Remote Execution Jobs

Remote Execution Jobs 
Remote Execution jobs let you execute commands to a remote UNIX, HP Integrity
NonStop, or OpenVMS computer through Secure Shell (SSH2) or Telnet.
Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows
and CA WA Agent for Remote Execution. The CA WA Agent for Remote Execution
supports only remote target environments of UNIX, HP Integrity NonStop, and
OpenVMS.

Define a Remote Execution Job 
You can define a Remote Execution (PROXY) job to run commands to a remote UNIX, HP
Integrity NonStop, or OpenVMS computer through Telnet or Secure Shell (SSH2).
Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows
and CA WA Agent for Remote Execution. The CA WA Agent for Remote Execution
supports only remote target environments of UNIX, HP Integrity NonStop, and
OpenVMS.
With the CA WA Agent for Remote Execution, you can define and run remote execution
jobs.

Follow these steps: 
1. Insert a job and specify the following attributes in the definition:
job_type: PROXY 
Specifies that the job type is Remote Execution.

machine 
Specifies the name of the machine on which the job runs.

remote_command 
Specifies a command or script to run on a remote computer.



remote_target 
Specifies the name of the custom properties (remote_target.properties) file
that is created on the agent for the remote system. The file contains the
default user credentials that are used to monitor all jobs run on the target
machine by the agent. The name should not include the .properties extension.

2. (Optional) Specify optional Remote Execution attributes:
■ envvars
■ fail_codes
■ job_class
■ spool_file
■ submit_modifier
■ success_codes

3. (Optional) Specify the following attribute:
owner
Specifies the user ID that the job runs under. This value overrides the default
owner of the job.
Default: The user ID who invokes jil to define the job
4. (Optional) Specify common attributes that apply to all jobs.
The Remote Execution job is defined.

Notes:
■ Attributes that have a default value automatically apply to the job definitions;
therefore, they are optional. For example, jobs with no specified job type are
defined as command jobs by default. Other optional attributes specify information
that is not required but affects how or when a job runs, such as attributes that
specify scheduling conditions.
■ Some optional attributes are common to all job types but others apply to certain
jobs types only. Optional attributes that apply to all job types are known as
common optional attributes. For more information about common optional
attributes and the values that you can specify for them (including their default
values when applicable), see the Reference Guide.
■ For information about required attributes and job type specific optional attributes,
see the procedure topics that provide instructions for defining jobs.
■ This guide provides instructions for defining jobs interactively. You also create job
definitions in script files and then import them using the jil command or use CA
WCC to define them. For more information about the JIL command and JIL syntax,
see the Reference Guide. For more information about using CA WCC to define the
job, see the CA Workload Control Center Workload Scheduling Guide.
 Attributes with Default Values

Chapter 18: Remote Execution Jobs 417

Example: Execute the list command on a remote machine
Suppose you want to list the contents of /opt on the remote agent machine.
insert_job: proxy_job
job_type: PROXY
machine:agentmachine
owner: root@remoteagent
remote_target: remoteagent
spool_file: /opt/spool/commandout.out
remote_command: ls /opt
Attributes with Default Values
Attributes that have a default value automatically apply to the job definition. Therefore,
you do not have to specify those attributes in the definition. Default values for some
attributes can be defined on the agent in the custom properties file for the remote
system. If you specify the attribute in the job definition, it overrides the default value
defined on the agent. For more information about possible default values, see the
syntax and notes for the attributes you are using.
If you specify the attribute in a job definition, it overrides the default.

The following Remote Execution job attributes have default values:
fail_codes
Defines which exit codes indicate job failure.
Default: Any exit code other than 0 (The job interprets any code other than zero as
failure.)

spool_file
Specifies the path to the spool file.
Default: spoolHome custom property

owner
Specifies the user ID that the job runs under.
Default: The default owner (the user ID who invokes jil to define the job)

success_codes
Defines which exit codes indicate job success.
Default: 0 (The job interprets zero as success.)
Note: For more information about JIL job types and other job definition attributes, the
values that you can specify for those attributes, and JIL syntax, see the Reference Guide.

 Attributes with Default Values

418 User Guide

Example: Override the Default Path to the Spool File
This example overrides the default path to the spool file specified in the custom
properties file for the remote system.
insert_job: ls_cmd
job_type: PROXY
machine: proxyagent
remote_target: hpserver
remote_command: ls
spool_file: >>/home/user1/test/ls.out

Chapter 17: Process Automation Jobs

Chapter 17: Process Automation Jobs

Process Automation Jobs 
Process Automation jobs let you launch CA Process Automation processes and monitor
them to completion.
Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows
and CA WA Agent for Web Services.
You can define the following Process Automation jobs:
Process Automation Process Execution
Lets you directly execute a CA Process Automation process.
Process Automation Start Request Form
Lets you submit a Start Request Form to execute a CA Process Automation process.
The Start Request Form sets the values for the current execution of the process.


Define a Process Automation Process Execution Job 
You can define a Process Automation Process Execution job to execute a CA Process
Automation process.
Follow these steps: 
1. Insert a job and specify the following attributes in the definition:
job_type: PAPROC 
Specifies that the job type is Process Automation Process Execution.
machine 
Specifies the name of the machine on which the job runs.
endpoint_URL 
Specifies the target endpoint address URL in a Web Service or Process
Automation job.
pa_name 
Specifies the fully qualified name of the process or Start Request Form in a
Process Automation job.

2. (Optional) Specify optional Process Automation Process Execution attributes.
■ job_class
■ job_terminator
■ owner
■ pa_monitor_progress
■ pa_parameter
■ pa_trace
3. (Optional) Specify common attributes that apply to all jobs.
The Process Automation Process Execution job is defined.
 Define a Process Automation Start Request Form Job


Notes:
■ Attributes that have a default value automatically apply to the job definitions;
therefore, they are optional. For example, jobs with no specified job type are
defined as command jobs by default. Other optional attributes specify information
that is not required but affects how or when a job runs, such as attributes that
specify scheduling conditions.
■ Some optional attributes are common to all job types but others apply to certain
jobs types only. Optional attributes that apply to all job types are known as
common optional attributes. For more information about common optional
attributes and the values that you can specify for them (including their default
values when applicable), see the Reference Guide.
■ For information about required attributes and job type specific optional attributes,
see the procedure topics that provide instructions for defining jobs.
■ This guide provides instructions for defining jobs interactively. You also create job
definitions in script files and then import them using the jil command or use CA
WCC to define them. For more information about the JIL command and JIL syntax,
see the Reference Guide. For more information about using CA WCC to define the
job, see the CA Workload Control Center Workload Scheduling Guide.

Example: Execute a CA Process Automation Process
This example executes a CA Process Automation process named /CAWAAE/Test Process
using the agent on the localhost machine and connecting to a CA Process Automation
installation on capamach.It uses the credentials from pamadmin@capamach to
authenticate on the Process Automation installation and passes values for the process
variable named strTestName. It will monitor the process until the process completes
and report success or failure at that time.
insert_job: execproc
job_type: PAPROC
machine: localhost
endpoint_URL: "http://capamach:8080/itpam/soap"
pa_name: "/CAWAAE/Test Process"
owner: pamadmin@capamach
pa_monitor_progress: Y
pa_parameter: param_name="strTestName", param_value="PA Test"
Define a Process Automation Start Request Form Job
You can define a Process Automation Start Request Form job to submit a Start Request
Form to execute a CA Process Automation process. The Start Request Form sets the
values for the current execution of the process.
. Define a Process Automation Start Request Form Job


Follow these steps: 
1. Insert a job and specify the following attributes in the definition:
job_type: PAREQ
Specifies that the job type is Process Automation Start Request Form.
machine
Specifies the name of the machine on which the job runs.
endpoint_URL
Specifies the target endpoint address URL in a Web Service or Process
Automation job.
pa_name
Specifies the fully qualified name of the process or Start Request Form in a
Process Automation job.
pa_path
Specifies the path of the Start Request Form.
Note: The path specified must end in a / character.

2. (Optional) Specify optional Process Automation Start Request Form attributes.
■ job_class
■ owner
■ pa_monitor_progress
■ pa_parameter
■ pa_trace
3. (Optional) Specify common attributes that apply to all jobs.
The Process Automation Start Request Form job is defined.
 Attributes with Default Values


Notes:
■ Attributes that have a default value automatically apply to the job definitions;
therefore, they are optional. For example, jobs with no specified job type are
defined as command jobs by default. Other optional attributes specify information
that is not required but affects how or when a job runs, such as attributes that
specify scheduling conditions.
■ Some optional attributes are common to all job types but others apply to certain
jobs types only. Optional attributes that apply to all job types are known as
common optional attributes. For more information about common optional
attributes and the values that you can specify for them (including their default
values when applicable), see the Reference Guide.
■ For information about required attributes and job type specific optional attributes,
see the procedure topics that provide instructions for defining jobs.
■ This guide provides instructions for defining jobs interactively. You also create job
definitions in script files and then import them using the jil command or use CA
WCC to define them. For more information about the JIL command and JIL syntax,
see the Reference Guide. For more information about using CA WCC to define the
job, see the CA Workload Control Center Workload Scheduling Guide.

Example: Submit a Start Request Form
This example submits a Start Request Form named Process A in the /CAWAE/ path. It
uses the credentials of the pamadmin@capamach user to authenticate the user on the
Process Automation installation on capamach.The Start Request Form has a field called
strTestName that will be populated with the value "PA Test" before the form is
submitted. The process will be tracked to completion.
insert_job: runsrf
job_type: PAREQ
machine: localhost
endpoint_URL: "http://capamach:8080/itpam/soap"
pa_name: "Process A"
pa_path: /CAWAAE/
owner: pamadmin@capamach
pa_monitor_progress: Y
pa_parameter: param_name="strTestName", param_value="PA Test"
Attributes with Default Values
Attributes that have a default value automatically apply to the job definition. Therefore,
you do not have to specify those attributes in the definition. Your agent administrator
can define some default values on the agent in the agentparm.txt file.
If you specify the attribute in a job definition, it overrides the default.
 Attributes with Default Values


The following Process Automation job attributes have default values:
owner
Specifies the Process Automation user. These credentials will be validated on the
Process Automation server.
Default: The user who invokes JIL to define the job
pa_monitor_progress
 Indicates whether the process is tracked to completion.
Default: Y; the process is tracked to completion.
pa_trace
Indicates whether a trace of SOAP messages is written to the spool file.
Default: N (A trace of SOAP messages is not written to the spool file.)
Note: For more information about JIL job types and other job definition attributes, the
values that you can specify for those attributes, and JIL syntax, see the Reference Guide.

Example: Track a Process Automation Process to Completion
The pa_monitor_progress attribute in the following job definition overrides the default
value.
insert_job: pam1
job_type: PAPROC
endpoint_url: "http://canor01-vm2k3c:8080/itpam/soap"
machine: paagent
owner: pamadmin@capamach
pa_name: "/ITPAM Tutorials/S01 Getting started/L01 Creating a Simple Process/L01-2
Running the Process/Running the Process"
pa_monitor_progress: Y
pa_trace: N

Chapter 16: PeopleSoft Jobs

Chapter 16: PeopleSoft Jobs

PeopleSoft Jobs 
PeopleSoft jobs let you run different types of PeopleSoft processes defined in your
PeopleSoft system. For example, you can define PeopleSoft jobs to execute PeopleSoft
programs and report the program status.
Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows
and CA WA Agent for PeopleSoft.
When you define a PeopleSoft job, you can set the output type and format of a report.
For email and web output types, you can set various distribution properties such as the
recipients and message text. You can also pass run control parameter values that will be
stored in the corresponding run control table.
 PeopleSoft Exit Codes


When a PeopleSoft program runs, it modifies its run status (RUNSTATUS) in the
PSPRCSRQST table in the PS database. The following diagram shows the functional
relationship between the scheduling manager, the agent, and the PeopleSoft system:


PeopleSoft Exit Codes 
A PeopleSoft (PS) job can return exit codes 9 and 17, which indicate success. When a PS
job terminates with either of these exit codes, CA Workload Automation AE changes the
status of the job to SUCCESS and logs the non-zero exit code.

PeopleSoft User IDs and Passwords 
The operator ID sets the authority for running PeopleSoft reports. Your agent
administrator can set defaults for an operator ID and corresponding password using the
ps.default.oprId and ps.default.oprPassword parameters in the agentparm.txt. You can
override the default operator ID by specifying the ps_operator_id attribute in a
PeopleSoft job definition. The ps_operator_id must be defined on CA Workload
Automation AE using the autosys_secure command unless the
ps.skipOprPswdValidation=true parameter is configured in the agentparm.txt file.
Note: For more information about the autosys_secure command, see the Reference
Guide.
 Define a PeopleSoft Job


Define a PeopleSoft Job 
You can define a PeopleSoft (PS) job to schedule workload to run in PeopleSoft. The job
runs a PeopleSoft process request or a collection of process requests.
Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows
and CA WA Agent for PeopleSoft.
Follow these steps:
1. Insert a job and specify the following attributes in the definition:
job_type: PS
Specifies that the job type is PeopleSoft.
machine
Specifies the name of the machine on which the job runs.
ps_process_name
Specifies the name of the PeopleSoft report to run. This value corresponds to
the Process Name field in PeopleSoft.
ps_process_type
Specifies the type of PeopleSoft report that you want the job to run.
2. Do one of the following:
■ Ensure that a default run control ID is defined in the agent's agentparm.txt file
using the ps.default.runCntlId parameter.
■ Add the following attribute to the definition:
ps_run_cntrl_id
Specifies the value assigned to the run control identifier. This value
corresponds to the Run Control ID field in PeopleSoft.
 Note: This attribute overrides the ps.default.runCntlId agent parameter.
3. (Optional) Specify optional PeopleSoft attributes:
■ envvars
■ job_class
■ job_terminator
■ ps_args
■ ps_dest_format
■ ps_dest_type
■ ps_detail_folder
 Define a PeopleSoft Job

398 User Guide

■ ps_dlist_roles
■ ps_dlist_users
■ ps_email_address
■ ps_email_address_expanded
■ ps_email_log
■ ps_email_subject
■ ps_email_text
■ ps_email_web_report
■ ps_operator_id
■ ps_output_dest
■ ps_restarts
■ ps_run_cntrl_args
■ ps_run_control_table
■ ps_server_name
■ ps_skip_parm_updates
■ ps_time_zone
Note: A PeopleSoft job must have a valid operator ID to run successfully. Check with
your agent administrator to determine whether a default operator ID is set on the
agent. If a default is not set, you must specify this attribute.
4. (Optional) Specify common attributes that apply to all jobs.
The PeopleSoft job is defined.
Notes:
■ Attributes that have a default value automatically apply to the job definitions;
therefore, they are optional. For example, jobs with no specified job type are
defined as command jobs by default. Other optional attributes specify information
that is not required but affects how or when a job runs, such as attributes that
specify scheduling conditions.
■ Some optional attributes are common to all job types but others apply to certain
jobs types only. Optional attributes that apply to all job types are known as
common optional attributes. For more information about common optional
attributes and the values that you can specify for them (including their default
values when applicable), see the Reference Guide.
■ For information about required attributes and job type specific optional attributes,
see the procedure topics that provide instructions for defining jobs. Attributes with Default Values

Chapter 16: PeopleSoft Jobs 399

■ This guide provides instructions for defining jobs interactively. You also create job
definitions in script files and then import them using the jil command or use CA
WCC to define them. For more information about the JIL command and JIL syntax,
see the Reference Guide. For more information about using CA WCC to define the
job, see the CA Workload Control Center Workload Scheduling Guide.

Example: Run a PeopleSoft Process
This example runs an Application Engine process named DDDAUDIT. The job runs on the
agent named psagt.
insert_job: ps_txtfile
job_type: ps
machine: psagt
ps_process_name: DDDAUDIT
ps_process_type: Application Engine
Note: The job uses the default operator ID, output destination format, output
destination type, and run control ID defined on the agent. The PeopleSoft Server that
runs the job is not defined in the job definition or as a default on the agent, so the
PeopleSoft Process Scheduler determines the PeopleSoft Server that will run the job.

Attributes with Default Values
Attributes that have a default value automatically apply to the job definition. Therefore,
you do not have to specify those attributes in the definition. Your agent administrator
can define some default values on the agent in the agentparm.txt file.
If you specify the attribute in a job definition, it overrides the default.

The following PeopleSoft job attributes have default values:
ps_dest_format
Specifies the type of format for the report output.
Default: ps.default.outDestFormat agent parameter, if specified
ps_dest_type
Specifies the output destination type for the PeopleSoft report.
Default: ps.default.outDestType agent parameter, if specified
 Attributes with Default Values

400 User Guide

ps_email_log
Specifies whether to email job logs with the PeopleSoft report to recipients on a
distribution list.
Default: No (Job logs are not emailed to recipients.)
ps_email_web_report
Specifies whether to email a web report to recipients on a distribution list.
Default: No (A web report is not emailed to recipients.)

ps_operator_id
Specifies the operator ID under whose authority the PeopleSoft reports run.
Default: ps.default.oprId agent parameter, if specified
ps_output_dest
Specifies the output destination for the PeopleSoft request. The destination can be
a file directory or a printer.
Default: If ps_dest_type is PRINTER, the default is one of the following, in the
following order:
■ ps.default.printer parameter in the agent's agentparm.txt file, if specified
■ The default PeopleSoft printer, lpt1

ps_restarts
Specifies whether to disable a restart feature for previously failed jobs from the
point where the job failed.
Default: No (The restart feature is not disabled.)
ps_run_cntrl_id
Specifies a set of PeopleSoft run parameters for a given PeopleSoft process.
Default: ps.default.runCntlId agent parameter, if specified
Note: All PeopleSoft jobs require a run control ID. If you do not specify this attribute
in the job definition, a default run control ID must be defined in the
ps.default.runCntlId parameter in the agent's agentparm.txt file. Otherwise, the job
fails.
 Mapping of PeopleSoft Fields to Job Attributes

Chapter 16: PeopleSoft Jobs 401

ps_server_name
Specifies the target server that runs the PeopleSoft job.
Default: ps.default.serverName
Note: If the PeopleSoft Server is not specified as a default on the agent or in the job
definition, the PeopleSoft Process Scheduler determines the PeopleSoft Server that
will run the job.
ps_skip_parm_updates
Specifies whether you want the agent to update job parameters with data in the
PS_PRCSDEFN table.
Default: NO (The agent updates job parameters with data in the PS_PRCSDEFN
table.)
Note: For more information about JIL job types and other job definition attributes, the
values that you can specify for those attributes, and JIL syntax, see the Reference Guide.

Example: Specify a Run Control ID and a Server Name
This example overrides the default run control ID using the ps_run_cntrl_id attribute
and server name using the ps_server_name attribute. The job uses the Application
Engine process type. The job uses the default output destination format and type
defined on the agent. The job overrides the default operator ID using the
ps_operator_id attribute.
insert_job: ps_cst
job_type: ps
machine: psagt
ps_process_name: PAYROLL
ps_server_name: PSPR
ps_process_type: Application Engine
ps_run_cntrl_id: PS_ALL
ps_operator_id: vp1@ps1
Mapping of PeopleSoft Fields to Job Attributes
When you define a PeopleSoft job, you specify JIL attributes that map to your
PeopleSoft process request. The following table maps the PeopleSoft fields to the
attributes:

PeopleSoft Field Name Attribute Name
Format ps_dest_format
Type ps_dest_type Mapping of PeopleSoft Fields to Job Attributes

402 User Guide

PeopleSoft Field Name Attribute Name
Folder Name ps_detail_folder
ID Type (Role selected)
Distribution ID
ps_dlist_roles
ID Type (User selected)
Distribution ID
ps_dlist_users
Email Address List ps_email_address
Email With Log ps_email_log
Email Subject ps_email_subject
Message Text ps_email_text
Email Web Report ps_email_web_report
Output Destination ps_output_dest
Process Name ps_process_name
Process Type ps_process_type
Run Control Arguments ps_run_cntrl_args
Run Control ID ps_run_cntrl_id
Run Control Table ps_run_control_table
Server Name ps_server_name
Time Zone ps_time_zone
 Distribute a PeopleSoft Report

Chapter 16: PeopleSoft Jobs 403

Distribute a PeopleSoft Report
If you specify EMAIL as the output destination type (ps_dest_type), you can distribute a
PeopleSoft report electronically to operators, groups of people, or individuals.
Follow these steps:
1. Define a PeopleSoft job (see page 397).
2. Add the following attributes to the job definition:
ps_dest_type: EMAIL
Sends the output of the PeopleSoft report as an email message. This attribute
corresponds to the Type field in PeopleSoft.
ps_dest_format
Specifies the field name of the output destination format. PeopleSoft stores the
list of output destination formats in the PSXLATITEM table. This value
corresponds to the Format field in PeopleSoft.

3. Add one or both of the following attributes:
ps_dlist_roles
Specifies a distribution list of the roles that represent the individuals who are
receiving the PeopleSoft report. This value corresponds to the ID Type field
(with Role selected) and the Distribution ID field in PeopleSoft.
ps_dlist_users
Specifies a distribution list of operator IDs to send a PeopleSoft report to. This
value corresponds to the ID Type field (with User selected) and the Distribution
ID field in PeopleSoft.

4. (Optional) Add the following attributes:
ps_email_address
Specifies the email addresses of the recipients on a distribution list. This value
corresponds to the Email Address List field in PeopleSoft.
ps_email_subject
Defines an email subject to include in the email. This value corresponds to the
Email Subject field in PeopleSoft.
ps_email_text
Defines the body text of the email. This value corresponds to the Message Text
field in PeopleSoft.
 Distribute a PeopleSoft Report

404 User Guide

5. Run the job.
The PeopleSoft report is sent to the specified distribution lists and email addresses.
Note: For more information about JIL job types and other job definition attributes, the
values that you can specify for those attributes, and JIL syntax, see the Reference Guide.
Example: Distribute a Report to Users
This example runs a Crystal report under the VP3 operator ID. The report is formatted as
PDF and distributed in an email to the VP1, VP2, and VP3 operator IDs.
insert_job: ps_users
job_type: PS
machine: psagt
ps_process_name: XRFWIN
ps_process_type: Crystal
ps_dest_type: EMAIL
ps_dest_format: PDF
ps_dlist_users: VP1,VP2,VP3
ps_operator_id: VP3@ps1
ps_run_cntrl_id: test
Example: Email a PeopleSoft Report
This example runs a Crystal report and emails the output to recipients. The Crystal
report runs under the VP2 operator ID. The output is sent to the email addresses
specified in the ps_email_address attribute. The email includes a subject title.
insert_job: ps_email
job_type: PS
machine: psagt
ps_process_name: XRFWIN
ps_process_type: Crystal
ps_dest_type: EMAIL
ps_dest_format: PDF
ps_operator_id: VP2@ps1
ps_email_address: user1@example.com;user2@example.com
ps_email_subject: PeopleSoft Report Status
ps_email_text: This report is available for distribution. Store the Output of a PeopleSoft Job as a Web Report

Chapter 16: PeopleSoft Jobs 405

Store the Output of a PeopleSoft Job as a Web Report
You can define a PeopleSoft job to run a process and store the output as a web report to
view later. You can also define the job to email the web report to one or more
recipients.
Follow these steps:
1. Define a PeopleSoft job (see page 397).
2. Add the following attributes to the job definition:
ps_dest_type: WEB
Posts the output of the PeopleSoft report on a website. This attribute
corresponds to the Type field in PeopleSoft.

ps_dest_format
Specifies the field name of the output destination format. PeopleSoft stores the
list of output destination formats in the PSXLATITEM table. This value
corresponds to the Format field in PeopleSoft.

3. (Optional) Add the following attributes:
ps_email_web_report: YES
Specifies that the job emails a web report to the recipients on the distribution
list. This attribute corresponds to the Email Web Report field in PeopleSoft.


ps_email_address
Specifies the email addresses of the recipients on a distribution list. This value
corresponds to the Email Address List field in PeopleSoft.

ps_email_subject
Defines an email subject to include in the email. This value corresponds to the
Email Subject field in PeopleSoft.

ps_email_text
Defines the body text of the email. This value corresponds to the Message Text
field in PeopleSoft.

4. Run the job.
The output of the PeopleSoft job is stored as a web report. The job emails the web
report to recipients if the email attributes are specified.
Note: For more information about JIL job types and other job definition attributes, the
values that you can specify for those attributes, and JIL syntax, see the Reference Guide.
 Store the Output of a PeopleSoft Job as a Web Report

406 User Guide

Example: Format a PeopleSoft Job Output as an HTML Web Report
This example runs the XRFWIN process. The process type is SQR Report and the run
control ID is PS_ALL. The server named PSPR runs the job, and the output is stored as an
HTML web report.
insert_job: ps_htmfile
job_type: ps
machine: psagt
ps_process_name: XRFWIN
ps_process_type: SQR Report
ps_server_name: PSPR
ps_dest_type: WEB
ps_dest_format: HTM
ps_run_cntrl_id: PS_ALL
Example: Distribute a PeopleSoft Web Report in an Email
This example stores the output as a PDF web report. The web report is sent to the email
addresses specified in the ps_email_address attribute. The email includes a subject title
and body text.
insert_job: ps_web
job_type: PS
machine: psagt
ps_process_name: XRFWIN
ps_process_type: Crystal
ps_dest_type: WEB
ps_dest_format: PDF
ps_operator_id: VP2@ps1
ps_email_web_report: YES
ps_email_address: user1@example.com;user2@example.com
ps_email_subject: PeopleSoft Report Status
ps_email_text: This report is available for distribution. Send the Output of a PeopleSoft Job to a Printer

Chapter 16: PeopleSoft Jobs 407

Send the Output of a PeopleSoft Job to a Printer
You can define a PeopleSoft job to run a process and send the output to a printer.
Follow these steps:
1. Define a PeopleSoft job (see page 397).
2. Add the following attributes to the job definition:
ps_dest_type: PRINTER
Sends the output of the PeopleSoft report to a printer. This attribute
corresponds to the Type field in PeopleSoft.
ps_output_dest
Specifies the network location of the printer including the printer server and
shared printer name. This value corresponds to the Output Destination field in
PeopleSoft.

3. Run the job.
The output of the PeopleSoft job is sent to a printer.
Note: For more information about JIL job types and other job definition attributes, the
values that you can specify for those attributes, and JIL syntax, see the Reference Guide.

Example: Send a Job's Output to a Specified Printer
This example runs an SQR Report. The report is formatted as PS and outputted to a
printer.
insert_job: ps_printer
job_type: ps
machine: psagent
ps_process_name: XRFWIN
ps_process_type: SQR Report
ps_dest_type: PRINTER
ps_dest_format: PS
ps_output_dest: \\printers\PRINTER1
ps_run_cntrl_id: test
ps_operator_id: VP1@ps1

Chapter 15: Oracle E-Business Suite Jobs

Chapter 15: Oracle E-Business Suite Jobs 

Oracle E-Business Suite Jobs 

You can define jobs to run Oracle E-Business Suite workload. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Oracle E-Business Suite. 

You can define the following Oracle E-Business Suite jobs: 

Copy Single Request Job 

Copies an existing single request defined on Oracle Applications and runs it under 

the agent. 

Request Set Job 

Runs multiple programs in an Oracle Applications application. 

Single Request Job 

Runs a single program in an Oracle Applications application. 

Define an Oracle E-Business Suite Copy Single Request Job 

You can define an Oracle E-Business Suite Copy Single Request (OACOPY) job to copy an 

existing single request defined on Oracle E-Business Suite and run it under the agent. 

When the job runs, it can override values in the original definition with values specified 

on the agent or in the job definition. The OACOPY job is useful when you want to reuse 

existing job definitions. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Oracle E-Business Suite. 

 Define an Oracle E-Business Suite Copy Single Request Job 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: OACOPY 

Specifies that the job type is Oracle E-Business Suite Copy Single Request. 

machine 

Specifies the name of the machine on which the job runs. 

request_id 

Specifies the request ID of the Oracle E-Business Suite request you want to 

copy. 

2. Do one of the following: 

■ Ensure that a default Oracle E-Business Suite user name and responsibility 

name are defined in the agent's agentparm.txt file using the oa.default.user 

and oa.default.responsibility parameters, respectively. 

■ Add the following attributes to the definition: 

oracle_user 

Specifies the Oracle E-Business Suite user name that the job runs under. 

 Note: This attribute overrides the oa.default.user agent parameter. 

oracle_resp 

Specifies an Oracle E-Business Suite responsibility name. 

 Note: This attribute overrides the oa.default.responsibility agent 

parameter. 

 Define an Oracle E-Business Suite Copy Single Request Job 

Chapter 15: Oracle E-Business Suite Jobs 379 

3. (Optional) Specify optional Oracle E-Business Suite Copy Single Request attributes: 

■ job_class 

■ job_terminator 

■ oracle_custom_property 

■ oracle_mon_children 

■ oracle_mon_children_delay 

■ oracle_notify_display_users 

■ oracle_notify_users 

■ oracle_output_format 

■ oracle_quote_in_default 

■ oracle_template_language 

■ oracle_template_territory 

4. (Optional) Specify common attributes that apply to all jobs. 

The Oracle E-Business Suite Copy Single Request job is defined. 

Notes: 

■ Attributes that have a default value automatically apply to the job definitions; 

therefore, they are optional. For example, jobs with no specified job type are 

defined as command jobs by default. Other optional attributes specify information 

that is not required but affects how or when a job runs, such as attributes that 

specify scheduling conditions. 

■ Some optional attributes are common to all job types but others apply to certain 

jobs types only. Optional attributes that apply to all job types are known as 

common optional attributes. For more information about common optional 

attributes and the values that you can specify for them (including their default 

values when applicable), see the Reference Guide. 

■ For information about required attributes and job type specific optional attributes, 

see the procedure topics that provide instructions for defining jobs. 

■ This guide provides instructions for defining jobs interactively. You also create job 

definitions in script files and then import them using the jil command or use CA 

WCC to define them. For more information about the JIL command and JIL syntax, 

see the Reference Guide. For more information about using CA WCC to define the 

job, see the CA Workload Control Center Workload Scheduling Guide. 

 Define an Oracle E-Business Suite Request Set Job 

380 User Guide 

Example: Copy a Single Request 

Suppose that you want to copy an existing single request defined on Oracle E-Business 

Suite. In this example, the job copies the single request job with request ID 2255470 and 

overrides the Oracle E-Business Suite user name and responsibility name defined in the 

agentparm.txt file. 

insert_job: oacopy_single 

job_type: oacopy 

machine: oaagent 

request_id: 2255470 

oracle_user: SYSADMIN 

oracle_resp: System Administrator 

Define an Oracle E-Business Suite Request Set Job 

You can define an Oracle E-Business Suite Request Set (OASET) job to run a request set 

program. You must get the following information from the original Oracle E-Business 

Suite request set: 

■ Display name or short name of the Oracle E-Business Suite application the request 

set belongs to 

■ Request set short name or display name 

■ User name that the job runs under 

■ Responsibility name 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Oracle E-Business Suite. 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: OASET 

Specifies that the job type is Oracle E-Business Suite Request Set. 

machine 

Specifies the name of the machine on which the job runs. 

oracle_appl_name 

Specifies the name of the Oracle E-Business Suite application that the request 

set belongs to. 

oracle_req_set 

Specifies the request set short name or display name depending on the 

oracle_req_set_type attribute. 

 Define an Oracle E-Business Suite Request Set Job 

Chapter 15: Oracle E-Business Suite Jobs 381 

2. Do one of the following: 

■ Ensure that a default Oracle E-Business Suite user name and responsibility 

name are defined in the agent's agentparm.txt file using the oa.default.user 

and oa.default.responsibility parameters, respectively. 

■ Add the following attributes to the definition: 

oracle_user 

Specifies the Oracle E-Business Suite user name that the job runs under. 

 Note: This attribute overrides the oa.default.user agent parameter. 

oracle_resp 

Specifies an Oracle E-Business Suite responsibility name. 

 Note: This attribute overrides the oa.default.responsibility agent 

parameter. 

3. (Optional) Specify optional Oracle E-Business Suite Request Set attributes: 

■ job_class 

■ job_terminator 

■ oracle_appl_name_type 

■ oracle_custom_property 

■ oracle_mon_children 

■ oracle_mon_children_delay 

■ oracle_output_format 

■ oracle_print_copies 

■ oracle_print_style 

■ oracle_printer 

■ oracle_programdata 

■ oracle_quote_in_default 

■ oracle_req_set_type 

■ oracle_save_output 

■ oracle_template_language 

■ oracle_template_territory 

■ oracle_use_arg_def 

■ oracle_use_set_defaults_first 

4. (Optional) Specify common attributes that apply to all job types. 

The Oracle E-Business Suite Request Set job is defined. 

 Define an Oracle E-Business Suite Request Set Job 

382 User Guide 

Notes: 

■ Attributes that have a default value automatically apply to the job definitions; 

therefore, they are optional. For example, jobs with no specified job type are 

defined as command jobs by default. Other optional attributes specify information 

that is not required but affects how or when a job runs, such as attributes that 

specify scheduling conditions. 

■ Some optional attributes are common to all job types but others apply to certain 

jobs types only. Optional attributes that apply to all job types are known as 

common optional attributes. For more information about common optional 

attributes and the values that you can specify for them (including their default 

values when applicable), see the Reference Guide. 

■ For information about required attributes and job type specific optional attributes, 

see the procedure topics that provide instructions for defining jobs. 

■ This guide provides instructions for defining jobs interactively. You also create job 

definitions in script files and then import them using the jil command or use CA 

WCC to define them. For more information about the JIL command and JIL syntax, 

see the Reference Guide. For more information about using CA WCC to define the 

job, see the CA Workload Control Center Workload Scheduling Guide. 

Example: Run a Request Set 

This example runs a request set named FNDRSSUB1310. The request set belongs to the 

application with the short name BIS in Oracle E-Business Suite. The job uses the default 

Oracle E-Business Suite responsibility name and user name defined on the agent. 

insert_job: oaset_resp 

job_type: oaset 

machine: oaagent 

oracle_appl_name_type: SHORT 

oracle_appl_name: BIS 

oracle_req_set: FNDRSSUB1310 Define an Oracle E-Business Suite Request Set Job 

Chapter 15: Oracle E-Business Suite Jobs 383 

Specify Data for an Individual Program in a Request Set 

When you define an Oracle E-Business Suite Request Set (OASET) job, you can specify 

data for an individual program in the request set. This data overrides the arguments and 

print parameters specified for the entire request set. You can specify the following data 

for a program: 

■ Program arguments 

■ Printer 

■ Print style 

■ Number of copies to print 

■ Whether to save the output from the program 

■ List of user names to notify using short or display names 

■ Output format 

■ Template language and template territory 

■ Whether to quote resolved expressions in default values 

Follow these steps: 

1. Define an Oracle E-Business Suite Request Set job (see page 380). 

2. Add the following attribute to the job definition: 

oracle_programdata 

Specifies data for an individual program in an Oracle E-Business Suite request 

set. 

3. Run the job. 

The data is specified for the program. 

Note: For more information about JIL job types and other job definition attributes, the 

values that you can specify for those attributes, and JIL syntax, see the Reference Guide. 

Example: Specify Values for Individual Programs in a Request Set 

Suppose that you want to run an Oracle E-Business Suite request set named EXTRACTS 

on the oaagent agent. The request set belongs to the application with the display name 

Application Object Library in Oracle E-Business Suite. The job definition specifies the 

following default settings for all programs in the request set: 

■ The number of copies to be printed is 1. 

■ The print style is LANDSCAPE. 

■ The printer is \\printer path\Q8. 

 Define an Oracle E-Business Suite Request Set Job 

384 User Guide 

The first oracle_programdata attribute overrides the default values for the first program 

in the request set. The first program uses the arguments T23 and R1 and prints two 

copies using the \\printer path\Q1 printer in PORTRAIT style. 

The second oracle_programdata attribute overrides the default values for the fifth 

program in the request set. The fifth program uses arguments R and R1 and prints three 

copies using the \\printer path\Q2 printer in PORTRAIT style. 

The other programs in the request set use the default values. 

insert_job: oaset_prog 

job_type: oaset 

machine: oaagent 

oracle_appl_name_type: DISPLAY 

oracle_appl_name: Application Object Library 

oracle_req_set: EXTRACTS 

oracle_user: SYSADMIN 

oracle_resp: System Administrator 

oracle_printer: "\\printer path\Q8" 

oracle_print_style: LANDSCAPE 

oracle_print_copies: 1 

oracle_programdata: index=1, args="T23,,R1", printer="\\printer\Q1", 

print_style=PORTRAIT, print_copies=2, saveop=Y 

oracle_programdata: index=5, args="R,R1,", printer="\\printer\Q2", 

print_style=PORTRAIT, print_copies=3, saveop=N 

Suppose that you want to run an Oracle E-Business Suite request set named 

FNDRSSUB1310 on the local host. The request set belongs to the application with the 

short name BIS in Oracle E-Business Suite. The SYSADMIN and ASGUEST users are 

notified when the single request completes on QATEST1. 

The first oracle_programdata attribute overrides the default values for the first program 

in the request set. The first program uses the output format as PDF, the template 

language is English, and template territory is US. 

The second oracle_programdata attribute overrides the default values for the fifth 

program in the request set. The second program uses the output format as EXCEL, the 

template language is English, and template territory is US. 

 Define an Oracle E-Business Suite Request Set Job 

Chapter 15: Oracle E-Business Suite Jobs 385 

The other programs in the request set use the default values. 

delete_job: test_OASET 

insert_job: oaset_fmt 

job_type: OASET 

machine: localhost 

oracle_user: SYSADMIN 

oracle_resp: System Administrator 

oracle_appl_name_type: SHORT 

oracle_appl_name: BIS 

oracle_req_name_type: DISPLAY 

oracle_req_set: FNDRSSUB1310 

oracle_use_arg_def: Y 

oracle_programdata: index=1, output_format=PDF, template_language=en, 

template_territory=US, notify_users="'SYSADMIN','ASGUEST','QATEST1'" 

oracle_programdata: index=2, output_format=EXCEL, template_language=en, 

template_territory=US, notify_users="'SYSADMIN','ASGUEST','QATEST1'" 

group: OA 

Specify Argument Values to Pass to a Program in a Request Set 

You can pass argument values to an individual program in an Oracle E-Business Suite 

Request Set (OASET) job. The job can also use the default values that are defined by the 

registered Oracle Applications Concurrent Manager program. When an argument value 

is defined in both the job definition and as a default, the argument value in the job 

definition overrides the default. 

Follow these steps: 

1. Define an Oracle E-Business Suite Request Set job (see page 380). 

2. Add the following attribute to the job definition: 

oracle_programdata 

Specifies data for an individual program in an Oracle E-Business Suite request 

set. 

3. (Optional) Add the following attribute: 

oracle_use_arg_def 

Specifies whether to use default values for arguments that are not defined 

using the oracle_programdata attribute. 

4. Run the job. 

The argument values are passed to the program in the request set. 

Note: For more information about JIL job types and other job definition attributes, the 

values that you can specify for those attributes, and JIL syntax, see the Reference Guide. 

 Define an Oracle E-Business Suite Single Request Job 

386 User Guide 

Example: Specify Argument Values for a Program in a Request Set 

This example runs an Oracle E-Business Suite Request Set job that uses the argument 

defaults in Oracle E-Business Suite and the argument values defined in the job 

definition. The second program in the request set has four arguments and you want to 

pass T23 as the first value and R1 as the fourth value. The argument string specifies 

placeholders for the second and third arguments, so the job uses the default values for 

those arguments. 

insert_job: oaset_prog 

job_type: oaset 

machine: oaagent 

oracle_appl_name_type: DISPLAY 

oracle_appl_name: Application Object Library 

oracle_req_set: EXTRACTS 

oracle_user: SYSADMIN 

oracle_resp: System Administrator 

oracle_use_arg_def: Y 

oracle_programdata: index=2, args="T23,,R1", printer="\\printer\Q1", 

print_style=PORTRAIT, print_copies=2, saveop=Y 

Define an Oracle E-Business Suite Single Request Job 

You can define an Oracle E-Business Suite Single Request (OASG) job to run a single 

request program. You must get the following information from the original Oracle 

E-Business Suite single request: 

■ Display name or short name of the Oracle E-Business Suite application the single 

request belongs to 

■ Program short name or display name 

■ User name that the job runs under 

■ Responsibility name 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Oracle E-Business Suite. 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: OASG 

Specifies that the job type is Oracle E-Business Suite Single Request. 

machine 

Specifies the name of the machine on which the job runs. 

 Define an Oracle E-Business Suite Single Request Job 

Chapter 15: Oracle E-Business Suite Jobs 387 

oracle_appl_name 

Specifies the name of the Oracle E-Business Suite application that the single 

request belongs to. 

oracle_program 

Specifies the single request program short name or display name depending on 

the oracle_program_name_type attribute. 

2. Do one of the following: 

■ Ensure that a default Oracle E-Business Suite user name and responsibility 

name are defined in the agent's agentparm.txt file using the oa.default.user 

and oa.default.responsibility parameters, respectively. 

■ Add the following attributes to the definition: 

oracle_user 

Specifies the Oracle E-Business Suite user name that the job runs under. 

 Note: This attribute overrides the oa.default.user agent parameter. 

oracle_resp 

Specifies an Oracle E-Business Suite responsibility name. 

 Note: This attribute overrides the oa.default.responsibility agent 

parameter. 

3. (Optional) Specify optional Oracle E-Business Suite Single Request attributes: 

■ job_class 

■ job_terminator 

■ oracle_appl_name_type 

■ oracle_args 

■ oracle_custom_property 

■ oracle_desc 

■ oracle_mon_children 

 Define an Oracle E-Business Suite Single Request Job 

388 User Guide 

■ oracle_mon_children_delay 

■ oracle_notify_display_users 

■ oracle_notify_users 

■ oracle_output_format 

■ oracle_print_copies 

■ oracle_print_style 

■ oracle_printer 

■ oracle_program_name_type 

■ oracle_quote_in_default 

■ oracle_save_output 

■ oracle_template_language 

■ oracle_template_territory 

■ oracle_use_arg_def 

4. (Optional) Specify common attributes that apply to all job types. 

The Oracle E-Business Suite Single Request job is defined. 

Notes: 

■ Attributes that have a default value automatically apply to the job definitions; 

therefore, they are optional. For example, jobs with no specified job type are 

defined as command jobs by default. Other optional attributes specify information 

that is not required but affects how or when a job runs, such as attributes that 

specify scheduling conditions. 

■ Some optional attributes are common to all job types but others apply to certain 

jobs types only. Optional attributes that apply to all job types are known as 

common optional attributes. For more information about common optional 

attributes and the values that you can specify for them (including their default 

values when applicable), see the Reference Guide. 

■ For information about required attributes and job type specific optional attributes, 

see the procedure topics that provide instructions for defining jobs. 

■ This guide provides instructions for defining jobs interactively. You also create job 

definitions in script files and then import them using the jil command or use CA 

WCC to define them. For more information about the JIL command and JIL syntax, 

see the Reference Guide. For more information about using CA WCC to define the 

job, see the CA Workload Control Center Workload Scheduling Guide. 

 Define an Oracle E-Business Suite Single Request Job 

Chapter 15: Oracle E-Business Suite Jobs 389 

Example: Run a Single Request 

This example runs a single request program named FNDSCARU. The single request 

belongs to the application with the short name ACCOUNTS in Oracle E-Business Suite. 

The job runs under the SYSADMIN user with System Administrator responsibility. 

insert_job: oasg_short 

job_type: oasg 

machine: oaagent 

oracle_appl_name_type: SHORT 

oracle_appl_name: ACCOUNTS 

oracle_program: FNDSCARU 

oracle_user: SYSADMIN 

oracle_resp: System Administrator 

Specify Argument Values to Pass to a Program in a Single Request 

You can pass argument values to a program in an Oracle E-Business Suite Single Request 

(OASG) job. The job can also use the default values that are defined by the registered 

Oracle Applications Concurrent Manager program. When an argument value is defined 

in both the job definition and as a default, the argument value in the job definition 

overrides the default. 

Follow these steps: 

1. Define an Oracle E-Business Suite Single Request job (see page 386). 

2. Add the following attribute to the job definition: 

oracle_args 

Defines the argument values to pass to an Oracle E-Business Suite single 

request. 

3. (Optional) Add the following attribute: 

oracle_use_arg_def 

Specifies whether to use default values for arguments that are not defined 

using the oracle_args attribute. 

4. Run the job. 

The argument values are passed to the program in the single request. 

Note: For more information about JIL job types and other job definition attributes, the 

values that you can specify for those attributes, and JIL syntax, see the Reference Guide. 

 Attributes with Default Values 

390 User Guide 

Example: Specify Argument Values for a Single Request 

Suppose that you want to pass the argument values, T,DefArg2,X23,,DefArg5, to a single 

request program. The job uses the argument values that are specified in the job 

definition and the default values defined in Oracle E-Business Suite as follows: 

■ The first argument, T, and the third argument, X23, are specified in the job 

definition. 

■ The second argument, DefArg2, and the fifth argument, DefArg5, are defined as 

defaults in Oracle E-Business Suite. 

■ The fourth argument is not specified in the job definition or defined as a default on 

Oracle E-Business Suite, so the agent passes an empty string for that argument. 

insert_job: oasg_args 

job_type: oasg 

machine: oaagent 

oracle_appl_name_type: DISPLAY 

oracle_appl_name: Application Object Library 

oracle_user: SYSADMIN 

oracle_resp: System Administrator 

oracle_program: FNDSCARU 

oracle_use_arg_def: Y 

oracle_args: T,,X23,, 

Attributes with Default Values 

Attributes that have a default value automatically apply to the job definition. Therefore, 

you do not have to specify those attributes in the definition. Your agent administrator 

can define some default values on the agent in the agentparm.txt file. 

If you specify the attribute in a job definition, it overrides the default. 

The following Oracle E-Business Suite job attributes have default values: 

oracle_appl_name_type 

Specifies whether the name of the Oracle E-Business Suite application is the short 

name or the display name. 

Default: SHORT 

oracle_desc (OASG jobs only) 

Defines a description for the Oracle E-Business Suite Single Request job, which is 

displayed in the Oracle Concurrent Manager. 

Default: oa.default.desc agent parameter, if specified 

 Attributes with Default Values 

Chapter 15: Oracle E-Business Suite Jobs 391 

oracle_mon_children 

Specifies whether the children of the Oracle E-Business Suite programs are 

monitored. 

Default: N (The job does not monitor children programs.) 

oracle_output_format 

Specifies the output format for a single request or request set. 

Default: oa.default.outputFormat agent parameter, if specified 

oracle_print_style 

Specifies an Oracle Applications print style. 

Default: oa.default.printStyle agent parameter, if specified 

oracle_printer 

Specifies the name of a printer to be used by Oracle Applications. 

Default: oa.default.printer agent parameter, if specified 

oracle_program_name_type (OASG jobs only) 

Identifies whether the name of the Oracle E-Business Suite program is the short 

name or the display name. 

Default: SHORT 

oracle_quote_in_default 

Specifies whether to quote resolved expressions in default values. 

Default: N (The resolved expressions in default values are not quoted.) 

oracle_req_set_type (OASET jobs only) 

Identifies whether the name of the Oracle E-Business Suite request set is the short 

name or the display name. 

Default: SHORT 

oracle_resp 

Specifies an Oracle Applications responsibility name. You must also specify an 

Oracle Applications user name using the oracle_user attribute or by setting the 

oa.default.user parameter in the agentparm.txt file. 

Default: oa.default.responsibility agent parameter, if specified 

Note: All Oracle Applications jobs require a responsibility name. If you do not 

specify this attribute in the job definition, a default responsibility name must be 

defined in the agent's agentparm.txt file using the oa.default.responsibility 

parameter. Otherwise, the job fails. 

 Attributes with Default Values 

392 User Guide 

oracle_save_output (OASG and OASET jobs only) 

Specifies whether to save the output from an Oracle E-Business Suite Single 

Request or Request Set job. 

Default: N (The job does not save the output.) 

oracle_template_language 

Specifies the template language for a single request or request set. 

Default: oa.default.templateLanguage agent parameter, if specified 

oracle_template_territory 

Specifies the template territory for a single request or request set. 

Default: oa.default.templateTerritory agent parameter, if specified 

oracle_use_arg_def (OASG and OASET jobs only) 

Specifies whether to use default values for arguments that not defined using the 

oracle_args attribute or the oracle_programdata attribute. The default arguments 

are defined in Oracle E-Business Suite. 

Default: N (The job does not use the default values for the arguments.) 

oracle_use_set_defaults_first (OASET job only) 

Specifies whether request set defaults take precedence over concurrent program 

defaults in Oracle Applications. 

Default: N ( The concurrent program defaults take precedence over request set 

defaults.) or oa.default.useSetDefaultsFirst agent parameter, if specified. 

oracle_user 

Specifies an Oracle Applications user name that the job runs under. 

Default: oa.default.user agent parameter, if specified 

Note: All Oracle Applications jobs require a user name. If you do not specify this 

attribute in the job definition, a default user must be defined in the agent's 

agentparm.txt file using the oa.default.user parameter. Otherwise, the job fails. 

Note: For more information about JIL job types and other job definition attributes, the 

values that you can specify for those attributes, and JIL syntax, see the Reference Guide. 

 Attributes with Default Values 

Chapter 15: Oracle E-Business Suite Jobs 393 

Example: Override a Default Value in an OASET Job 

This example overrides the default responsibility name using the oracle_resp attribute. 

The job also overrides the default user that the job runs under using the oracle_user 

attribute. 

insert_job: oaset_resp 

job_type: oaset 

machine: oaagent 

oracle_appl_name_type: SHORT 

oracle_appl_name: BIS 

oracle_req_set: FNDRSSUB1310 

oracle_user: SYSADMIN 

oracle_resp: System Administrator