Jobscheduler.com is intended to provide information about job schedulers and their characteristics. It is curated by Flux, a job scheduler vendor. This site is intended to provide guidance and suggestions in your search for job scheduler information. We stay objective and will not overtly sell to you on this site. Refer to flux.ly for details about our Flux product.

What is a Job Scheduler?

Job schedulers carry out repetitive tasks defined within a schedule and based upon calendar and event conditions. A job scheduler or task scheduler itself is a software application for controlling the unattended background program execution of jobs or tasks.This is commonly called batch scheduling, as execution of non-interactive jobs is often called batch processing.

To perform a specific software job or task a job scheduler calls other software programs to perform some action. These calls can be made via numerous mechanisms such as invoking a command line, a shell script, a web service, and a programming language API.

Job scheduling has evolved over the years to handle increasingly complex and diverse uses. This evolution has delivered terms including batch system, task manager, distributed resource management system (DRMS), distributed resource manager (DRM), process automation, robotic process automation, service orchestration, process orchestration, and workload automation.

Job Scheduler Uses:

The spectrum of industries that use job scheduler software is too varied to list. One may reasonably assume that any industry that has repetitive tasks that involves the scheduled execution of software programs utilizes job schedulers today.

Some sample use cases out of the myriad of possibilities include the automating of software deployments, scheduling of payroll runs, preparation of customer account statements, generation of billing statements, and the periodic performance of data maintenance and records archival.

Looking for a Job Scheduler?

Today there are hundreds of job scheduler software applications available. This link on Wikipedia scratches the surface of what is available today. Finding a match between your job scheduling requirements and the market’s offering is no easy task. Using published reviews such as Gartner’s Magic Quadrant or Enterprise Management Associates RADAR report is a useful to help analyze vendors in the current market. However, enterprises must apply their own requirements to select a vendor. Enterprises that have traditional calendar-based job-scheduling requirements should have a different short list of vendors from enterprises that have batch application integration requirements or use Java application server platforms.

An abbreviated list of Job Scheduling Products with ERP Support:

How to evaluate Job Schedulers:

First – Clearly Describe your Requirements:

• Budget constraints: The solutions that present themselves tend to cluster around certain dollar amounts. You will get different vendors bidding different products to respond to your request if your budget is 10,000 vs. 100,000 vs. 1,000,000 or more.
• Supported hardware and/or operating system requirements: List support for Linux, mainframes, Windows, etc. If you intend to run on cloud hardware state which cloud providers you require support for. If running on virtual machines specify the virtual machine software provider. Container support – if required – should be specified.
• Number of  environments you require: For example, are you anticipating a production server with a failover node, a QA/Testing server, and a development server or developer workstations? Or just one server with all work being done on the same machine? State your desired environments.
• Use cases: Needing to provision 100 Docker containers within AWS vs. running twice daily (at noon and 6 PM) five SQL Server index defragmentation scripts on an on-premise database will yield very different vendor proposals.
• Schedule Specification: Do you require that schedules be developed only visually, visually with optional scripts, or only via scripts?
• Remote machine execution: Do you require that the scheduler can initiate jobs on a remote machine? Can the scheduler initiate a remote command using SSH and/or does the scheduler provide an agent that can be installed on remote machines (or both)?
• Other software must the scheduler integrate with: Many customers state their requirements to integrate with ERP solutions such as SAP and Oracle Financials.
• Migration support: Migrating an existing scheduler to a new scheduler’s format is not commonly supported. If this is mandatory – state as a requirement.
• Embeddable: While not a common requirement, some customers require that the scheduler be embedded into another product, such as the customer’s own product.

Second – Weight your requirements

• For each requirement above, specify of the requirement must be satisfied to be consider, or is a “nice to have” or optional requirement. Assign each requirement a point value. The sum of all the mandatory requirements satisfied by a vendor should be distinct from the sum of all optional requirements satisfied.

Third – Specify your Proof of Concept Use Case(s)

• • Once your requirements are laid out and weighted, specify a proof of concept use case (or multiple use cases) that when completed will demonstrate satisfaction of your mandated requirements.

• • The use case should be generic enough that vendors can build and construct examples that will execute without access to customer IT systems. The vendor’s examples should document exactly where and how the developed examples can be modified to then run within the customer’s environment.

• Identify the expected deliverables and results from the vendor’s, and your own, development and execution of the proof of concept.

Fourth – Layout your Vendor Demonstration Requirements

• • Vendor demonstrations provide a means to eliminate vendors from review.

• • Vendor demonstration requirements should be directed in a way to present the mandatory requirements and weights determined in steps one and two above.

• Specify what you expect a vendor to demonstrate to your team within a 1 to 2 hour video conference or in-house presentation.

History of Job Schedulers: 

Job schedulers have evolved over time from a variety of directions. The earliest schedulers had to address the scheduling of low-level operating system tasks within computer hardware. Then operating system vendors such as AT&T/Bell Labs and Microsoft provided schedulers services accessible to their customers. Available on Unix and Linux machines, is Cron (standing for Command Run On (a schedule)). The Windows operating system released its Windows Task Scheduler in Windows NT in 1996. These schedulers are frequently used by sysadmins to schedule jobs (commands or shell scripts) to run periodically at fixed times, dates, or intervals for system maintenance or administration. Their general-purpose nature makes them useful for other things like downloading files and email at regular intervals.

Database, file and tape management vendors started to embed schedulers to automate their routine maintenance activities. As applications grew more diverse, the need for repetitive task scheduling also grew, yielding many schedulers being embedded into many packaged software applications (e.g., human resource, enterprise resource planning, and materials resource planning). Such embedded schedulers are still common today.

In the late 1970’s and early 1980’s job scheduling software itself became an application that could be purchased, separate and apart from other software applications. In this time period vendors released their “enterprise job scheduling software.” At the time such packages only ran on mainframe computers. These packages provided scheduling services across applications allowing an enterprise to coordinate the scheduling between and across their applications. With such software tape backups could be taken before running payroll, and check deposits could be run before check payments, even though these process ran in separate software applications (but still on the same mainframe computer).