# IBM i Batch Window Capacity Calculator

> Source: https://netray.co/tools/ibm-i-batch-window-capacity-calculator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Predict how many years of growth your nightly batch can absorb before it overruns the available window, and how much speedup you need.

## Category

oracle

## Erp

Oracle JD Edwards World

## Audience

- IBM i operator
- IT manager
- ERP administrator

## Tool

**Kind:** calculator

**Inputs:**

#### Current batch runtime

**Key:** runtime

**Type:** number

**Default:** 5.5

**Min:** 0.1

**Step:** 0.1

**Unit:** hours

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

#### Available window

**Key:** window

**Type:** number

**Default:** 8

**Min:** 0.5

**Step:** 0.5

**Unit:** hours

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

#### Annual transaction volume growth

**Key:** growth

**Type:** slider

**Default:** 12

**Min:** 0

**Max:** 40

**Step:** 1

**Unit:** %

#### Planning horizon

**Key:** horizon

**Type:** slider

**Default:** 5

**Min:** 1

**Max:** 10

**Step:** 1

**Unit:** years

#### Share of runtime that can run in parallel

**Key:** parallel_share

**Type:** slider

**Default:** 40

**Min:** 0

**Max:** 90

**Step:** 5

**Unit:** %

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

**Outputs:**

#### Headroom today

**Key:** headroom

**Expr:** window - runtime

**Format:** hours

#### Window utilisation today

**Key:** util

**Expr:** runtime / window * 100

**Format:** percent

#### Years until the window is full

**Key:** years_left

**Expr:** if(and(lt(runtime, window), gt(growth, 0)), ln(window / runtime) / ln(1 + growth / 100), 0)

**Format:** years

**Primary:** true

**Description:** Zero means already over, or no growth entered.

#### Runtime at end of horizon

**Key:** future

**Expr:** runtime * pow(1 + growth / 100, horizon)

**Format:** hours

#### Runtime reduction needed to fit

**Key:** cut

**Expr:** max(0, (1 - window / future) * 100)

**Format:** percent

**Primary:** true

#### Best-case saving from parallelism

**Key:** par_gain

**Expr:** future * parallel_share / 100 * 0.5

**Format:** hours

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

**Chart:**

#### Runtime at horizon vs annual growth

**Type:** line

**X:** growth

**From:** 0

**To:** 40

**Steps:** 21

**Series:**

- future

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

## Content

**Intro:** 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.

**Sections:**

#### How to use it

**Body:** 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

**Body:** 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

**Body:** 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.

**Bullets:**

- 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

**Body:** 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.

**Cta:** If you would like job run history analysed to find the critical path in your batch, Netray can do a read-only review of your scheduler data.

**Faq:**

#### Does it matter which ERP I run?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

#### Is the parallelism number a promise?

**Answer:** No. It is a rough upper bound. Real gains depend on CPU cores, memory, file locking and dependencies, so test on your own system.

## Search terms

as400 batch window, ibm i nightly batch runtime, jd edwards world night processing, batch window capacity planning, ibm i job scheduler window, month end batch overrun, as400 performance growth

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json