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.



CA Workload Automation AE Cross-Instance Job Dependencies
A CA Workload Automation AE instance is one licensed version of CA Workload
Automation AE software running as a server and as one or more clients, on one or more
computers. An instance uses its own scheduler, one or more application servers, and
event server, and operates independently of other instances.
Different instances can run from the same executables and can have the same value for
$AUTOSYS. However, each instance must have different values for $AUTOUSER and
$AUTOSERV. Different instances can also be run on the same computer.

Multiple CA Workload Automation AE instances are not connected, but they can
communicate with one another. This communication lets you schedule workload across
instances in your enterprise. You can define jobs that have dependencies on jobs
running on other instances (cross-instance job dependencies). A CA Workload
Automation AE job with these dependencies conditionally starts based on the status of
the job on the other instance. In this situation, the local instance scheduler acts as a
client and issues sendevent commands to the external instance. The other instance's
application server processes the sendevent request and stores the dependency request
or status update in its database. You can also manually send events from one instance
to another.

When the status of a job with cross-instance dependencies changes, the scheduler
sends a CHANGE_STATUS event to the remote instance event server while the job in the
local instance runs. The scheduler processes incoming events and stores the status
changes in the ujo_ext_job table on the remote instance event server. The scheduler
evaluates condition dependencies for external jobs based on the stored status.
 CA Workload Automation AE Cross-Instance Job Dependencies



The scheduler also sends an equivalent CHANGE_STATUS event to the remote instance
for status changes not resulting from a CHANGE_STATUS event, specifically status
changes resulting from one of the following:
■ Unavailable machine load units, resources or agents prevent a job from running and
the scheduler change the status of the job.
■ The user changes the status by issuing a sendevent command for one of the
following events: JOB_ON_HOLD, JOB_OFF_HOLD, JOB_ON_ICE, JOB_OFF_ICE,
JOB_ON_NOEXEC, JOB_OFF_NOEXEC.
The equivalent CHANGE_STATUS event may also result in changes to job exit codes
stored on the remote instance. This helps ensure that the scheduler accurately
evaluates downstream jobs dependent on the remote jobs, including the job status and
exit code conditions of the dependent jobs.
Notes:
■ The equivalent CHANGE_STATUS event represents the actual status change that
occurs in the local instance, and the event includes text specifying the actual status
change. The remote scheduler log records this information.
■ For more information about the translated status that the local scheduler sends to
the remote instance, see the Administration Guide.

■ Before you can submit jobs on other CA Workload Automation AE instances, you
must define the instances to each other. For more information about configuring
CA Workload Automation AE to support cross-instance scheduling, see the UNIX
Implementation Guide or Windows Implementation Guide.

How Cross-Instance Job Dependencies are Processed
You can associate jobs with more than one CA Workload Automation AE instance. For
example, you can define a job to conditionally start based on the status of a job on
another instance.
The following illustration shows two instances exchanging cross-instance job
dependencies:

Note: If instance ACE’s application server runs on port 9001 and instance PRD’s
application server runs on port 9002, you must verify that both ports are configured
using SSA on both machines. Otherwise, communication with the remote application
server will fail.

The CA Workload Automation AE event server tracks cross-instance job dependencies as
follows:
Each time a job definition with a cross-instance job dependency is submitted to the
database, the event server does the following:
■ Makes an entry in the ujo_ext_job table of the issuing instance. The entries in this
table specify the status of jobs in other instances that the issuing instance has an
interest in.
■ Makes an entry in the ujo_req_job table of the receiving instance. The entries in
this table specify the jobs defined as job dependencies in a job definition on the
issuing instance.
 How Cross-Instance Job Dependencies are Processed



The jobs are entered in the ujo_ext_job and ujo_req_job tables using the following
syntax:
job_name^INSTANCE_NAME
For example, jobB^PRD indicates a job named jobB on the PRD instance.
The use of multiple databases is independent of instances using cross-instance
dependencies. You can have multiple instances that each use dual event servers.

When CA Workload Automation AE encounters a cross-instance dependency, it sends an
EXTERNAL_DEPENDENCY event from the requesting instance. The following process
occurs when one instance cannot send status updates (events) to the other instance:
■ An INSTANCE_UNAVAILABLE alarm is issued.
■ The ujo_asext_config table is updated to indicate that the external instance is
offline.
■ While the job continues to run, all external events to be sent to the external
instance are stored in the ujo_ext_event table.
■ The local instance periodically tries to connect to the external instance.
■ When local instance reconnects successfully to the external instance, all the events
are sent to the external instance, and the external events are deleted from the
ujo_ext_event table.
Types of External Instances
To use external job dependencies, the scheduling manager or remote machine must be
defined as an external instance in the CA Workload Automation AE database.
When you define the external instance, you must identify the type using the xtype JIL
attribute. Options are the following:
xtype: a
Indicates that the external scheduling manager is a CA Workload Automation AE
application server instance.
xtype: c
Indicates that CA AutoSys WA Connect Option is installed with the external
scheduling manager. CA AutoSys WA Connect Option can be installed on the
mainframe and supports cross-instance jobs and job dependencies. It lets you
submit job requests to and receive job submissions from the following mainframe
scheduling managers:
■ CA Jobtrac Job Management
■ CA Scheduler Job Management
■ CA Workload Automation SE
The CA Workload Automation AE scheduler uses CAICCI to communicate with CA
AutoSys WA Connect Option.

xtype: u
Indicates that CA UJMA is installed with the external scheduling manager or on the
remote machine. CA UJMA can be installed on the mainframe, UNIX, and Windows.
It lets you submit job requests to the remote machine where CA UJMA is installed.
It lets you submit job requests to and receive job submissions from the following
scheduling managers:
■ CA Job Management Option
■ CA Jobtrac Job Management
■ CA Scheduler Job Management
■ CA Workload Automation SE
The CA Workload Automation AE scheduler uses CAICCI to communicate with CA
UJMA.
Note: Unlike CA AutoSys WA Connect Option, CA UJMA does not let you define
cross-instance job dependencies on the mainframe. To define cross-instance job
dependencies on the mainframe, you must install CA AutoSys WA Connect Option
on the same computer as the mainframe scheduling manager.
 Creating Cross-Instance Job Dependencies Using CA AutoSys WA Connect Option



xtype: e
Indicates that the external scheduling manager is CA Workload Automation EE. You
can define cross-instance job dependencies.
Note: Bi-directional scheduling is currently not supported between CA Workload
Automation AE and CA Workload Automation EE.

Creating Cross-Instance Job Dependencies Using CA AutoSys
WA Connect Option
CA Workload Automation AE jobs can have dependencies on jobs managed by an CA
AutoSys WA Connect Option and a CA Technologies scheduling manager running on the
mainframe. The mainframe scheduling manager uses CA AutoSys WA Connect Option
and CAICCI to communicate with CA Workload Automation AE. The CA Workload
Automation AE scheduler also uses its cross-platform scheduling interface for
communication.
For example, the following illustration shows a CA Workload Automation AE job defined
on a UNIX or Windows computer. The job's starting condition is the successful
completion of a job running on the mainframe.
 Submitting a Job To and From Another Computer Using CA UJMA

CA Workload Automation AE jobs can be dependent on the status of external jobs
managed by CA AutoSys WA Connect Option, and external jobs can be dependent on
the status of CA Workload Automation AE jobs. CA Workload Automation AE uses the
following process to create cross-instance dependencies:
1. The CA Workload Automation AE scheduler sends a request for the status of a CA
AutoSys WA Connect Option job.
2. CA AutoSys WA Connect Option registers the request.
3. The CA AutoSys WA Connect Option job runs on the mainframe.
4. CA AutoSys WA Connect Option sends the job status to the CA Workload
Automation AE scheduler.
5. The CA Workload Automation AE scheduler communicates the status to the event
server.
6. The CA Workload Automation AE scheduler processes the status and starts the job
that is dependent on the completion of the CA AutoSys WA Connect Option job, if
appropriate.
Note: For more information about the CAICCI components, see the UNIX
Implementation Guide or Windows Implementation Guide.

Submitting a Job To and From Another Computer Using CA
UJMA
CA Workload Automation AE can schedule jobs on a computer that has CA UJMA
installed on it. As job submission requests are processed, the scheduler log file records
events sent between CA Workload Automation AE and CA UJMA. The following
descriptions help you understand the events recorded in the scheduler log file.
Note: CA Workload Automation AE can directly schedule jobs on a computer that is
running a supported workload automation agent. This topic only discusses the
communication with CA UJMA.
 Submitting a Job To and From Another Computer Using CA UJMA



The following diagram shows the components involved in the communication:

The CA Workload Automation AE scheduler communicates directly with CA UJMA using
CAICCI and the CA Workload Automation AE Cross-Platform Interface. The
communication components running on the CA UJMA computer receive information
from the CA Workload Automation AE scheduler and pass it to CA UJMA. Similarly, CA
UJMA passes information through the communication components to the CA Workload
Automation AE scheduler.
CA UJMA does the following:
■ Receives job requests from one or more CA Technologies scheduling managers
(such as CA Job Management Option (JMO), CA Workload Automation AE, and CA
Workload Automation SE). CA UJMA initiates the requested program, script, JCL, or
other unit of work. If you are scheduling to the mainframe, the command or
program to initiate is the job name of the job as defined in the mainframe
scheduling system.
■ Collects status information about job runs.
■ Sends status information to the requesting scheduling manager.
Note: Unlike CA AutoSys WA Connect Option, CA UJMA does not support cross-instance
job dependencies.

The following process is used to start a job on a CA UJMA computer:
■ You define a job on CA Workload Automation AE that specifies the job to start on
the CA UJMA computer. The mainframe job to start (specified in the command
attribute of the CA Workload Automation AE job definition) must be a named job
known to the CA Workload Automation AE scheduler. The mainframe job to start
cannot be a command or script.
■ The CA Workload Automation AE scheduler sends the job information to CA UJMA.
■ The job changes to STARTING status.
■ CA UJMA starts the job and sends an event to the scheduler. The event sent is
JOBINITU if the job started or JOBFAILU if the job could not start.

■ The scheduler converts the JOBINITU event to RUNNING, puts it in the database,
and updates the job's status to RUNNING. If CA UJMA sent a JOBFAILU event, the
scheduler converts the event to FAILURE and processes it accordingly.
■ If the job completes successfully, CA UJMA sends a JOBTERMU event to the
scheduler.
■ The scheduler converts the JOBTERMU event to SUCCESS, FAILURE, or TERMINATED
based on the exit code of the job. If the job exited with a normal end of job code
(EOJ) the scheduler converts JOBTERMU to SUCCESS or FAILURE. If the job exited
with an abnormal end of job code (AEOJ), the scheduler converts JOBTERMU to
TERMINATED.

CA Workload Automation AE can also receive job submission requests from a CA UJMA
computer. The job to start must be a job defined on CA Workload Automation AE and
cannot be a command or script. If CA Workload Automation AE receives a job
submission request from the mainframe, the job to run (specified by the SUBFILE
parameter of the mainframe job) must be defined as a valid job on the CA Workload
Automation AE computer.
For the CA Workload Automation AE scheduler to communicate with CA UJMA
computers, the scheduler must convert CA Workload Automation AE-based events to
events that CA UJMA can interpret. Similarly, the CA Workload Automation AE scheduler
must convert events returned from CA UJMA back to events the scheduler can interpret.

The following table lists the CA Workload Automation AE and CA UJMA events:

Operation CA Workload Automation
AE
CA UJMA
Starting a job STARTJOB SUBMITU
Job has started and is
running
RUNNING JOBINITU Unsupported Attributes for CA AutoSys WA Connect Option or CA UJMA Jobs



Operation CA Workload Automation
AE
CA UJMA
Job has terminated
successfully with an exit
code
SUCCESS or FAILURE JOBTERMU
Job has failed to start FAILURE JOBFAILU

Unsupported Attributes for CA AutoSys WA Connect Option or
CA UJMA Jobs
The following table lists attributes that are not supported for CA AutoSys WA Connect
Option and CA UJMA jobs. If you specify these attributes, they are ignored.

JIL Attribute CA WCC Field
chk_files File system check
heartbeat_interval Heartbeat interval
job_load Job load
job_terminator Terminate on failure of containing box
job_type:f File Watcher (FW) job in either Quick Edit or Application
Editor
n_retrys Times to restart job after failure
priority Priority
profile Profile
std_err_file Standard error file
std_in_file Standard input file
std_out_file Standard output file
term_run_time Minutes to wait before terminating
watch_file File(s) to watch
watch_file_min_size Minimum file size
watch_interval Watch interval
Note: Computers managed by CA UJMA computers cannot be part of a virtual machine.
The max_load and factor attributes are also not supported when defining an external CA
UJMA instance.

How Job Dependencies are Processed Using CA Workload
Automation EE
You can define job dependencies between CA Workload Automation AE and an external
CA Workload Automation EE instance running on the mainframe. As job dependencies
are processed, the scheduler log file records events communicated between CA
Workload Automation AE and CA Workload Automation EE. The following descriptions
help you understand the events recorded in the scheduler log file.

A CA Workload Automation AE job can depend on another job on CA Workload
Automation EE as shown in the following diagram:

The job dependency is processed as follows:
■ The job dependency is specified in the condition attribute of the local CA Workload
Automation AE job definition. For example, the following job depends on the
success of the ZOS01 job defined on the CA Workload Automation EE instance
named MSR:
insert_job: MSR1
job_type: CMD
command: sleep 10
machine: localhost
owner: root@hostname.ca.com
condition: s(ZOS01^MSR)
■ When the CA Workload Automation AE job is created or updated, an
EXTERNAL_DEPENDENCY event is created in the CA Workload Automation AE
database. The event contains the information in the condition attribute.
■ The CA Workload Automation AE scheduler sends a job dependency request to CA
Workload Automation EE.
■ As the job runs on the external instance, CA Workload Automation EE sends status
updates to CA Workload Automation AE.
 How Job Dependencies are Processed Using CA Workload Automation EE



■ The CA Workload Automation AE scheduler updates the ujo_ext_job table with the
status updates from CA Workload Automation EE.
■ When the CA Workload Automation AE job is deleted or its condition attribute is
changed, an EXTERNAL_DEPENDENCY event is created in the CA Workload
Automation AE database. The event contains the information required to remove
the external job dependency from the ujo_ext_job table.
■ The CA Workload Automation AE scheduler sends a request to CA Workload
Automation EE to deregister the job dependency on the external instance.

A job on CA Workload Automation EE can depend on a CA Workload Automation AE job
as shown in the following diagram:

The job dependency is processed as follows:
■ When a new generation of an application is started in the external instance, CA
Workload Automation EE sends a job dependency request to CA Workload
Automation AE for a single run of a job.
■ The CA Workload Automation AE scheduler creates an EXTERNAL_DEPENDENCY
event on its behalf.
■ The CA Workload Automation AE scheduler updates the ujo_req_job database table
to record that a CA Workload Automation EE job is dependent on the local job.
■ As the job runs on the local CA Workload Automation AE instance, the CA Workload
Automation AE scheduler sends status updates to CA Workload Automation EE.
■ When the job has its run, the CA Workload Automation AE scheduler deletes the
dependent job entry from the ujo_req_job table.
The following process occurs when CA Workload Automation AE cannot send status
updates (events) to CA Workload Automation EE:
■ An INSTANCE_UNAVAILABLE alarm is issued.
■ The ujo_asext_config table is updated to indicate that the external instance is
offline.
■ While the job continues to run, all events to be sent to the external instance are
stored in the ujo_ext_event table.
■ The CA Workload Automation AE scheduler periodically tries to connect to CA
Workload Automation EE.
■ When the CA Workload Automation AE scheduler successfully re-connects to CA
Workload Automation EE, all the events are sent to CA Workload Automation EE,
and the events are deleted from the ujo_ext_event table.

To communicate with CA Workload Automation EE, the CA Workload Automation AE
scheduler converts CA Workload Automation AE-based events to events that CA
Workload Automation EE can interpret. Similarly, the scheduler must convert events
returned from CA Workload Automation EE back to events that the scheduler can
interpret. All converted events are recorded in the scheduler log file to indicate that the
events are from an external instance.

The following table lists the CA Workload Automation AE and CA Workload Automation
EE events:

CA Workload Automation AE Event CA Workload Automation EE Event
STARTING READY
RUNNING EXEC
SUCCESS COMPLETED
FAILURE FAILED
TERMINATED FAILED with a Job Terminated status
ON_ICE COMPLETED with a BYPASSED status
INACTIVE HELD
Notes:
■ CA Workload Automation AE communicates directly with CA Workload Automation
EE. You do not have to install additional products to integrate the scheduling
managers.
■ Bi-directional scheduling is currently not supported between CA Workload
Automation AE and CA Workload Automation EE. You cannot submit jobs to or
receive job requests from CA Workload Automation EE at this time.
 Cross-Platform Scheduling



Cross-Platform Scheduling
Cross-platform scheduling lets you schedule and reroute jobs between CA Workload
Automation AE and other machines running on different platforms, including
mainframe.
To use cross-platform scheduling, required components must be installed on the CA
Workload Automation AE computer and on the external machine that CA Workload
Automation AE works with. The scheduling manager or remote machine must also be
defined as an external instance in the CA Workload Automation AE database.

Note: Before you can submit jobs on other scheduling managers, you must activate the
CA Workload Automation AE cross-platform interface and define the scheduling
manager as an external instance on CA Workload Automation AE. For more information
about configuring CA Workload Automation AE to support cross-platform scheduling,
see the UNIX Implementation Guide or Windows Implementation Guide.

Submitting a Job To and From the Mainframe Using CA AutoSys
WA Connect Option
CA Workload Automation AE lets you schedule workload across distributed and
mainframe platforms. You can submit jobs on the mainframe and receive job
submission requests from the mainframe. Depending on the mainframe scheduling
manager, the mainframe must have the following software installed on it:
■ CA Jobtrac Job Management and CA AutoSys WA Connect Option
■ CA Scheduler Job Management and CA AutoSys WA Connect Option
■ CA Workload Automation EE
■ CA Workload Automation SE and CA AutoSys WA Connect Option

CA Workload Automation AE and the mainframe scheduling manager use CAICCI to
communicate.
When submitting a job to the mainframe, the following process occurs:
■ The CA Workload Automation AE scheduler on the distributed platform interrogates
the start job request, processes it, and transmits it to the scheduling manager
installed on the mainframe.
■ After the scheduling manager receives the request on the mainframe, it submits
and tracks the mainframe job. The job submission and tracking is completed in one
of the following ways:
– Directly by the XPS-enabled mainframe scheduling product
– Through CA AutoSys WA Connect Option

When CA Workload Automation AE accepts a job submitted from a mainframe system,
CA Workload Automation AE reports its status back to the scheduling manager on the
mainframe.
Note: For more information about submitting the job from an external mainframe
scheduling manager, see the appropriate product documentation.

Cross-Platform Interface Messages Logged for CA UJMA
On UNIX, all messages produced by the cross-platform interface are written to the CA
Workload Automation AE scheduler log, which is located in the $AUTOUSER/out
directory.
On Windows, all messages produced by the cross-platform interface are written to the
CA Workload Automation AE scheduler log, which is located in the %AUTOUSER%\out
directory.

The following message indicates that the scheduler has transferred a job to the
cross-platform interface for submission to a CA UJMA computer:
CAUAJM_I_10073 AutoSys --> Cross Platform Interface:
machine=machine_name job_name=job_name
machine_name
Identifies the CA UJMA computer to which the job is being submitted.
job_name
Identifies the CA Workload Automation AE job name as defined to the event server.
 Cross-Platform Interface Messages Logged for CA UJMA



The following message indicates that an event status has been received from CA UJMA.
The event status is converted to the appropriate CA Workload Automation AE event
status and inserted in the event server.
CAUAJM_I_40263 EVENTU: event_name
EXITCODE: exitcode/dbcode JOB: job_name
event_name
Identifies one of the following events:
JOBINITU
Indicates that a job has started on a CA UJMA computer.
JOBTERMU
Indicates that a job has completed on a CA UJMA computer.
JOBFAILU
Indicates that a job has failed to start on a CA UJMA computer.
SUBMITU
Indicates that a job has been submitted to CA Workload Automation AE.

exitcode/dbcode
Identifies the actual job exit code returned by CA UJMA.
job_name
Identifies the CA Workload Automation AE job name as defined to the event server.

Define an External Instance
To use cross-instance scheduling, you must define the external instance to CA Workload
Automation AE. The external instance can be another CA Workload Automation AE
instance or a scheduling manager running on another platform.
Follow these steps:
1. Do one of the following:
■ Issue JIL in interactive mode.
■ Open a JIL script in a text editor.
2. Specify the following definition:
insert_xinst: instance_name
xtype: a | c | u | e
xmachine: host_name
xtype: a | c | u | e
Specifies the external instance type. Options include the following:
■ a—Identifies a remote CA Workload Automation AE application server
instance.
■ c—Identifies a CA AutoSys Workload Automation Connect Option instance.
■ u—Identifies a CA Universal Job Management Agent or CA NSM instance.
■ e—Identifies a CA Workload Automation EE instance.
3. (CA Workload Automation AE instances only) Specify the following additional
attributes:
xcrypt_type: NONE | DEFAULT | AES
xkey_to_manager: encryption_key
xport: port_number
4. (CA Workload Automation EE instances only) Specify the following additional
attributes:
xmanager: manager_name
xport: port_number
xcrypt_type: NONE | AES
xkey_to_manager: encryption_key
5. Do one of the following:
■ Enter exit if you are using interactive mode.
■ Redirect the script to the jil command if you are using a script.
The insert_xinst subcommand is issued and the specified external instance is
defined.
 Update an External Instance



Notes:
■ For CA Workload Automation EE, the xcrypt_type value must match the encryption
type specified in the AGENTDEF data set.
■ For more information about the syntax for the insert_xinst subcommand and
related attributes, see the Reference Guide.
Example: Define a CA Workload Automation EE Instance
This example defines the CA Workload Automation EE instance named CYB to CA
Workload Automation AE. CYB runs on the CYBHOST computer at port 7550. The CM
manager name is unique to this CA Workload Automation EE instance. The CA Workload
Automation AE scheduler communication alias is defined in the AGENTDEF data set on
CA Workload Automation EE. CA Workload Automation EE is also configured to point to
the CA Workload Automation AE computer on the auxiliary listening port.
insert_xinst: CYB
xtype: e
xmanager: CM
xmachine: CYBHOST
xcrypt_type: NONE
xport: 7550
Update an External Instance
You can update an external instance defined in CA Workload Automation AE. The
external instance can be another CA Workload Automation AE instance or a scheduling
manager running on another platform. You can update the instance definition when the
connection information changes. The connection information must be accurate so that
the scheduling managers can communicate with each other.
Follow these steps:
1. Do one of the following:
■ Issue JIL in interactive mode.
■ Open a JIL script in a text editor.
2. Specify the following JIL subcommand:
update_xinst: instance_name Delete an External Instance
3. Specify the following attributes as appropriate:
xmachine: host_name
xcrypt_type: NONE | DEFAULT | AES
xkey_to_manager: encryption_key
xport: port_number
xmanager: manager_name
4. Do one of the following:
■ Enter exit if you are using interactive mode.
■ Redirect the script to the jil command if you are using a script.
The update_xinst subcommand is issued and the specified external instance is
updated.
Note: For more information about the syntax for the update_xinst subcommand and
related attributes, see the Reference Guide.
Example: Update a CA Workload Automation EE Instance
Suppose that an external instance is defined on CA Workload Automation AE for the CA
Workload Automation EE instance named CYB. This example updates the external
instance definition so that CYB points to the CYBHOST2 computer at port 7551.
update_xinst: CYB
xmachine: CYBHOST2
Delete an External Instance
You can delete an external instance that you no longer use from CA Workload
Automation AE.
Follow these steps:
1. Do one of the following:
■ Issue JIL in interactive mode.
■ Open a JIL script in a text editor.

2. Specify the following JIL subcommand:
delete_xinst: instance_name
3. Do one of the following:
■ Enter exit if you are using interactive mode.
■ Redirect the script to the jil command if you are using a script.
The insert_xinst subcommand is issued and the specified external instance is
deleted from CA Workload Automation AE.
 Start a Job on an External CA Workload Automation AE Instance



Note: For more information about the syntax for the delete_xinst subcommand, see the
Reference Guide.
Example: Delete a CA Workload Automation EE Instance
This example deletes the definition of the CA Workload Automation EE instance named
CYB.
delete_xinst: CYB
Start a Job on an External CA Workload Automation AE
Instance
CA Workload Automation AE instances are not connected, but they can communicate
with one another. You can send a STARTJOB event directly from one instance to
another. This helps you integrate your workload across CA Workload Automation AE
instances in your enterprise.
To start a job on an external CA Workload Automation AE instance, enter the following
command at the UNIX operating system prompt or the Windows instance command
prompt:
sendevent -E STARTJOB -J job_name -S autoserv
job_name
Specifies a job defined on the autoserv instance.
autoserv
Specifies the instance's unique, capitalized three-character identifier.
Example: ACE
The sendevent command is issued and the job request is submitted on the external CA
Workload Automation AE instance.
Notes:
■ To use the sendevent -S option, the instance from where you issue the sendevent
command must have a client installed for the external instance. For more
information about configuring cross-instance communication, see the UNIX
Implementation Guide or Windows Implementation Guide.
■ For more information about the syntax for the sendevent command and related
attributes, see the Reference Guide.
Define a Job to Run on an External Instance
From your local CA Workload Automation AE instance, you can submit a job to run on
an external instance. The external instance is a different scheduling manager installed
on another platform, including mainframe. Submitting external jobs helps you integrate
workload across platforms in your enterprise.
Note: Before you can submit jobs on other scheduling managers, you must activate the
CA Workload Automation AE cross-platform interface and define the scheduling
manager as an external instance on CA Workload Automation AE. For more information
about configuring CA Workload Automation AE to support cross-platform scheduling,
see the UNIX Implementation Guide or Windows Implementation Guide.
Follow these steps:
1. Insert a job and specify the following attributes in the definition:
job_type: CMD
Specifies that the job type is Command.
machine
Specifies the name of the external instance.
Note: The external instance must be defined on CA Workload Automation AE
using the insert_xinst subcommand.

owner
Specifies the user on the external instance that the job runs under. The owner
must be specified as owner@machine.
CA UJMA Note: The specified owner must have an account on the external CA
UJMA computer. The account must match the owner name exactly, and the
owner (user ID and password) must be defined using the autosys_secure
command.

command
Specifies the job to run on the external instance when all the starting
conditions are met.

CA UJMA Limits (UNIX or Windows): Where the operating system permits, CA
UJMA job names on distributed systems can contain up to 64 alphanumeric
characters and can contain both uppercase and lowercase characters. You
cannot use blank spaces and tab characters.
 Define a Job to Run on an External Instance



CA UJMA Limits (mainframe): CA UJMA job names on the mainframe must
follow these guidelines:
■ The first character of a job name must be an uppercase letter (A-Z), a
pound sign (#), an at sign (@), or a dollar sign ($).
■ The remaining characters in the job name can be any combination of
uppercase letters (A-Z), numbers (0-9), pound signs (#), at signs (@), and
dollar signs ($).
■ All letters (A-Z) must be in uppercase.
■ Job names can be up to eight characters in length.

2. (Optional) Specify common attributes that apply to all jobs.
The external job is defined.
Note: For more information about the syntax for the JIL attributes, see the Reference
Guide.

Example: Define a Job to Run on an AS/400 Computer
This example defines a command job to run on an AS/400 computer.
insert_job: as400_a1
job_type: CMD
command: DLYJOB DLY(15)
machine: usprncax
owner: user1@usprncax
permission: gx,wx
date_conditions: 1
days_of_week: all
start_mins: 30
Example: Define a Job to Run Through CA AutoSys WA Connect Option
This example defines a command job to run in CA Workload Automation CA 7 Edition
through CA Workload Automation AE Connect.
insert_job: ca71
job_type: CMD
command: auto_cnct -a A87SOENF -j RYAKEJ01 -c RUN -p SCHEDULE=RYAKE01 -s CA7
machine: A87SOENF
owner: user1@A87SOENF
permission: gx,wx
date_conditions: 1
days_of_week: all
start_mins: 45 Define a Job to Run on an External Instance

Example: Define a Job to Run Directly in CA Workload Automation SE
This example defines a command job to run directly in CA Workload Automation SE.
insert_job: ca72
job_type: CMD
command: RYAKEJ01
machine: A87SOENF
owner: user1@A87SOENF
permission: gx,wx
date_conditions: 1
days_of_week: all
start_mins: 45
Example: Define a Job to Run in Another CA Workload Automation AE Instance
This example defines a command job to run in another CA Workload Automation AE
instance.
insert_job: ca72
job_type: cmd
command: job_in_other_instance
machine: othermachine
owner: user1@othermachine
permission: gx,wx
date_conditions: 1
days_of_week: all
start_mins: 45
This example uses the following configuration:
■ In the machine definition for othermachine, machine_type was set to u, indicating a
machine that runs CA UJMA.
■ The cross-platform interface was activated on the server (where job ca72 is being
submitted) by setting the CrossPlatformScheduling parameter to 1 (run jobs directly
on a CA UJMA agent). If this instance will receive job submissions from any
scheduling manager in the enterprise, set the CrossPlatformScheduling parameter
to 2 (enable bi-directional scheduling support) instead.
■ The CrossPlatformScheduling parameter for the machine othermachine was set to 2
(enable bi-directional scheduling support).
 Define a Cross-Instance Job Dependency



Example: Define a Job to Run on a UNIX Computer
This example defines a command job to run on a UNIX computer.
insert_job: soljob1
command: “@SYS$LOGIN:SCHEDULE_WAIT.COM “
machine: mysolaris
owner: user1@mysolaris
max_exit_success: 1
Note: A job that runs successfully on a UNIX computer returns an exit code of 1. By
default, CA Workload Automation AE interprets an exit code of 1 as a failure unless the
max_exit_success attribute is properly set in the job definition.

Define a Cross-Instance Job Dependency
You can define a job to be dependent on another job that runs on an external instance.
The external instance can be another CA Workload Automation AE instance or a
scheduling manager running on another platform.
To define a cross-instance job dependency, add the following attribute to your job
definition:
condition: status(JOB_NAME^INS) [AND|OR status(JOB_NAME^INS)...]
status
Specifies the status that the external job must have before your job starts. Options
are the following:
■ done
■ failure
■ notrunning
■ success
■ terminated

JOB_NAME
Specifies the name of the external job that the local job depends on.
Limits: The names of jobs specified as job dependencies between CA Workload
Automation AE and CA AutoSys WA Connect Option must follow these guidelines:
■ The first character of a job name must be an uppercase letter (A-Z), a pound
sign (#), an at sign (@), or a dollar sign ($).
■ The remaining characters in the job name can be any combination of uppercase
letters (A-Z), numbers (0-9), pound signs (#), at signs (@), and dollar signs ($).
■ All letters (A-Z) must be in uppercase.
■ Job names can be up to eight characters in length.

INS
Specifies the name of the external instance that JOB_NAME runs on. The name
must be three uppercase alphanumeric characters. The first character must be a
letter (A-Z).
Notes:
■ You can specify multiple job dependencies in a definition.
■ For detailed information about the syntax for the condition attribute, see the
Reference Guide.

Example: Specify a Cross-Instance Job Dependency
This example defines a job that runs only when the following starting conditions are
met:
■ jobA on the same instance returns SUCCESS
■ jobB on the CA Workload Automation AE instance PRD returns SUCCESS
insert_job: dep_job1
machine: localhost
job_type: CMD
command: sleep 100
condition: success(jobA) AND success(jobB^PRD) Generate a Report on an External Instance



Generate a Report on an External Instance
You can generate a report on an external instance to verify the instance configuration is
correct. Generating a report is helpful when you want to check the status of an external
instance during failover. The event details in a report can also help you determine
whether the correct events are waiting for updates from the external instance.
To generate a report on an external instance, enter the following command at the UNIX
operating system prompt or the Windows instance command prompt:
autorep –X external_instance [-q]
-X external_instance
Specifies the external instance you want to generate a report on.
-q
(Optional) Generates a query report, which contains the current job or machine
definition.
The autorep command is issued and the report is generated and displayed.
Note: For more information about the autorep command, see the Reference Guide.

Example: Generate a Report on an External Instance
This example generates a report on the external machine named PRD.
autorep -X PRD
Name Type Server Port
____ ____ _____________________________ ____
PRD a nyc-wall-04 9001 Generate a Report on an External Instance
Example: Generate a Report on an External Instance
This example generates a query report on the external machine named PRD. The report
displays the machine definition.
autorep -X PRD -q
/* ----------------- PRD ----------------- */
insert_xinst: PRD
xtype: a
xmachine: nyc-wall-04
xport: 9001
xcrypt_type: DEFAULT
Example: Export External Instance Definitions
This example uses the autorep command to export all external instance definitions.
autorep -X ALL -q
The output might resemble the following:

/* ----------------- CCT ----------------- */

insert_xinst: CCT
xtype: c
xmachine: WACNCTHOST


/* ----------------- NSM ----------------- */

insert_xinst: NSM
xtype: u
xmachine: NSMHOST Generate a Report on an External Instance




/* ----------------- WAE ----------------- */

insert_xinst: WAE
xtype: a
xmachine: WAAEHOST
xport: 9001
xcrypt_type: DEFAULT


/* ----------------- WEE ----------------- */

insert_xinst: WEE
xtype: e
xmachine: WAEEHOST
xport: 7550
xcrypt_type: NONE
xmanager: WAAEMGR

Example: Generate a Report for All External Instances
This example uses the autorep command to generate a report of all external instances:
autorep -X ALL
The report might resemble the following:
Name Type Server Port
____ ____ _____________________________ ____
CCT c WACNCTHOST 0
NSM u NSMHOST 0
WAE a WAAEHOST 9001
WEE e WAEEHOST 7550