IBM i Job Scheduling Software

What should an IBM i job scheduling demo prove before we trust it?

It should prove the platform can handle one real overnight or cross-system workflow from start to finish ... dependency checks, calendar rules, exception handling, restarts, alerts, and the exact point where a human has to intervene if something goes wrong. A clean chain of green boxes is not enough.

Answer

The workflow chosen for the demo matters more than the vendor's script. Buyers get the most honest picture by picking the process with the worst operational history, not the simplest one, and walking the vendor through it step by step: a file lands from a trading partner, an RPG or COBOL program validates and loads it into Db2 for i, and a downstream extract or report depends on that load completing cleanly. Calendar handling should be tested against real exceptions too, month-end schedules, holiday shifts, and fiscal period boundaries, since generic daily jobs rarely expose where a scheduler's calendar logic breaks down.

The most revealing test is asking the vendor to deliberately fail a step mid-run. Watch whether the software restarts from the failed step or forces a full rerun from the beginning, whether the person intervening needs to know library lists and job parameters to fix it, and whether the alert that fires actually tells someone what to do next. A platform that handles this cleanly in front of the buyer, using the buyer's own job names and libraries rather than vendor sample data, has proven something a features list cannot.

Buyers should also ask what happens when two workflows compete for the same resource at the same time, since resource contention during month-end or peak season is where scheduling gaps usually surface first in production.

Back to IBM i Job Scheduling Software