How to predict a batch SLA breach on z/OS, hours before it happens

Why the deadline is the wrong moment to find out

A night's batch is a chain. Settlement jobs wait for extracts, reports wait for settlement, and the file transfer to the client waits for the reports. When the last job ends late, the cause is almost always hours upstream: a job that abended at 01:10, a restart that ran from the wrong step, an initiator class that filled up, a Db2 subsystem that was down for maintenance longer than planned.

Most operations floors find out from the scheduler's late status or, worse, from the client. By then the only choices left are an apology and an SLA credit. The useful question is the one asked at 01:15: with what we know right now, will this batch still end before its deadline?

What a prediction needs

A prediction that operators trust needs four things, and none of them is a guess.

1. The chain. Which jobs make up the batch, and which job waits for which. The scheduler already knows this: in CA 7 it is the triggers and requirements on each job. Nobody should draw the chain by hand, because a hand-drawn chain is wrong the week after someone adds a job.
2. The usual run time of each job. Taken from your own history, not from a vendor's model. A job's run time depends on the day: month-end, Mondays and the first business day of a quarter are different from a quiet Wednesday. So the history has to be split by weekday class, and it has to carry its spread, not just an average.
3. The live state of the estate. A job that needs a CICS region, an IMS control region or a Db2 subsystem cannot run while it is down. A job that needs an initiator in a class that is full will wait. A prediction that ignores this is right on quiet nights and wrong on exactly the nights that matter.
4. The critical path. The longest chain of dependent work from now to the last job decides when the batch ends. It is found by walking backwards from the last job through its predecessors. The job on that path is the one to watch, and it can change during the night.

Update the prediction when the night changes

The night changes when something happens: a job ends, a job abends, a subsystem stops, a restart is submitted. The prediction should be worked out again at each of those moments, so it is never older than the last thing that happened. A prediction refreshed every fifteen minutes can be fourteen minutes behind the abend that decided the night.

Say it in words

Times and percentages are hard to read at three in the morning, and a manager reading a report the next day should see the same thing the operator saw. Meridian uses four phrases for a running batch:

• On time.
• On time, but tight.
• Slightly delayed, within the approved time.
• SLA breach incoming.

After the fact: Done on time, Done late, Missed. Next to the words sits the job that decides the batch's end right now, so the operator knows where to look.

When there is not enough history yet, the right answer is to say so. A prediction made from two weeks of data on a new client is not confident, and Meridian says it is not sure, in those words, instead of showing a precise time it cannot back.

The restart question

The most useful moment for a prediction is when a job fails. The operator has to decide how to restart it: from the failing step, from the top, or force it complete and fix the data later. Each choice ends the batch at a different time. The restart card in Meridian shows whether the batch can still end on time after the restart, and by how much, before anyone clicks.