Running many clients' mainframes from one operations floor

The provider's night

An enterprise running its own mainframe has one estate, one set of runbooks, one scheduler and one ticket queue. A service provider has many of each. The same operator may move between a bank's LPARs, an insurer's and a retailer's in an hour, each with its own job names, its own deadlines and its own rules about what may be done without asking.

That changes what goes wrong. It is less often a missing skill and more often a missing view: the WTOR that scrolled away on one client's console while the operator was in another client's scheduler, the restart sent to the right job name on the wrong system, the batch that was late because nobody was watching it at the moment it could still be saved.

What the tooling has to do

Say which client you are looking at, on every screen. Two estates with similar job names are a real risk. The client's name belongs on every screen, every card and every command.

Keep each client's rules its own. Alert rules, named batches, deadlines, approvals and the people who may act differ per client. A rule written for one client must never fire for another.

Put the job on one screen. Console, scheduler, batch status and tickets in one place, per client, with the things that need a person at the top and the rest quiet. Every switch between tools is time and attention, and on a provider's floor it is multiplied by the number of clients.

See the SLA before it is missed. Provider contracts carry SLA credits. A batch that will miss its deadline should say so while there is still time to act, in words both the operator and the client's manager read the same way.

Keep evidence a client can audit. After an incident the client asks what was seen, what was done, by whom and when. That record should exist already, per action, not be rebuilt from syslog and chat.

Let trust grow per client. One client wants every action approved by two people. Another is happy for routine replies to go out on their own. The tooling should allow both, per kind of situation, and move back the moment something is wrong.

Seats on the floor

A 24x7 seat has to be covered through nights, weekends, leave and training, so a provider's floor costs mostly seats. When the console, the scheduler, the tickets and the batch line for each client are on one screen, a seat can watch more LPARs than it can today, and the things that need a person rise to the top instead of being found.

Pricing that fits a provider

Much mainframe software is priced by capacity, in MSUs or MIPS, which ties the provider's tooling cost to each client's machine size. Per-LPAR pricing with no per-user charge is simpler to pass through to clients and lets every operator, SME and manager use the tool.