IBM i Job Scheduling Software

How should dependencies be modeled across jobs and systems?

Dependencies should follow the actual business workflow, not just the technical order in which jobs were historically scheduled. That means modeling prerequisites, file arrivals, API responses, restart behavior, approval steps, and exception paths in the same design instead of treating them as separate operational knowledge.

Answer

Modeling file arrivals well means watching for the actual file, not just assuming it landed because a transfer job completed, since an FTP or SFTP job can report success while delivering a zero-byte or partial file. The same discipline applies to API-based triggers: a scheduler that treats any HTTP response as success, rather than checking the response code and payload for a genuine confirmation, will start downstream processing on bad data just as often as it does on good data. Buyers should ask vendors to walk through exactly how their platform validates these conditions rather than simply polling for existence or completion.

Restart behavior is where dependency design earns its keep during a real failure. When a job in the middle of a chain fails, the platform needs a clear answer for whether downstream jobs wait, skip, or require manual approval to proceed, and that answer should be visible to operations staff in plain terms rather than buried in configuration. Approval steps for sensitive processes, such as releasing a payroll run or a financial close job, should be modeled as first-class parts of the workflow with a full audit trail, not handled as an informal phone call outside the system. A dependency map that cannot be reviewed by someone other than its author has become exactly the kind of opaque risk workload automation is supposed to eliminate.

Back to IBM i Job Scheduling Software