Batch

Scheduler
Integration
Oracle Utilities Application Framework (4.4.0.0.0)

Technical Brief / FEBRUARY 2019

DISCLAIMER
The following is intended to outline our general product direction. It is intended for information
purposes only and may not be incorporated into any contract. It is not a commitment to deliver any
material, code, or functionality, and should not be relied upon in making purchasing decisions. The
development, release, and timing of any features or functionality described for Oracle’s products
remains at the sole discretion of Oracle.

2 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

Table of Contents
Introduction .................................................................................................. 6

Batch Scheduler Overview .......................................................................... 6

Scheduler Features ..................................................................................................................... 6

Basic Concepts............................................................................................................................ 7

Management Capabilities ............................................................................................................ 8

Dictionary Views .......................................................................................................................... 9

Scheduler Integration................................................................................. 10

Interface Components ................................................................................................................ 10

Interface Architecture ................................................................................................................. 10

How does the interface work? .................................................................................................... 11

Cancelling Jobs/Threads ............................................................................................................ 12

Advantages of using Oracle Scheduler and the Interface........................................................... 12

Implementation Guidelines ........................................................................ 13

Local or Remote Scheduling....................................................................................................... 13

Configuring Oracle Scheduler..................................................................................................... 14

Setting Up the Oracle Scheduler Interface ................................................ 15

Setting Global Options ................................................................................................................ 15

Run Status Conditions ................................................................................................................ 16

3 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

Schedule Guidelines .................................................................................. 17

General Guidelines ..................................................................................................................... 17

Interface Job Guidelines ............................................................................................................. 18

External Job Guidelines .............................................................................................................. 18

Threadpool Guidelines ............................................................................................................... 18

Job Parameters .......................................................................................................................... 18

Parameter Precedence ............................................................................................................... 19

Set_Option Parameters .............................................................................................................. 20

Soft Parameter Formats ............................................................................................................. 20

Parameter Use Guidelines ......................................................................................................... 21

Resource Optimization ............................................................................................................... 22

Advanced Job Attributes ............................................................................................................. 23

DBMS Scheduler Business Services .......................................................................................... 24

DBMS Scheduler API ................................................................................................................. 24

Frequently Asked Questions ...................................................................... 25

What are the licensing restrictions for the Oracle Scheduler? ....................................................25

What are the licensing restrictions for the interface? .................................................................. 25

How can I set up holiday and daylight savings calendars? ......................................................... 25

Can I use dynamic parameters in my execution? ....................................................................... 25

How can I cancel jobs? ............................................................................................................... 25

4 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

 How can I monitor jobs from the scheduler dictionary views? ....................................................26

How can I restart failed jobs? ..................................................................................................... 26

How can I check my Calendaring Syntax is correct? .................................................................. 27

Can I build a query to view the Oracle Scheduler objects from other users? .............................27

5 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

INTRODUCTION

The Oracle Database Batch Scheduler (DBMS_SCHEDULER) is an efficient

mechanism that allows background processes within a local database or
across an enterprise. Oracle Utilities Application Framework has
implemented a direct integration with the scheduler to allow
implementations to define, manage, monitor and execute scheduled product
batch processes.

BATCH SCHEDULER OVERVIEW Related Materials:

All the editions of the Oracle Database include a database-based scheduler to organize, schedule and • DBMS_SCHEDULER
execute a variety of tasks in the background. In past releases of the Oracle database, this scheduler Reference
was used by database administrators to schedule and automate common database tasks and jobs. • Oracle Scheduler Concepts
Over time the scheduler was expanded to support several types of tasks, therefore support activities
• Scheduling Jobs With Oracle
within the database and related activities. In Oracle Database 12c and above, the Oracle Scheduler Scheduler
has been extended to support a wide range of tasks, enough to support the ability to schedule and
• Administrating Oracle Scheduler
execute Oracle Utilities Application Framework based jobs, via a prebuilt interface.
• Known Issues and Bugs Using
The Oracle Database includes an enterprise wide scheduler to simply the scheduling of background the Scheduler (Doc Id:
jobs. The scheduler is implemented by the DBMS_SCHEDULER package. 1311355.1)

• Overview of Oracle Scheduler

Note: In past releases of the Oracle Database, the job package DBMS_JOBS was available but the (Doc Id: 1485539.1)
DBMS_SCHEDULER package replaces this older package. DBMS_JOBS may be removed in a future • Troubleshooting Assistant: Get
release. Assistance to Understand and
Troubleshoot Oracle
Scheduler Features DBMS_SCHEDULER (Doc Id:
1585228.2)
The Oracle Scheduler is a feature of the Oracle Database that is embedded in every installation of the
Oracle Database. It is used internally by the database and other Oracle products to schedule tasks in
the background. The Oracle Scheduler has the following features:

• Support for wide range of types of jobs. Allows for the scheduling of database program units (i.e.
PL/SQL anonymous blocks, pl/sql stored procedure and Java based stored procedures) as well as
external executables (i.e. applications, shell scripts and batch files). These scheduled objects can
be expressed as reusable programs or individual jobs. These can be mixed across products and
across technologies.

• Support for Local or Remote Execution. Execution of database program units and external
executable locally or remotely using Destinations and related Credentials.

• Flexible Scheduling. Scheduling is flexible with support for one or more of the following scheduling
methods:

– Time based scheduling. Scheduling job based upon dates and times including overlapping
calendars.

– Event based scheduling. Scheduling based upon dynamic events and file arrivals using File
Watchers and other event types including pl/sql events and Oracle AQ based events.

6 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

 – Dependency scheduling. Scheduling based upon job dependencies using Chains.

• Prioritization Support. Job Prioritization is supported based upon class of job and/or the schedule
itself.

• Maximize Reuse. Grouping of resources to maximize reuse.

• High Availability Support. Support for Oracle Maximum Availability Architecture including support
for Real Application Clustering.

• Effective Resource controls. Database resource usage controls using Database Resource Plans
and Windows.

• Native Database Support. Scheduler objects are dictionary objects so can be granted individual
object permissions, if desired.

For more information about the features of the Oracle Scheduler refer to the Oracle Scheduler
Concepts.

Basic Concepts
The Scheduler is a set of processes and objects that are defined and executed within the Oracle
Database. The Scheduler can be implemented within the same database as the product or remotely to
implement enterprise wide scheduling. Refer to Local or Remote Scheduling under Implementation
Guidelines for a discussion of each implementation option.

The lowest object in a scheduler is the Program. A program describes what is to be run by the schedule.
The program object includes a definition of the physical object as well as arguments to execute them.
An instance of a program, is a Job. The job is a collection of metadata that defines the program to
execute as well as where to execute it (for remote executions), its related schedule (which dictates
when it is executed) and any related information.

Jobs are subject to scheduling using the time based, event based and/or dependency of other jobs.
The Schedule object defines when and how many times the job is executed. The schedule object uses
a rich calendaring syntax to define repeating schedules. Jobs also contain data used for prioritizing as
well as resource profiles including support for Windows and Resource Manager.

Jobs can also be executed based upon events. These events can be based upon outcomes of SQL or
most commonly arrivals of files. The scheduler uses a File Watcher to detect when a file has arrived to
trigger the event.

Sequences of jobs expressing the dependencies are represented by Chains. Chains define steps which
link a job or file watcher and contains Rules to decide the sequence and outcomes based upon the
state of another job in the chain. For example, Job B needs to run only if Job A has completed
successfully. Chains can support multiple branches and chains can include other chains for greater
reuse.

The Oracle Scheduler supports remote invocation of jobs using configurations of Destinations and their
related Credentials to access that remote destination. These remote destinations must enable the
Oracle Scheduler Agent which is installed with the Database (for database destinations) or Oracle
Client installation (for non-database destinations).

To maximize reuse, the Oracle Scheduler also supports groups in the form of Destination Groups and
Window Groups.

7 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

A summary of the scheduler objects discussed above is illustrated in the figure below:

PL/SQL Block Program

Rule Step Chain

Job
Event
File Watcher
Schedule

Time

Destination

Credentials

Remote Only

Figure 1. Oracle Scheduler Objects

Management Capabilities
The Oracle Scheduler is maintained using several tools provided by Oracle:

• SQL Interface. At the base level, there is a DBMS_SCHEDULER package which is installed with the
database automatically. This interface is available to be used by any valid direct SQL interface such
as SQL*Plus or equivalent. This interface has a set of subprograms to allow maintenance of the
scheduler objects. This is recommended for Developers.

• Oracle SQL Developer. The Oracle SQL Developer (V4 and above) includes a set of wizards and
functions to maintain the schedule attached to a connected database (including DBaaS instances).
For example:

8 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

Figure 2. Oracle SQL Developer Integration

• Oracle Enterprise Manager. For customers using Oracle Enterprise Manager, there is a browser
interface to maintain the scheduler objects from the Administration menu on the appropriate
database target. For example:

Figure 3. Oracle Enterprise Manager Integration

Whichever interface has been used, will ultimately result in the execution of the DBMS_SCHEDULER
package.

Note: This Technical Brief will generically refer to object creation using the DBMS_SCHEDULER
interface. If an alternative is used, then adjust the advice to suit the tool.

Dictionary Views
The Oracle Scheduler creates a series of dictionary objects that contain the definitions of the various
scheduler objects. These dictionary objects are accessible from a series of views that can be used for
object management, to track progress of jobs for effective monitoring. Refer to the Scheduler Data
Dictionary Views for a detailed description of the views available.

9 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

SCHEDULER INTEGRATION
In Oracle Utilities Application Framework 4.3.0.2.0 and above, the Oracle Scheduler integration
interface was introduced to allow Oracle Scheduler to schedule and execute background (batch)
processes shipped with the product. It is recommended to refer to the Installation Guide, DBA Guide
and Server Administration Guide shipped with your product for additional advice on the interface.

Interface Components
The Oracle Scheduler integration interface is a set of components to implement a simple but powerful
interface reusing the batch infrastructure within Oracle Utilities Application Framework in conjunction
of the Oracle Scheduler. The interface consists of the following:

• Scheduler Administrator. A new database user, SCHADM by default, and set of Oracle Scheduler
roles to maintain and build the scheduler definitions. This user will own the schedule whether the
schedule is implemented locally in the products database or on a remote dedicated scheduler
database.

• OUAF_BATCH PL/SQL package. A database-based PL/SQL package that is installed on the

product database that provides the interface for Oracle Scheduler to invoke and manage product
background processes.

• Special Database objects. A set of database objects used by the interface on the product database
to control executions and set options.

• Permission sets. A set of SQL commands to enable permissions to product tables and individual
objects to implement the interface. As the Oracle Scheduler implements dictionary objects for
scheduler objects, then database object permission rules need to be applied (e.g. GRANT, REVOKE
etc).

The Installation Guide and DBA Guide shipped with your product outlines the installation process for
the scheduler interface.

Interface Architecture
The Oracle Scheduler interface has a flexible architecture that exploits the underlying features of the
product to execute and monitor background processes. From an architecture perspective the following
applies:

• The Oracle Scheduler objects are held as dictionary objects in the Schedule Administrator schema.
At a minimum the Oracle Scheduler uses Programs, Jobs and Chains. Other Schedule objects can
be defined as necessary.

• The Oracle Scheduler interface is installed on the product schema which includes several interface
tables, the OUAF_BATCH pl/sql package and permissions to product batch tables. If the product
database is remote to the Oracle Scheduler database then the Scheduler Agent must be enabled on
the server containing the product database and the appropriate Destinations and Credentials Oracle
Scheduler objects created.

• The product batch architecture must have a batch daemon enabled on one of the threadpools. The
batch daemon will monitor internal batch tables to detect when to initiate batch processes in the
threadpool cluster.

10 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

Note: The batch daemon is not to be confused with online submission which also requires at least one
threadpool to be allocated as a batch server. For Oracle scheduler submission the batch server is not
required to be enabled.

The following figure summarizes the above components:

Oracle Scheduler Product Database

daemon Threadpool

Interface Tables
Threadpool
Scheduler Agent (if remote)

Programs

Chains Threadpool
OUAF_BATCH
Threadpool
Jobs

Threadpool
Other Objects Batch Instance Tables
Threadpool

Figure 4. Oracle Scheduler Integration

How does the interface work?

The Oracle Scheduler Interface allows the submission of product jobs using the provided pl/sql
interface. The interface works in the following way:

• The OUAF_BATCH.Submit_Job procedure is invoked from the Oracle Scheduler within the relevant
job definition either locally or remotely via the destination using the credentials provided. The job can
be part of a chain, manually initiated or because of a successful pre-configured event.

Note: Refer to the Server Administration Guide supplied with your product for details of the
OUAF_BATCH package.

• On the OUAF_BATCH.Submit_Job command there are several parameters that are specified,
including the batch control to execute. Any parameters explicitly or implicitly specified, are subject to
the precedence rules set out in Parameter Use Guidelines.

• The interface creates an entry within the CI_BATCH_JOB object in pending status, with an internal
identifier (generated using the DBMS_RANDOM package). Whilst this identifier is used internally, it can
also be used to cancel the job. The job is created with the following processing:

• Parameters are gathered from the various facilities using the processing sequence outlined in
Parameter Precedence.

• Each thread is individually submitted to the batch cluster to the threadpool specified in the options
or specified in the parameters.

• The batch daemon detects the Pending job entry in the CI_BATCH_JOB and submits the job to the
cluster using the threadpool configuration for the cluster and the threadpool derived for the
parameters for the execution.

11 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

• The interface waits for the job to complete, using the polling interval, and sends back the status of
the job as an evaluation of the state of individual threads of the job. Refer to Run Status Conditions
for additional advice in this area. This state is expressed as a state used by the scheduler.

Cancelling Jobs/Threads
Whilst in most of cases the execution of a scheduled job will be handled automatically, it may be
necessary to cancel a job or chain for some business or technical reason. The process of cancellation
will differ depending on the execution state of the job:

• If the job has not been executed yet, then use the STOP_JOB on the chain or pause the chain using
the DBMS_SCHEDULER package (directly or via the SQL Developer/Enterprise Manager interface).

• If the job is executing, then use the Cancel_Job procedure within the OUAF_BATCH package
specifying the Batch Control or generated job identifier to cancel the job. This can be issued from
any SQL compliant tool against the product database. Refer to the Server Administration Guide
supplied with the product for more information on the command line. The threads for the job will be
cancelled when the next poll of the status is performed according to the global poll interval.

When a running job is cancelled the identifier of the connection is attached to the cancellation for audit
purposes. This information is accessible from the batch run tree.

Advantages of using Oracle Scheduler and the Interface

The Oracle Scheduler interface is to provide a method for implementations to use the Oracle Scheduler
facility inbuilt within the Oracle Database to schedule and manage their batch processes. Typically,
before this interface, implementations would have to use a command line interface with other
technologies including third party schedulers to schedule and manage their batch processes.

The Oracle Scheduler and Oracle Scheduler interface have many advantages over the command-
based interface:

• License free implementation. The Oracle Scheduler is provided in all editions of the Oracle
Database and is included in existing licenses. No additional licensing is required no matter how much
of the scheduler is used, how it is deployed or how many jobs are managed by the scheduler. This
assumes that the database housing the scheduler is already licensed.

• Less Administration. In the command-based utilities, parameters are either on command lines
and/or external properties files. This means any changes to the batch control by the business need
to be reflected in the properties files which is an additional administration step.

• Flexible Administration. Oracle supplies a set of flexible administration methods to the Oracle
Scheduler which can be command based, DBA tool based (via Oracle SQL Developer) or via Oracle
Enterprise Manager.

• Flexible implementation models. The Oracle Scheduler can live with the product or externalized
for centralized scheduling support. This implementation can be mixed as well with some
environments having local copies of their schedules and other environments sharing a global
scheduling instance.

• Increased Use of the Batch Controls. The Oracle Scheduler interface uses the Batch Control
parameters directly which mean that authorized users can maintain the parameters from the
business, local support or your IT personnel. The Batch Control maintenance function is subject to
authorization rules within the product.

12 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

• Supports High Availability. The Oracle Scheduler respects your database high availability solution
supporting such technologies as Real Application Clusters (RAC) and Oracle Data Guard.

• Reuse of Resource Profiles. Resource Profiles are supported in the Oracle Utilities Application
Framework which can be shared with the Oracle Scheduler to automate resource usage for
scheduling.

• Maximum Flexibility. The Oracle Scheduler can schedule simple and complex chains with flexible
scheduling.

• Dynamic parameter support. Additional packages may be developed to dynamically determine

values at runtime.

The existing command line interface will continue to be supported and enhanced to give
implementations an alternative option if desired.

IMPLEMENTATION GUIDELINES
The Oracle Scheduler can be implemented in any number of ways to suit the way you want to use it
and the scope of the jobs managed by the scheduler. This section outlines some basic implementation
principles that may assist in the effective implementation of the scheduler. Also refer to the Additional
Resources outlined earlier for additional advice.

The Oracle Scheduler is popular with Oracle customers and is used in some of the Oracle products
that you may use already. There are lots of resources available with advanced advice that can be
access using an appropriate search engine using the terms Oracle Scheduler or DBMS_SCHEDULER.

Local or Remote Scheduling

One of the major decisions to make in implementing the Oracle Scheduler is whether you want to
implement local scheduling (within the product database only) or enterprise wide scheduling (i.e.
remote scheduling). This will affect how the scheduler is configured and how the interface is installed
and configured.

Before discussing the implementation implications, it is important to understand the advantages and
disadvantages of the local and remote architecture:

• Oracle Scheduler can manage and schedule many types of jobs which can include database jobs
(such as backups), external jobs and interface jobs needed for an implementation. These jobs can
be housed in separate chains or integrated with product specific chains. Typically, it is recommended
to consider implementing Oracle Scheduler remotely as it makes it independent of the product and
provides an enterprise wide resource to implement these additional jobs.

• Implementing Oracle Scheduler remotely, in enterprise wide mode, does mean additional
configuration within the scheduler. The Oracle Scheduler Agent must be installed and active on any
server where work needs to be scheduled. Within the scheduler objects, each remote location must
be defined as a destination and the appropriate credentials of the job type must be configured so
that the scheduler can access the resources remotely. While enterprise scheduling is supported, it
is only recommended if this extra configuration is not burdensome.

• Implementing Oracle Scheduler locally is easier to configure, as it avoids destinations and agents,
and focuses on scheduling the product jobs. The schema would be housed in the product database
using a different schema owner.

13 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

• It is recommended that the scheduler objects be housed in a separate schema regardless of the way
the scheduler is implemented. It is not recommended to house the schedule in the product schema
as this may adversely affect upgrade processes and reduce flexibility in the solution.

The following guidelines should be considered when deciding to use local or remote scheduling:

• For non-production environments typically, local installation is recommended as each environment

needs to be isolated in terms of various testing and implementation activities. Attempting to use a
centralized enterprise wide scheduler across many environments overly complicates the schedule
configuration.

• If your implementation is primarily using the scheduler for product jobs (and some simple associated
jobs) then consider using a local installation on the product database to avoid the extra effort in
remote management.

• If your implementation is considering enterprise wide scheduling, then the database agent on the
database server for the product must be configured and started. The product database must be
defined as a destination and the product user must be used as credentials. For Oracle Utilities
Application Framework V4.x and above customers, it is recommended to use the credentials
represented in the BATCH_DBUSER and BATCH_DBPASS configuration settings as credentials to
isolate batch processes for monitoring and take advantage of common resource plans, if used.

Ensure the BATCH_DBUSER has access to the OUAF_BATCH packages within the product schema.
Refer to the Installation Guide and DBA Guide shipped with your product for more advice.

It is possible to add custom jobs of several types into any schedule managed by the Oracle Scheduler.
Refer to the Oracle Scheduler Concepts for additional advice in this area.

Configuring Oracle Scheduler

One of the first steps in the implementation is configuring the Oracle Scheduler with the following global
settings:

• Set the default time zone. The schedule engine uses a default time to align schedules. This can be
overridden using the calendaring syntax for individual jobs and/or chains.

• Set the email attributes. One of the optional features is to configure an email server with various
settings that allows an email to be sent according to the specifications on the job or chain. The
interface supplies an OUAF_NOTIFY that is used as the default job to send the email, if necessary.
The attributes to specify include the email server URL, email server credentials and optional email
encryption settings.

• Set the event expiry time (in seconds). The Oracle Scheduler holds the state of any job for a
period to be used by the scheduler to cover long running processes or multi-day processes. The
state is held within the scheduler dictionary for use by the scheduler.

• Set log history retention period (in days). The Oracle Scheduler includes a basic log facility that
is retained in the dictionary views for perusal. Refer to the Monitoring Jobs for more details of the
logs. It is possible to set the period within the dictionary views on how long these records are retained
for analysis. This information can be set globally or set via Job Class.

The event expiry time and log history retention period only apply to the dictionary objects used by the
Oracle Scheduler. They do not apply to the data held in the batch run tree or the logs generated by the
batch jobs themselves. These are managed separately as outlined in the Server Administration Guides
shipped with your products.

14 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

It is possible to purge scheduler logs manually by creating a job with the
DBMS_SCHEDULER.PURGE_JOB procedure.

SETTING UP THE ORACL E SCHEDULER INTERFACE

The Oracle Scheduler Interface is a set of SQL files that implement a pl/sql based interface to submit,
cancel etc product jobs. It is installed as outlined in the Installation Guide that is provided with the
components summarized in the Interface Components section. This section outlines some techniques
that can be useful for implementing the scheduler interface.

Setting Global Options

One of the first steps is to set the global options for the interface as well as global parameters that will
be used as defaults on executions.

Note: Refer to the Set_Option API documented in the Server Administration Guide supplied with
your product for additional advice

The following parameters are set using the Set_Option procedure of OUAF_BATCH using the
GLOBAL scope:

• Business Date (business_date). Set the global business date which will be used as the default
for all executions. Setting this value ensures the business date is used consistently across chains
regardless of time of day or date. If used, it is highly recommended to set this value at least once a
day either at the start of a chain or as part of an independent process. This value can be overridden
on individual jobs.

• User Identifier (user_id). This is the global authorization user within the product that will be used
for permissions of underlying objects. It is also used to mark any records created or modified by the
process for auditing purposes. This value can be overridden on individual jobs.

• Poll Seconds (poll_seconds). How often the interface will check with the product on the state of
the job. This poll interval will also determine how often a job cancel request will be checked for.

• Notifications (thread_notifications). Whether an email notification for failed threads will be

sent.

Note: By default, an individual thread that ends in error will trigger notification job OUAF_NOTIFY.
This is independent of the job's overall status (for all threads) or the raise_error option. Triggering
a notification for a thread in error allows the user to correct the problem and resubmit that thread
without interrupting the overall flow of the chain. The job will wait indefinitely for the job to reach the
status defined by min_run_status, so individual threads can be restarted while this condition is
not true. To disable it, set thread_notifications to false, but be aware that the job may then
appear to be running while it is in fact waiting for a thread to be resubmitted, so it is a clever idea to
keep an eye on the Batch Run Tree to monitor the threads.

• Default Thread Pool (thread_pool). The default threadpool if no threadpool is set for the
individual job.

• Discard Queue (discard_queue). Determines whether all unused online job queue entries are
removed. This is housekeeping for the interface to prevent batch instance records from overloading
the system. This does not affect batch run tree information.

15 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

• Debug Mode (debug). This sets a debug mode used for development purposes only.

• Single Submitter (single_submitter). By default, set to false, the interface submits a multi-
threaded job one by one. In implementations where there are many threads, this can cause
excessive lock contention on the Batch Control table. Setting this value to true will reduce lock
contention on a multi-threaded job.

For example:

begin

OUAF_BATCH.Set_Option(scope => 'GLOBAL', name => 'user_id', value =>

'FRED01');

end;

There are several guidelines when setting these options:

• Consider setting the user_id and thread_pool to appropriate settings for your site. These can
be overridden on individual jobs as necessary.

• Leave most of the settings on the defaults unless the defaults are not appropriate for your site.

• To avoid long term storage issues consider leaving discard_queue to true to allow the interface
to manage its entries automatically. The records managed are internal only typically as the Batch
Run Tree information is not altered by this change.

• The notification engine used in the interface works only with failed threads. If this is not appropriate,
then disable the notifications from the interface and use the notification settings on individual jobs to
set your notification preferences. The format of the email can be altered per job if necessary with
appropriate events. For example:

Run Status Conditions

By default, the interface will wait for the run to end in COMPLETED status, use min_run_status on
Submit_Job to override the status on which it can end. For example, if it is acceptable to end with
errors, specify min_run_status => OUAF_BATCH.RUN_STAT_ERROR.

Set raise_error to true to make the procedure raise an application error and end if the job ends
with that min_run_status. For example, to stop if a job ends in error, specify min_run_status =>
OUAF_BATCH.RUN_STAT_ERROR, raise_error => true.

Note: Option raise_error => true is not valid for min_run_status =>
OUAF_BATCH.RUN_STAT_COMPLETED.

There are several statuses in the interface:

State Values

STATE COMMENTS

RUN_STAT_PENDING Pending Status which is the initial state for all jobs before they execute.

RUN_STAT_IN_PROGRESS Job has started executing but is not completed.

RUN_STAT_ERROR Job completed with errors

16 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

 RUN_STAT_COMPLETED Job completed successfully

Refer to Event Types Raised by the Scheduler for additional notifications events.

SCHEDULE GUIDELINES
The important aspect of implementing Oracle Scheduler is designing your scheduling solution that will
effectively schedule and manage your batch processes. The Oracle Scheduler is flexible and allows
chains to be designed to suit not only the raw dependencies but also to mirror your individual style of
IT management. In effect, there are typically many ways of achieving the same results. This section
will outline some general and specific techniques that can be used to build, maintain, operate and
optimize your scheduling objects.

General Guidelines
The Oracle Scheduler is powerful, flexible and has a wide range of capabilities. Whilst those capabilities
can be used with the interface there are several general guidelines that should be considered:

• Avoid using lightweight jobs for product jobs. The LIGHTWEIGHT job type is not recommended
for use with Oracle Utilities Application Framework based jobs.

• Avoid using detached jobs for product jobs. Detached jobs are processes that typically spawn
other processes that are independent of the scheduler. Avoid using that with product jobs.

• Respect the naming conventions of the objects. As the scheduler objects are dictionary objects
they are subject to Oracle dictionary naming conventions. For example, the Batch Controls contain
the "-" character and/or reserved words. These cannot be used in the object identifiers, such as Job
identifier. It is recommended that if you wish to use product identifiers, such as batch control
identifiers, then substitute "_" for the "-" character and prefix any reserved words to avoid naming
errors.

• Avoid loops in chains. One of the most common issues in scheduling, including within Oracle
Scheduler, is recursive chains. These are chains that loop back potentially causing an endless loop.
Avoid loops as much as possible.

• Ensure all jobs in a chain are linked. Each chain has a start and ending event job. Jobs within a
chain typically have predecessors and successors. In some chains you may have jobs that have no
predecessors or successors. It is recommended that these jobs be connected to either the start
event, if the job does not have predecessors and to the end event if they do not have successors.
Whilst, this is not required for execution it ensures all processes in a chain are started and complete
before the chain itself is complete.

• Start simple and alter as necessary. When designing a chain, it is always a pitfall to try and get it
setup fully featured schedules in the Oracle Scheduler. Most of the optimized chains tend to be
optimized over time to reflect ever changing business needs. The best approach is to start with the
simple dependencies and adjust those dependencies over time and add resource management after
examining the progress of the chain. This will then truly optimize the chain.

• Prioritization. It is possible to implement a chain with no prioritization. Prioritization allows for

possibilities in resource optimization amongst jobs. Refer to Resource Optimization for techniques
that are applicable to prioritization.

17 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

• Number of Chains. Create chains for processes that need to be scheduled together and/or related
to business processes. Chains can reference other chains, known as child chains. Child chains
should only be created if those child chains are shared across multiple chains.

• Ensure objects are enabled. Ensure your scheduler objects are enabled before they are used. The
Oracle Scheduler will ignore objects that are not enabled. You can disable a job to alter it and then
set enabled to true when edits are complete.

Interface Job Guidelines

One of the most common extensions to the product chains is the integration of jobs that process data
exported from the product or load data into the product. The following guidelines are applied when
including these jobs in chains:

• If the interface job is built using the same technology as the product, the batch control will be setup
and the OUAF_BATCH interface can be used the same as product jobs within the chain.

• If the interface job is built on different technology than the product the job can be setup as an External
Job within the chain. Refer to the External Job Guidelines for additional advice.

• If the job requires an event then use File Watcher, or general events as the attribute on the job.

• If the interface job is one that loads data into a staging table, then the next job in the chain is
recommended to be the product job that processes that loaded staging data.

• Interface jobs should be named appropriately.

External Job Guidelines

Oracle Scheduler 12 and above, supports external jobs that can execute scripts or executables. When
creating external jobs, the following guidelines should be considered:

• Destinations and Credentials. The job should be linked to the machine and operating system
credentials for the server that is running the process. It is possible to set global credentials in the
scheduler agent.

• Running Scripts. If the script is run using the product environment variables, then prefix the
command with the splenviron[.sh] -c <command> where the <command> is the command to
execute.

Refer to Techniques for External Jobs for additional advice.

Threadpool Guidelines
The Oracle Scheduler interface does not support the execution and stopping of batch threadpools. This
is intentional as the management of thread pools can be performed from many options including cron,
Oracle Enterprise Manager etc. If the scheduler, is to be used to start and stop the thread pools then it
is recommended that the thread pools be managed using an external job. Refer to the External Job
Guidelines for advice.

Job Parameters
The scheduler interface allows for flexible implementation of parameters to batch jobs. The parameters
can be specified in several formats:

18 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

• Global Options. It is possible to set global defaults which can be overridden on individual jobs. Use
of these global options can reduce the maintenance for parameter management.

• Batch Specific Options. It is possible to provide specific parameters at the batch control level using
several techniques, described in the Parameter Precedence section.

• Command Line Overrides. For maximum flexibility, it is possible to override parameters at the
command line level to support advanced situations and special executions.

Implementations can use a combination of these options for their chains.

Parameter Precedence
The parameters for the scheduler interface are assessed in the following order (lower levels can
override upper levels):

• OUAF_BATCH defaults. The OUAF_BATCH interface sets a base set of parameters as indicated in
the Server Administration Guide supplied with the product.

• Global Options. It is possible to set options at the global level using the OUAF_BATCH.Set_Option
procedure with the GLOBAL scope. Refer to the Server Administration Guide supplied with the
product for details of the options that can be set.

• Batch Control settings. It is possible to set parameters for each product batch job on its associated
Batch Control record. Refer to the online documentation for details of the parameters that can be set
for individual batch jobs.

• Batch Specific Options. It is also possible to use the OUAF_BATCH.Set_Option procedure with
the scope set to the values of the Batch Control to set the options. Refer to the Server Administration
Guide supplied with the product for details of the options that can be set.

• Command Line Parameters. At the lowest level it is possible to override parameters at the
command line level using the parameters on the OUAF_BATCH.Submit_Job procedure. This level
supports several formats to specify the parameter for flexibility.

The following figure outlines the precedence:

19 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

Figure 5. Parameter Precedence

Set_Option Parameters
As part of the OUAF_BATCH package a procedure Set_Option is provided to set options for global
and the batch job levels. The options supported configure the behavior of the interface for the execution
of jobs as well as provide options for common parameters across jobs.

The procedure requires three parameters to set the options:

• Scope. The scope of the setting needs to be provided. For global options use the value GLOBAL and
for batch job specific options then specify the Batch Control Identifier.

• Option Name and Option Value. The option to set and the value to set it to for the option. Refer to
the Server Administration Guide shipped with your product for a full description of the options that
are available.

The values can be removed as options using the OUAF_BATCH.Unset_Option procedure. Refer to
the Server Administration Guide shipped with your product for more information about that procedure.

Soft Parameter Formats

Note: This facility uses the PL/SQL collections feature.

The parameters of a job can be specified on the command line using multiple formats for maximum
flexibility. The parameters may be specified in two formats:

20 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

• Associative Array (soft_parm_map). This allows the parameters to be specified before the
OUAF_BATCH calls, using the OUAF_BATCH.parm_map_t type. This is ideal where dynamic
calculation is required for the parameter and there may be a relationship between values. An
example of this format is:

declare

my_soft_parms OUAF_BATCH.parm_map_t;

begin

my_soft_parms('maintenanceObject') := 'F1-SYNC REQ';

my_soft_parms('isRestrictedByBatchCode') := 'true';

OUAF_BATCH.Submit_Job(batch_code => 'F1-SYNRQ',

user_id => 'MYUSER',

soft_parm_map => my_soft_parms);

end;

• In Memory Table Array (soft_parm_list). This is a table array of parameters and values. It is
specified as a list of name and value pairs. This may be convenient for jobs where the parameters
need to be directly specified in the job call. In this format the parameters must be of the type
OUAF_BATCH.parm_list_t. An example of this format is as shown:

begin

OUAF_BATCH.Submit_Job(

batch_code => 'F1-SYNRQ',

user_id => 'SYSUSER',

soft_parm_list =>

OUAF_BATCH.parm_list_t('maintenanceObject','F1-SYNC REQ',

'isRestrictedByBatchCode','true'));

end;

Both formats can be used in the same call. In this case, the soft_parm_list format may override
values set in the soft_parm_map.

Parameter Use Guidelines

There are several guidelines when using parameters:

• Set parameters at global level and use overrides for exceptions. To save maintenance costs it
is recommended to set the parameter at higher levels and only specify parameters at the lower levels
when overrides are necessary.

• Batch Controls are key for business parameters. The batch control object should be used to
maintain batch control specific business settings.

21 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

• Set the default user_id as a GLOBAL option. To minimize maintenance set a global default valid
user for authorization for batch processes.

• Use the business_date GLOBAL option for handling past midnight scheduling. One of the
general issues in scheduling is the setting of a consistent business date for a chain. If the system
date is used, then if the chain extends over the midnight boundary then jobs past midnight may use
different business dates from those jobs running before midnight. To run a consistent business date,
it is recommended to set the business_date at the start of the chain using the GLOBAL option. For
example:

/* Sets the date to system date */

begin

OUAF_BATCH.Set_Option(scope => 'GLOBAL',

business_date => to_char(sysdate,'YYYY-MM-DD')

);

end;

/* Sets date to a specific date */

begin

OUAF_BATCH.Set_Option(scope => 'GLOBAL',

business_date => to_char('1990-08-04','YYYY-MM-DD')

);

end;

• Set a command line standard. If you want to specify parameters on the command line, decide on
the format that is comfortable for your implementation. For supported formats refer to the Soft
Parameters Formats for a discussion on supported formats.

Resource Optimization
Note: The use of resource optimization is optional but can be useful for flexibility in scheduling and
prioritization.

One of the techniques to use with the scheduler is resource management to implement prioritization
and management of resources. The key component of this is the ability to specify a set of resource
objects to control the jobs or chains use of database resources to optimize your schedule.

The product supports the use of resource manager at the connection level (including the session
variables as documented in the Server Administration Guide provided with your product). The resource
plans and other resource objects can be created independently of the schedule to control resources at
a global level. If the scheduler needs to use these resource objects they can be specified at the
following levels:

• Job Class. It is possible to set the resource plans for the group of jobs allocated a specific job class.
This is a general optimization technique to group jobs into resource groups that can be allocated

22 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

 appropriate use of resources. Within a job class, the job priority is used for concurrently executing
jobs.

• Windows. It is possible to design windows which control which resource plan is used at specific
times. For example, it may be possible to create windows that define peak and non-peak times that
allocate different resource objects to control resources between different channels. These windows
are then allocated to schedules which are used for scheduling chains and/or jobs. It is also possible
to create several windows and group them as Windows Groups to allocate multiple windows to the
schedule.

There are a few guidelines when using resource management:

• Optional. The use of resource management is optional. In this case all jobs in the scheduler are
treated with the same overall resource plans and overall priority.

• Keep it simple. The Job priority (job_priority) attribute of the jobs is a simple method of
prioritization. All jobs within the same job class, that run concurrently are treated the same unless
the job priority is used where the jobs with the highest priority (the value of the job_priority
parameter is lower) are given execution priority over other concurrent jobs in that class. Use of job
class with resource profiling is the simplest method after using priority.

• Use Windows for complex situations. If your schedules are all over the time period and overlap
with other channels it is recommended to use Windows for resource management to prevent one
channel taking over resources reserved for another. An example of this is the balance between online
and batch. If you need to run batch during peak online hours, then batch will potentially cause
contention issues if run without any resource management. In this case, it may be appropriate to
create a set of windows that describe peak and non-peak periods for online transactions and define
appropriate values for online and batch. This can ensure batch is kept within resource limits to
minimize contention during peak periods and given more resources at non-peak times.

Refer to Managing Resources with Oracle Database Resource Manager and Using the Database
Resource Manager to Manage Database Server Resources (Doc Id: 2067783.1) available from My
Oracle Support for more information.

Advanced Job Attributes

The Oracle Scheduler includes several advanced parameters that can be set on the individual jobs.
Whilst these can be used their use should be only considered if they are used to satisfy your individual
requirements.

Refer to the JOB_DEFINITION for additional advice.

Job Attributes

PARAMETER DEFAULT COMMENTS

auto_drop FALSE Drop the internal scheduler objects after the job
has completed.

event_spec null Event condition for event-initiated jobs.

follow_default_timezone FALSE Determines whether the job follows changes to the

time zone or not.

job_priority 3 Priority of job used by scheduler. Refer to

Prioritizing Jobs for more advice.

23 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

 job_style REGULAR Style of Job. For product jobs use REGULAR.

logging_level LOGGING_OFF Level of logging used within scheduler. This does

not affect the logging used by the product.

max_failures null Specifies the number of times a job can fail on

consecutive scheduled runs before it is
automatically disabled.

max_run_duration null Specifies the maximum amount of time that the

job should be allowed to run. If exceeded, then the
JOB_OVER_MAX_DUR event is raised.

max_runs null Specifies the maximum number of consecutive

scheduled runs of the job. Once max_runs is
reached, the job is disabled and its state is
changed to COMPLETED.

parallel_instances FALSE This is used for LIGHTWEIGHT jobs only. Not

recommended to change.

queue_spec null File watcher name or queue specification for

event-based jobs.

restartable FALSE This setting does not apply to product jobs as the
Restart_Thread API within OUAF_BATCH is
available.

schedule_limit null In heavily loaded systems, jobs are not always

started at their scheduled time. This attribute
enables you to have the scheduler not start a job
at all if the delay in starting the job is larger than
the interval specified.

stop_on_window_close FALSE Indicates whether the job should be stopped when

the window it is running in ends.

store_output TRUE Specifies whether job details are logged in

scheduler dictionary objects.

DBMS Scheduler Business Services

In Oracle Utilities Application Framework V4.3.0.4.0 and above several business services were added
to the product to allow direct integration with a local installation of the Oracle Scheduler. These
business services may be used by implementations to directly interface with the Oracle Scheduler from
an extension (using any of the valid development languages supported). They are prefixed with the
F1-DBMS* characters.

DBMS Scheduler API

Note: The API provided does not cover ALL the scheduler objects available in the Oracle Scheduler.
The interface is only meant for simple interactions with the scheduler. For more detailed management
of the schedule it is recommended to use Oracle SQL Developer or Oracle Enterprise Manager.

Note: These API’s will only work when the scheduler objects are housed in the same database as the
product. Remotely implemented schedulers or remote objects are NOT supported.

24 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

A key number of API’s are available for managing scheduler objects and extracting metrics from the
scheduler. These are exposed as Business Services with attached schemas to outline the API
interface. These can be called directly from other objects, exposed as Inbound Web Services or called
via the REST API provided with the Oracle Utilities Application Framework.

Note: Refer to the Server Administration Guide for details of the Scheduler API's available for your
version of the Oracle Utilities Application Framework.

FREQUENTLY ASKED QUESTIONS

These are a common set of questions that typically are asked within implementations.

What are the licensing restrictions for the Oracle Scheduler?

The Oracle Scheduler is included in all editions of the Oracle Database and is included in the base
license. It is used internally by the database and other Oracle products already. All rules and limits are
documented in the Oracle Database documentation.

What are the licensing restrictions for the interface?

The interface is included in Oracle Utilities Application Framework V4.3.0.2.0 and above. All products
on those releases can use the interface for scheduling and executing any product jobs that are built
using Oracle Utilities Application Framework technology. There is no restriction on numbers of jobs,
number of chains, number of destinations etc.

How can I set up holiday and daylight savings calendars?

Yes, it is possible to set up multiple schedule calendars within the scheduler to include or exclude dates
and times. This is documented in the Operational Notes for the Oracle Scheduler. Daylight savings
support is covered by the daylight savings time support for the Oracle Database that is holding the
scheduler objects.

Can I use dynamic parameters in my execution?

Yes. It is possible to include dynamic parameters in your job parameters when using OUAF_BATCH.
It is recommended that the procedure be written in pl/sql and be available to the product schema
running the job to ensure it does not cause the job to fail. For example, say a pl/sql procedure
cm_determine_date was available to dynamically return the date based upon some data in the
database or relevant source. To use this in the OUAF_BATCH command line would be:

begin OUAF_BATCH.Submit_Job(batch_code => TEST',

business_date => cm_determine_date()

);

end;

Note: To use external procedures, ensure the product user used for the interface has appropriate
access to those procedures within the product database. Ideally, these procedures should be owned
by the database user used for executing the jobs to avoid permission issues.

How can I cancel jobs?

25 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

There are several techniques to cancel a running job:

• Using the OUAF_BATCH.Cancel_Job interface. It is possible to stop a running job and/or thread
using the Cancel_Job procedure. This will sent the job to a cancelled status and on the next poll
interval, cancel the job and/or thread from the batch cluster. After all threads are cancelled the job
will register the cancellation in the Batch Run Tree (with the conditions of the cancellation). Refer to
the Server Administration Guide for more information about the Cancel_Job interface.

• Using the JMX interface. It is possible to cancel a thread using the JMX interface using jconsole,
jmxbatchclient[.sh] or Oracle Enterprise Manager with the Application Management Pack for
Oracle Utilities. Refer to the Server Administration Guide for more information about this interface.
As with previous interfaces, the Batch Run Tree will record the relevant information of the
cancellation.

• Using SQL interface. This interface is not recommended and should only be used as a last resort,
but it is possible to stop the jobs using the SQL:

UPDATE CI_BATCH_JOB

SET BATCH_JOB_STAT_FLG = 'CA'

WHERE BATCH_CD = '<batch_control>'

AND BATCH_JOB_STAT_FLG = 'ST';

COMMIT;

where:

<batch_control> is the batch control identifier to stop

EFFECTS ON CHAINS

Depending on the setup of the chain rules the chain will react differently to a job cancellation:

• If the chain rule has an end condition for a FAILED execution, then the chain will stop executing.

• If the chain rule is setup for a SUCCEEDED execution, the default, then the chain will be in a
STALLED state and must be manually set to resume.

• If the chain rule is setup for COMPLETED execution, then the next job in the chain will be executed.

Note: Avoid using the DBMS_SCHEDULER.stop_job procedure as while it will stop the chain it will
not stop the execution of the underlying process as the interface does not permit a call back to support
remote jobs. Use the OUAF_BATCH.Cancel_Job instead to avoid issues as that interface will stop the
job and send the FAILED status to the chain.

How can I monitor jobs from the scheduler dictionary views?

The Oracle Scheduler includes several views that can be used to monitor jobs that are executing.
These are documented in the Monitoring section of the scheduler documentation.

How can I restart failed jobs?

The majority of product jobs have the ability to restart. To restart a batch job means submitting a job
that previously ended in error, with the expectation that it would resume from where the previous

26 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

execution had ended. The product framework keeps track of a job while it runs so that it can be easily
and automatically restarted if needed.

It is recommended to use the OUAF_BATCH.Restart_Thread job to restart the thread of the job
correctly. Do not use the OUAF_BATCH.Submit_Job as this may result in duplicates in the scheduler.
Refer to the Server Administration Guide for more information about these interfaces.

Use OUAF_BATCH.Restart_Thread to restart a single thread of an already-running job. This will

submit that thread so that it joins the Submit_Job procedure that is in progress. If it is not running but
in error status, OUAF_BATCH.Submit_Job will restart the threads that need to be restarted.

How can I check my Calendaring Syntax is correct?

The calendaring syntax is quite powerful and can model very complex calendars for scheduling. If the
calendaring sequence is complex then it is possible to look at what dates/times are valid for the syntax
using the DBMS_SCHEDULER.EVALUATE_CALENDAR_STRING procedure. Refer to the
DBMS_SCHEDULER documentation on this facility including examples.

Can I build a query to view the Oracle Scheduler objects from other users?
While the Oracle Scheduler stores its objects in the dictionary supplied within the Oracle database and
that dictionary is accessible from views it may not be possible to create a view to query the scheduler
objects. Since the scheduler objects are stored as dictionary objects they are subject to database
security rules. For one user to see another user's objects they must be granted appropriate
permissions. An example set of permissions are outlined in Setting Oracle Scheduler Privileges section
of the Oracle Scheduler documentation. There are several recommendations:

• Permissions are set at database user level NOT product user level. Each product channel can have
different database users if desired. For each user to access the scheduler objects for the scheduler
user they must be granted permissions on individual objects.

• Avoid granting SCHEDULER_ADMIN role to users. It is a powerful role that should be treated as akin
to the DBA role.

• All scheduler objects used in GRANT should be fully qualified to avoid issues. Typically, scheduler
objects will be prefixed by the Scheduler administrator account. Refer to the GRANT statement for
full list of Job Scheduler Objects that are managed.

• Any dictionary views should use the USER, ALL or DBA prefix. If the user that owns the objects is
used for the query, then use the USER version of the view otherwise use the ALL version of the view
with the appropriate OWNER value.

The following summary of the subset of dictionary associated with the Oracle Scheduler is listed in the
Scheduler Data Dictionary Views section of the Administrating Oracle Scheduler documentation.

27 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)

28 T e c h n i c a l B r i e f / Batch Scheduler Integration - Oracle Utilities Application Framework (4.4.0.0.0)
ORACLE CORPORATION

Worldwide Headquarters
500 Oracle Parkway, Redwood Shores, CA 94065 USA

Worldwide Inquiries
TELE + 1.650.506.7000 + 1.800.ORACLE1
FAX + 1.650.506.7200
oracle.com

CONNECT W ITH US
Call +1.800.ORACLE1 or visit oracle.com. Outside North America, find your local office at oracle.com/contact.

blogs.oracle.com/theshortenspot linkedin.com/in/theshortenspot twitter.com/theshortenspot

Copyright © 2007 - 2019, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the contents hereof
are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed
orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This document may not be
reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or
registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of
Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0219
Batch Scheduler Integration - Oracle Utilities Application Framework
February 2019