What to monitor

A good tool must show the health of every LPAR in real time. Look for a dashboard that lists:

  • Live status for each LPAR, with a warning when it goes stale
  • Open WTORs with age
  • Job abends for the day
  • Batch line expressed in plain words
  • Subsystem status for CICS, IMS, Db2 and Adabas
  • Spool usage and initiator counts

The dashboard should let you filter by client, LPAR or items that need attention. Check that what it shows comes from the systems themselves as things happen, not from a report run every few minutes.

How to predict batch timing

Prediction is useful only if it is easy to understand. The tool should:

  • Show a named batch with a plain‑language prediction such as "On time", "Slightly delayed" or "SLA breach incoming".
  • Base the prediction on recent run history, not on guesswork.
  • Update the prediction as new events arrive, for example when a job aborts or a subsystem goes down.

Ask whether the prediction engine needs a minimum amount of historical data and how it learns the normal run time.

Actions and automation

Automation should be under operator control. Check that the tool can:

  • Propose an action on a card, for example a scheduler restart or a command to a subsystem.
  • Show the exact command that will be sent and the expected effect.
  • Require a single confirm click before the command is issued.
  • Record the outcome on the same card, including who confirmed it and the reply received.

The workflow must integrate with the scheduler you use, such as CA 7, and with your ticketing system, for example ServiceNow.

Multi‑client and role separation

If you run a managed service provider operation, the tool must support many clients on one install. Look for:

  • A wizard to add a new client quickly.
  • Separate role‑based screens for operators, SMEs and managers.
  • Rules and alerts that can be defined per client.
  • Visibility of only the client’s own LPARs and actions for each user.

This reduces the need for multiple installations and keeps data isolated.

Evidence and audit trail

Every action taken on a batch should be traceable. The tool should record:

  • The original message or event that triggered the action.
  • The command sent and the reply from the mainframe.
  • The user who confirmed the action and the timestamp.
  • A link back to the exact line in the console that raised the issue.

The audit data must be searchable and exportable to the ticketing system for client review.

Footprint on the mainframe

The monitoring solution should have a minimal impact on the host. Verify that:

  • Its footprint on each LPAR is light, and it uses very little CPU when nothing is happening.
  • It runs inside your own network, and your data never leaves it.
  • One install can serve an entire company, covering every client and every LPAR.

How Meridian helps

Meridian is built for z/OS estates that need batch monitoring, prediction and action from one screen. It runs inside your network, your data never leaves it, and its footprint on the mainframe is light. One install serves a whole company, with per-LPAR pricing in two tiers, Watch and Act, plus a yearly company fee. A ninety-day proof of concept on one LPAR is free. It works with CA 7 and ServiceNow today. It shows subsystem status for CICS, IMS, Db2 and Adabas, and provides plain-language SLA predictions. All actions are presented as cards that require operator confirmation, and every action is recorded with its evidence. For more details see the product page, the service provider view and how an engagement runs.