Like cron, with dependencies, hosts and a live queue
Where cron is the right answer, where it stops being one, and what Xi-Batch adds at that point.
When cron is enough
If you need to run a script at a time, on a machine, and you will notice if it
does not work, cron is a good tool and you should keep using it. We would not
try to persuade you otherwise.
It is universally available, it is robust, and it has done that job well for forty years.
Where it runs out
A control file looks like this:
0 2 * * 0,4 /usr/lib/cron/logchecker
Run that program every Sunday and Thursday at two in the morning. In theory you should be able to express 'the second Tuesday of every month'. In practice, on most systems, you cannot.
More significantly:
Jobs cannot depend on one another
There is no way to say that the ledger post runs only after the transaction load has finished successfully. What people do instead is guess at a time, leave a gap, and hope - or write a wrapper script that becomes its own maintenance problem.
There is no coordination across hosts
A job on one server cannot wait on work completing on another. In a network of servers doing real work, this is the limitation that hurts most.
There is no display
You cannot see what is running, what is queued, or what
failed, without deciphering the output of ps.
There is no load control
Every job that is due starts, whatever else is already running.
There is no intervention
Once cron has started a job, its involvement is
over. You cannot hold it, reprioritise it, or restart it.
Security is limited
There is no concept of what a user may schedule, where, or at what priority.
cron starts a job at a specified time. It does not provide the job management
and dependency handling that Xi-Batch does.
db_backup_run waits on DB_QUIESCED = 1 and sets BACKUP_STATE when it ends normally; the variable pane shows DB_QUIESCED is still 0, which is why it has not started. The two dialogs are modal and cannot be open together - this is composited from two captures of the same moment. Every job and variable shown is fictitious. Shown in the Motif interface.What a production scheduler has to do
The table below lists what a production scheduler has to do, and whether cron and Xi-Batch do it.
| Capability | cron | Xi-Batch |
|---|---|---|
| Time and date triggering | Yes | Yes |
| Repeat by minutes, hours, days, months | Partial | Yes |
| Nth or last working day of the month | No | Yes |
| Holiday calendars and days to avoid | No | Yes |
| Job-to-job dependencies | No | Yes |
| Dependencies across hosts | No | Yes |
| Trigger on file creation, deletion or change | No | Yes |
| Load levelling | No | Yes |
| Job priorities with per-user ranges | No | Yes |
| Live queue display | No | Yes |
| Hold, release, reprioritise, restart a job | No | Yes |
| Per-user security and access control | Limited | Yes |
| Remote submission without a remote login | No | Yes |
| Audit trail | Limited | Yes |
| Chargeback accounting | No | Yes |
| Graphical and character interfaces | No | Yes |
| Programmatic API | No | Yes |
Built from the ground up
Some scheduling products are little more than a user interface over the standard utilities. Xi-Batch was developed from the ground up and does not rely on any other software product or utility for its operation.
That matters in practice: dependencies, load control and security are part of
the scheduler itself, not an addition that anyone with access to crontab can
walk around.
Migration
Existing crontab entries convert automatically during installation. Xi-Batch
installs in minutes, makes no kernel modifications, and requires no relational
database. It does not interfere with existing systems, so it can be evaluated
alongside what you have.
All text - help messages, menus, keyboard assignments - is tailorable to your environment, which reduces the retraining that usually makes operations teams resist a change of this kind.
If you already have a message bus
A message bus and a scheduler are often put in the same conversation, and they answer different halves of the question.
A bus is reactive. It carries an event from one application to another, and each consumer decides for itself what to do about it. That is the right design for application-to-application traffic, and where you have one it should stay.
What a bus does not hold is time, or the state of the run as a whole. It has no opinion that the ledger post should have started by half past two, that it is now late, that the extract it depends on failed, or that nothing downstream should be released until someone has looked. A bus reports events that happened. It does not report that an expected event has not happened, and that is what an operations team needs to know.
Xi-Batch works both ways round. It owns the calendar, including the awkward parts - the last working day, the days to avoid, the holiday list - and it also reacts in real time, to a file arriving, a job finishing somewhere else, or a submission from another host. Between those two it holds the dependency graph and the live state of tonight's run, which is the thing an operator can look at, hold, reprioritise and restart.
The two compose. Let the bus carry the events, and let the scheduler decide what is due, what is late, and what may now proceed. Xi-Batch needs no broker of its own to install, license or keep running, which is usually the deciding practical point for a team that already has one bus to look after.
If you are looking at Airflow, Kestra or Rundeck
Those tools are strong for data pipelines and container-native workloads, and if your work is Python-centric and your team is engineers, they may suit you better. They also bring real operational complexity of their own.
Xi-Batch is built for business batch work on Unix and Linux servers: jobs run by operations staff, dependencies between jobs on different hosts, and installations that run unattended for years.
Next
About Xi-Batch · Xi-Batch case studies · Request an evaluation