Reports that speak the language of the business

Clients expect daily and weekly summaries that show the health of each LPAR, the number of jobs that ran, abends recorded and any SLA breaches. The report should list:

  • LPAR name and owner
  • Total jobs scheduled vs. completed
  • Jobs that missed their SLA, with the plain‑word prediction that warned in advance
  • WTORs still open and their age
  • Subsystem status for CICS, IMS, Db2 and Adabas

The format is usually a PDF or an HTML page that can be emailed automatically. The key is that the data is presented without jargon; a line such as "Batch X will miss its SLA by two hours" is far more useful than a raw timestamp.

Service‑level agreements that are measurable

A client’s SLA must define three elements:

  1. Prediction accuracy - the provider must forecast a missed SLA at least two hours before the deadline.
  2. Response time - once a breach is reported, the provider must acknowledge the alert within fifteen minutes and propose an action within thirty minutes.
  3. Resolution time - the provider must complete the agreed corrective action (restart, force‑complete, hold, etc.) within a time frame that matches the impact of the batch.

These metrics are tracked per LPAR and per client, and the results are fed back into the regular reports. If a provider consistently meets the prediction and response targets, the client can rely on the service for credit calculations and capacity planning.

Evidence for every action

Clients need an audit trail that shows who did what, when, and why. For each card that the monitoring tool generates, the following must be recorded:

  • The original alert (message id, job name, abend code)
  • The proposed command (e.g., CANCEL JOB(jobname)) and the operator’s confirmation
  • The outcome of the command, captured from the scheduler or console
  • A timestamp and the operator’s identifier

All evidence stays inside the client’s network; it never leaves the premises. The audit log can be exported for compliance reviews or internal investigations.

Rapid response workflow

When a batch is predicted to miss its SLA, the provider should follow a clear workflow:

  1. Alert - the monitoring screen raises a card with the prediction in plain words.
  2. Propose - the system suggests the most appropriate scheduler action (restart from step, force complete, hold, etc.).
  3. Confirm - an operator clicks the card to send the command.
  4. Record - the action and its result are logged as evidence.
  5. Notify - the client receives a notification via the agreed channel (email, Teams, ServiceNow ticket).

The whole loop should be visible on a single screen so the provider’s staff can see the status of every LPAR at a glance.

Multi‑client and role separation

A managed service often supports several customers from one operations floor. The tool must keep each client’s data, alerts and actions isolated. Roles are granted per client:

  • Operator - can view alerts and confirm actions for their client.
  • SME - can adjust alert rules and view deeper diagnostic data.
  • Manager - can generate reports and audit trails for their client only.

This separation ensures that a provider can scale without mixing data, and each client retains control over who sees their environment.

Continuous improvement and earned autonomy

Clients appreciate when a provider learns from past incidents. By analysing which actions resolved a breach, the system can raise the same card with a pre‑filled suggestion for future occurrences. The provider can raise the autonomy level for routine actions, but any automatic step is still recorded as if an operator had clicked it.

How Meridian helps

Meridian provides a single console that shows every LPAR, its WTORs, abends and subsystem status. It predicts batch‑SLA breaches in plain words, proposes scheduler actions, and records every operator confirmation as evidence. The product runs inside the client’s network, leaving data on‑premises, and has a light footprint on the mainframe. Pricing is per LPAR per month, with a free 90‑day proof of concept on one LPAR.

---

Key take‑aways

  • Reports must be clear, client‑specific and include plain‑word SLA predictions.
  • SLAs should be measurable on prediction accuracy, response and resolution times.
  • Every action needs an audit‑ready record that stays within the client’s network.
  • A single screen workflow speeds up response and reduces noise.
  • Role‑based separation protects multi‑client environments.
  • Evidence of continuous improvement builds confidence.

By delivering these elements, a managed service provider meets the core expectations of its batch‑monitoring clients and creates a foundation for long‑term partnership.