OracleFree calculatorPDF, Excel, Word exportOracle JD Edwards WorldAll JD Edwards World tools

IBM i Batch Window Capacity Calculator

Batch windows rarely fail suddenly. They erode a few percent per year until a heavy month end pushes the last job into the morning. This calculator tells you how close you are and how much faster the batch must run to stay safe.

Your numbers

Current batch runtime

hours

Elapsed time from first to last job on your heaviest night, such as month end.

Available window

hours

Time between the last user leaving and the first user or interface needing the system.

Annual transaction volume growth

12 %

Planning horizon

5 years

Share of runtime that can run in parallel

40 %

Jobs with no dependency on each other that could run in separate job queues.

Your results

Years until the window is full

3.3 years

Zero means already over, or no growth entered.

Runtime reduction needed to fit

17.5%

Headroom today

3 hrs

Window utilisation today

68.8%

Runtime at end of horizon

10 hrs

Best-case saving from parallelism

2 hrs

Assumes parallel jobs finish in half the time. Measure your own job queue and CPU limits.

Assumes runtime scales linearly with volume. Batch jobs with sort or index rebuild steps can scale worse.

Free, optional. Reopen it on any device.

Save results:

Runtime at horizon vs annual growth

Sweeps Annual transaction volume growth from 0 to 40, holding your other inputs fixed.

Batch history analysis

Optional: we read your scheduler history and mark the critical path.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

How to use it

Take your longest night from the last twelve months, not the average. Use the job scheduler or QHST history to find the first start and last end time. Enter the window the business really needs, which for a plant often ends when the first shift scans in. Add volume growth from order and receipt counts, not revenue.

The formulas

If runtime scales with volume, then after t years runtime equals current runtime times (1 + g) to the power t. The window is full when that equals the window, so years left is ln(window / runtime) divided by ln(1 + g). The reduction needed is one minus window divided by the future runtime. The chart sweeps growth from 0 to 40 percent so you can test optimistic and pessimistic cases.

What to do with the answer

If you have more than three years of headroom, monitor and move on. Between one and three, start with the cheap wins: run independent jobs in parallel job queues, purge or archive large history files before month end, and fix full-file scans with proper logical files or SQL indexes. Under one year, add the hardware or tuning work to the budget now, since hardware and skills have lead time.

Check that the interface jobs after the batch have a fixed deadline
Look for a single long job holding the critical path
Test after each change on the same heavy night, not a quiet one

Common mistakes

Using average runtimes, ignoring year-end or quarter-end peaks, and assuming parallelism is free. Jobs that lock the same files serialise anyway. Another common error is mixing runtime caused by waiting on a tape or an interface partner with CPU work, which behave differently as volume grows.

Frequently Asked Questions

Does it matter which ERP I run?

No. The model works for any IBM i batch, including JD Edwards World nightly processing, custom RPG jobs and third-party applications. Only the runtime, window and growth rate matter.

Why use the heaviest night?

Because failures happen on the peak. A batch that fits comfortably on an average night can still overrun at month end, when volumes and reports are highest.

What if growth is zero?

Then the batch never overruns on volume alone and years left shows zero. Check whether any other changes, such as new reports or interfaces, will add work.