Scheduling, execution and output for Unix and Linux
Your automated workload has three problems, and most suppliers solve one
Work has to be scheduled in the right order across the right machines. It has to execute on hosts you would rather not hand out shell access to. And it has to produce output that reaches a printer, a file or a person without anyone watching. The overnight run is the clearest example, and the same three problems apply to anything that runs without somebody watching it.
Xi builds all three pieces, and has done since 1984.
Xi-Text since 1984 · Xi-Batch since 1990 · Xi Software incorporated 1986 · Many Unix platforms, most Linux distributions · On your infrastructure · Perpetual licensing · No database to install
The three stages, and where the standard tools stop
Scheduling
More than a clock
cron starts things at times. It cannot express that one job depends on another,
cannot coordinate across hosts, shows you nothing about what is running, and
hands back control the moment a job starts.
Output
Production print is not desktop print
lp and CUPS are fine for a desktop. They cannot restart a failed sixty-thousand
page run at the point of failure, route by the form loaded rather than the printer
named, or stop most of the organisation reaching the cheque printer.
Execution
Remote work without shell access
Scheduled work has to reach other machines. The usual answers - shared keys, a service account with a shell, an SSH command that becomes an interface by accident - are the ones that turn up in an audit.
The products
Schedule it
Xi-Batch
Dependency scheduling across hosts, load levelling, file monitoring, and a live
queue your operators can see and act on. A replacement for cron, not a wrapper
around it. In production since 1990.
Run it
Xi-Exec
Named, pre-approved scripts dispatched to remote hosts over mutual TLS, with centralised access control and a structured audit log. No shell access exposed.
Deliver it
Xi-Text
Production print spooling and output management. Route by form type, pool printers automatically, restart interrupted jobs at the point of failure, and see every printer and job on one screen. In production since 1984.
Why these, and not the alternatives
Nobody else does both ends of the cycle. The scheduling vendors do not sell print management. The print vendors do not sell schedulers. We sell both, built to work together.
We do not break what you have built. On-disk formats, the network protocol, command-line flags and exit codes are treated as a contract. Customers who wrote integrations against Xi-Batch twenty years ago still have them working.
Light on the systems it runs on. Event-driven throughout, with no relational database to install, license or maintain.
Yours permanently. Perpetual licensing, tiered by processor class. No subscription and no annual renegotiation.
Sovereign by design. Everything runs on your systems, and nothing in the operating path depends on us or on anyone's cloud. How that works.
We schedule overnight batches, and it just works seamlessly. We are long-term customers and can't find anything else as good.
Adrian Foster, Kirklees Metropolitan Council
Moving off HP-UX, Solaris or AIX?
Xi-Batch and Xi-Text run on the commercial Unix you are leaving and on the Linux distributions you are moving to, with the same interfaces, the same job and printer definitions, and the same command syntax. The scheduler and the print estate become the parts of the migration you do not have to re-plan, and the two platforms can run in parallel while you move: changing platform within a processor class carries no additional licence fee.
HPE support for HP-UX ended on 31 December 2025, which is why that one comes up most often.
Talk to us about your migration
Try it on your own systems
Evaluation copies install in minutes, need no database, make no kernel modifications, and convert to licensed status without reinstallation - no second install, no rebuild, no re-testing.