① Licensing concept · Peak management
The bill runs off the highest four hour average in the month. Move the deferrable work out of that window and the peak drops, taking every MLC product's charge down with it. No work removed, just retimed.
Move the work in time. Watch the peak fall.
Peak shaving is the practice of scheduling and capping work so the rolling four hour average MSU, the R4HA, never climbs higher than it has to. IBM sub-capacity Monthly License Charge products are billed on the highest R4HA recorded in the month, so the single busiest four hour window sets the figure that every MLC product is charged on. Lower that window and you lower the billed MSU across the whole stack, without removing a single unit of work from the estate. It is the cheapest lever on the mainframe because it spends scheduling, not money.
The mechanism is the average itself. Because the R4HA is computed over a four hour window, concentrating heavy work into one window drives the peak up, while spreading the same work out keeps it down. Deferrable batch, analytics, reporting, and housekeeping jobs that happen to pile into the busy window are the candidates: move them, stagger them, or cap them, and the four hour average that sets the bill flattens. The work still runs and the totals are unchanged. Only the timing moves, and timing is what the metric charges for.
A first pass at which work is a candidate for shaving and which is not. The test is deadline slack and latency sensitivity, not job size.
| Workload | Shave it? | Why |
|---|---|---|
| Overnight batch with slack deadlines | Yes | Deferrable, can move off the busy window |
| Analytics and reporting runs | Yes | Rarely latency sensitive, easy to retime |
| Housekeeping and backups | Often | Schedulable around the peak window |
| Latency sensitive online transactions | No | Must run when demanded; shaving breaks service |
| Hard deadline regulatory jobs | No | No slack to move without missing the deadline |
An estate whose peak is driven by deferrable batch landing on top of the online peak. Moving it off the window lowers the billed peak. The rate per MSU is an illustrative placeholder R; actual rates are negotiated and not stated here.
| Measure | Before shaving | After shaving |
|---|---|---|
| Online peak (MSU) | 360 | 360 |
| Deferrable batch in the same window | 160 | 0 |
| Highest rolling four hour average | 520 | 370 |
| MSU billed across MLC products | 520 × R | 370 × R |
| Total work done in the month | same | same |
| Change in billed peak | base | −29% |
The batch did not need to run during the online peak; it simply did. Moving it to a quiet window drops the highest four hour average from 520 to 370 MSU, a 29 percent cut in the figure that every MLC product is billed on, for a scheduling change and no reduction in work. This is why peak shaving is usually the first lever to pull: it spends planning rather than budget, and the saving recurs every month the schedule holds.
The bill is set by the single highest four hour average in the month, so one unplanned heavy run, a recovery test or an ad hoc job, can rebuild the peak you shaved. The discipline has to hold every day, not most days.
A schedule tuned once erodes as new jobs are added and old ones shift. Without periodic review, shaved peaks creep back, and the saving quietly disappears into a schedule nobody is watching against the R4HA.
Shaving the wrong window wastes effort and can hurt service. It only works when the actual peak window is identified from real SCRT and SMF data, not from where the team assumes the busy period is.
Scheduling flattens predictable peaks; it cannot catch the unpredictable ones. Without soft capping as a backstop, a surprise spike still sets the month's bill, so shaving and capping are a pair, not alternatives.
Find the real window, move the deferrable, cap the rest, then hold it.
Peak shaving rewards measurement and discipline over cleverness. Start by identifying the actual peak window from SCRT and SMF data, not from where the team thinks the load sits. Sort the work in that window into deferrable and not, and move or stagger the deferrable jobs out, leaving latency sensitive and hard deadline work alone. Add soft capping as a backstop for the spikes scheduling cannot predict. Then guard the result: review the schedule on a cadence, because shaved peaks creep back as jobs are added and one stray heavy run can reset the month's bill.
This is the active version of the same problem the capacity metric creates, so read MIPS and MSU explained for how the peak is built and group capacity limits for the capping backstop. If the peak is mostly mobile driven, see Mobile Workload Pricing; if you are weighing leaving the peak model behind, see Tailored Fit Pricing. When the schedule is worth real money against the R4HA, our mainframe cost optimization service turns the data into a shaving plan.
Scheduling and capping work so the rolling four hour average MSU does not climb higher than it needs to. Since MLC products bill on the highest R4HA in the month, lowering the peak lowers the charge across the whole stack.
The R4HA averages over a four hour window, so concentrating heavy work raises the peak and spreading it out lowers it. Moving deferrable batch and reporting off the busy window flattens the average that sets the bill.
Not when it targets deferrable work with deadline slack. It leaves latency sensitive online transactions alone. Done with measurement, only movable work moves, so the peak falls without breaching service.
Shaving moves work in time so the peak never forms; capping throttles consumption at a ceiling. Shaving is proactive scheduling, capping is the backstop. They work best together, not as alternatives.