The situation

It is 01:40. A settlement job in the CA 7 queue has abended in its fourth step. The batch it belongs to has a deadline of 06:00 for the client's file transfer. The operator has a few options and a few minutes:

  • Restart from the failing step, if the earlier steps' output is good and the step can be rerun.
  • Restart from the top, if the job is not restartable mid-way or the data written so far cannot be trusted.
  • Force complete, so its successors can run, and fix the data later, when the job's output is not needed downstream tonight.
  • Hold the job and its successors while someone who knows the application looks at it.

Each of these ends the batch at a different time. The scheduler knows the chain. History knows how long each job usually takes. What is usually missing is someone putting the two together at 01:40.

Read the abend first

The abend code narrows the choice before anything else.

  • S0C7 (data exception) and S0C4 (protection exception) usually mean bad input or a program fault. Rerunning without changing anything usually fails the same way.
  • S322 means the step ran out of its CPU time limit. It can be a loop, or a genuinely larger night.
  • SB37, SD37, SE37 are space problems on an output data set. Fix the space and restart from the step.
  • S806 means a module was not found: often a library change. Restarting before it is fixed wastes the time.
  • S913 is a security product refusal. A restart will not help until access is fixed.
  • Unnnn codes are set by the application itself, and the runbook for that application says what they mean.

Then look at the deadline

With the cause known, the question is time. A restart from the step takes the remaining steps' usual run time. A restart from the top takes the whole job again. Forcing complete takes nothing for this job but may push work to the day shift. Each one then has to be added to everything downstream on the critical path, the longest chain of dependent jobs from here to the last job in the batch.

This is arithmetic the operator should not have to do by hand. It needs the chain from CA 7's triggers and requirements, the usual run time of each remaining job on this weekday, and the live state of anything the downstream jobs need, such as a Db2 subsystem or an initiator class.

Make the decision visible

Whatever is chosen, three things help the next person:

  1. Write down why. The abend, the choice, and the expected end of the batch after the restart.
  2. Send exactly one command. The CA 7 restart, with the step and options, as it was decided, not retyped from memory.
  3. Keep the outcome with the decision. What CA 7 answered, when the job ended, and whether the batch made its deadline.

How Meridian does it

In Meridian a failed job becomes a card. It shows what Meridian saw (the abend, its code and step, linked to the console line), what CA 7 already holds for the job, what it proposes, and the command exactly as it will be sent. The restart card shows whether the batch can still end on time after the restart, and by how much, before anyone clicks. After the click, CA 7's answer and the outcome land on the same card, and the whole thing is in the audit trail with who confirmed it.

Meridian supports all of CA 7's job actions from cards: restart from a step, force complete, cancel, hold, release, demand, run now, requeue, and the queue-wide holds and releases. See Predict for the SLA view and Act for the cards.