(Click on images for higher definition view)
The cosbatch Scheduler is an instance of a cosbatch Server that manages all the object data (data about queues, processors, calendars, for example) in a cosbatch domain and performs all the scheduling of jobs and suites. If considerations of throughput and resilience indicate it, more than one cosbatch Server may be installed. In this configuration, the cosbatch object data can be distributed between the instances of the cosbatch Servers, and one or more Servers may be designated as Control (FailOver) Hosts.
The logical configuration of cosbatch is simple and can be understood by reference to the diagram below in which the main cosbatch structural objects are shown. In cosbatch terminology, the main structural objects are called resources and consist of queues, processors, and calendars.
There are, in addition, cosbatch objects which are used for user access control. These are users, roles, and capabilities.
When cosbatch is operational, applications or users submit jobs to queues. Users may be either actual, logged-on interactive users or applications that have been set up to use cosbatch as their background processing engine. Every batch job is scheduled in an appropriate queue to arrive at its chosen processor(s) in accordance with the attributes that have been assigned to it. Queues may be used to organise jobs by the users, department or the application responsible for those jobs, or by the target CPU architecture, or a target application which will be needed to dispatch them.
When configuring a cosbatch domain, administrators can set up any number of queues and give them names that are useful in the context of their business. Any naming convention is possible so, for example, queues may be named according to the department they serve, a processor at which the queue is targeted, or after the type of job that they will be used to schedule.
Each job attached to a queue has a queuing priority. Two jobs on the same queue which become ready to execute simultaneously will be released for execution in priority order. Queues are normally open to receive jobs (but may be closed to the definition of new jobs). Queues are normally running (but may be stopped to prevent them from delivering jobs to execution).
Although a processor is a logical object in the structure of cosbatch, it is of course closely related to a physical unit. Many logical processors may be attached to the same physical processor. Multiple processors may be assigned to a queue and multiple queues can share a processor.
The definition of a “processor” is flexible. A processor may be the CPU resources of a single machine; it may be a sub-set of the total count of CPUs in a multiple-CPU system; or it may be associated with a “host group”, meaning that cosbatch will dynamically assign the servers in the Host group to the job at run-time. The definition of a processor includes a value for the maximum number of jobs that it can run concurrently.
A calendar is a named resource which either contains or generates a list of times and dates. Calendars are created independently of jobs and are fully re-usable objects which are subsequently attached to the jobs and/or suites which need to use them.
A calendar may contain explicit definitions by quoting days of the week, days of the month, week numbers, and so on. Jobs and suites may also be run by quoting a frequency such as “every five days”.
A calendar may be used either to enable execution or to disable execution, so that when they are nested together, complex results can be generated. In this way we can end up with a scheduling scheme that, for example, specifies that a job should execute on the last Monday of every month, other than when the Monday is a Public Holiday.
A Suite is a named collection of (more often than not) inter-dependent jobs. A suite is scheduled as, and may be managed as, a single object, but its constituent jobs may be placed on different queues and routed to different processors for execution. Though the suite provides a preferred context for ease of specification and efficient resolution of logical dependencies (preconditions) between its jobs, such preconditions may also span suite boundaries.
For more information on how user access security is implemented within cosbatch, please visit Security and Access Controls
For more information on the user interface please visit Java based Graphical User Interface
For more information on FailOver please visit Automatic FailOver
For more information on the cosbatch architecture you can also download the white paper - "cosbatch 3.1 - an overview of its architecture".