Why do I need a job scheduling package
when similar services (e.g.
cron) are provided free and as standard components in operating systems?
If all you need is to be able to run individual applications either
from your desktop or at specific times and dates, then standard
operating system components will suffice. However, if one or more of the
following requirements apply, then you should consider a job scheduling
package.
The ability to easily apply complex, repetitive and/or variable
timing to unattended job execution, or have jobs run in response to
other types of event
The capacity to define, store and combine any number of complex
execution calendars and be be able to easily apply them to new or
existing application jobs
The facility to pre-define and store job definitions and protect
them with access and many other run-time controls so that they may be
allocated to individual users to initiate and run, without the need to
involve technical or system administration staff.
The requirement to assemble large application runs from any number
of smaller tasks, each task having its own access controls and error
handling with the group of tasks being able to be managed as a whole
(as an entity commonly known as a suite or schedule)
The need for batch jobs to be monitored and logged in detail so
that a full record of all runs is maintained for future audit and/or
compliance studies
The ability to run multi-task applications across several servers
Simplified job definition and runtime controls via a choice of
user interfaces
The requirement to control the number of batch jobs in execution
in order to prevent interactive services from being affected
A suite (job suite) is a collection
of individual application tasks
in which the execution of any particular task is initiated by the
completion of one or more predecessors and whose completion is a
condition for a subsequent task (or tasks) to run. Frequently, the output of a
completed task may be used as the input to another. The suite can be
managed as a whole and the execution of a suite is initiated by the
execution of the head task.
Can we configure all our
batch jobs from a centralized point
while retaining control over the jobs
executing on the remote nodes?
Yes. COSbatch
is a complete network based batch job management product. Jobs can be defined
from anywhere within the COSbatch domain where there is a
standard node (including a central point) and executed on any node in
the domain. Users have full control over their jobs across the network
providing they are authorized to do so.
Can we
build dependencies between jobs and between job suites?
Yes. The precondition
language within COSbatch was designed to allow both job labels and
suite names to be used. This means that a suite or even a job within a suite
can be triggered by the completion of a job in another suite.
Can we set up a batch job
scheduling system to work in a fully heterogeneous environment?
Yes. COSbatch is available for all standard UNIX
variants, Linux and Windows
servers, and has been designed to be fully network based. It is, therefore,
a simple process to configure a network-wide solution.
How can we give operations
staff different views of job requests?
COSbatch users with appropriate rights can view jobs, all jobs
in a given queue, all jobs in a suite and many other options. Custom
views can be generated enabling views to be created according to various
criteria including user, job status or job id.
Can we give users and administrators
different access rights to COSbatch?
Yes. The ability to define
user roles within COSbatch is a standard feature of all OSM products.
The roles are implemented as classes within COSbatch. Each class
is a collection of access and/or resource capabilities. These
capabilities control the access to the interface and individual objects
within the product. By combining various capabilities into named
classes, and then adding a user to a given class, fine control can then
be kept over access to all components.
How do I run a job every Monday
night except for a Public Holiday?
This scenario is easily specified
using the calendar functionality within COSbatch.
Simply define a calendar which specifies every Monday and another calendar
which specifies all Public Holiday dates. Then schedule the job to use the
‘every Monday’ calendar, and set the exclusion dates to be the ‘Public Holidays’
calendar.
This is just one example of the many scheduling options available within
COSbatch. Jobs and job suites can be scheduled to run at regular
intervals (a frequency), or according to a calendar. Calendars enable
jobs to be run at specific times and days. This gives the designer of
the batch schedules a great deal of flexibility.
Batch runs are a very important
part of our business process – how does COSbatch handle system failure?
COSbatch is designed to deliver a high measure of availability.
If a system is down then clearly COSbatch will be inoperative on
that system, but the role of scheduling and executing jobs can be passed
automatically from the Scheduler node to a Control node, should the
Scheduler fail. This allows a COSbatch domain to exhibit a very
high level of availability, ensuring important operational work has a
much greater chance of being run.
COSbatch is available for many Unix operating systems and Linux.
It also allows jobs to be scheduled, controlled and managed on Windows servers
from the COSbatch scheduler node located on a Unix or Linux
system.
The most commonly used of the several user
interfaces available for COSbatch
is the COSbatch User Interface for Windows. The CUIW runs on any Windows®
desktop operating system from Windows 98 onward.
Can we spread jobs across a number of
hosts to spread the load?
Yes. COSbatch is network based and uses queues and logical processors
to distribute jobs across hosts. Jobs can be submitted to queues which use
a number of logical processors that may reside on different hosts.
Will COSbatch tell me
when my job is likely to finish running?
Yes. COSbatch stores the history of jobs that have run and can
calculate the approximate completion time of a job based on its average
previous execution times.
In a network environment
can I control where jobs are run?
Yes. COSbatch has a flexible and sophisticated way to control
any resource within its environment. COSbatch uses a queuing model
where each queue is associated with one or more logical processors. The
processors are defined as pointing to hosts in the COSbatch domain. This
provides the ability to control where a job is run.
Yes. A job will run on the host which has been defined as the processor
attached to the queue to which the job has been submitted. Therefore, to
move a job to run on a different system, you need only move the job to a
queue that is directed to the host that you require.
In our environment,
job requests are submitted by users and applications and some need to be
processed straight away and others can be run later. Will COSbatch
let me run urgent request immediately and run non-urgent requests when CPU
availability permits?
Yes. This requirement can be satisfied with COSbatch
by defining two types of queue, let's call them ‘urgent’ and
‘non-urgent’. The urgent queue is running all the time while the
non-urgent queue receives requests but does not process them. The jobs
on a non-urgent queue are processed when the queue is started. This
can be achieved in different ways, for example:
Manual: COSbatch administrator
Automatic: set up a batch job to start/stop the queue at the appropriate
times of day
Event Driven: Using the COSbatch KM for BMC's PATROL product
to start/stop queues depending on the current system load.
.gif){kind=small}
