It's the middle of the night, and a batch window that normally finishes by four is still running. Whoever's on call has to answer a question: is this a real problem, or just noise?
What's on the screen right now likely won't settle it. Every mainframe shop already watches the numbers that matter: CPU utilization, dataset growth, missed SLAs during a critical batch window, whatever would put the whole organization at risk if it slipped. Tracking them was never the hard part. But how long has this potential problem been building before the emergency? The insight only matters as much as the context behind it, and 500 GB of DASD used today is just a fact. 500 GB today, set against 420 GB six months ago and 350 GB the year before, is a trend line you can plan around.
That's because every forecast you make about a mainframe is really a statement about the past. Will you run out of DASD before the next fiscal year? Will you still make your SLAs during the batch window eighteen months from now? Every answer is pulled from what already happened, and the further back the record reaches, the more confidently you can plan. Which is what makes losing that history so damaging. And it rarely goes in a single dramatic event. A team falls out of sync, a migration or tooling change doesn't carry the old records forward, or someone clears out data nobody expected to need again. You tend to find out on the day you needed it most. That isn't a dashboard problem, it's a data availability problem. It's also why, when we built OPTIMAⁿ, we started from a different premise: a report is only as good as the data behind it, and no one should have to give up their history to move forward.
This is where most performance and capacity tools quietly fall short. They answer one question well, what's happening right now, and that is genuinely useful. But it's a snapshot, not a story. Without a deep record behind it, a report can tell you a job ran long today. It can't tell you whether that's normal for the first of the month, whether it's been trending that way for six quarters, or what next quarter is likely to demand. Ask it whether something is normal, and what comes back is a guess dressed up as an insight.
Depth is exactly what changes the answer. OPTIMAⁿ sits on top of the data your enterprise has already generated across decades of mainframe operations, pulling from SMF and other z/OS sources and carrying that history forward instead of starting the clock over. With that much behind it, seasonality becomes visible, slow drift that hides inside a short window shows up, and a spike finally has context, measured against how that same process behaved the last twenty times it ran.
Take that spike at 2am. On its own it could mean anything. Set against the same window from past months, you can tell almost immediately whether it's routine or worth waking someone for. That's the role OPTIMAⁿ plays, and it stays consistent: it surfaces what the data shows and points you toward what to look at next. It informs the call rather than making it, so your team still decides, now with the full history behind the decision. The same logic drives capacity planning. If a batch job's runtime has crept up 8% over three quarters, that trend will likely hold unless something changes, and that matters when storage, processor capacity, and hardware refreshes are decided months ahead and expensive to get wrong.
Found something worth keeping an eye on? Ask the chat bot to build the query, save it, and run it again whenever you need it, all without leaving the interface for a separate Db2 query tool.
None of that depth counts for much unless what you do with it is sound. The metrics themselves are standard: CPU, DASD, and batch windows are the same measures every shop watches. What isn't generic is the baseline. You can check your numbers against industry benchmarks, but they're not one size fits all, since they're not built from your environment. What counts as normal here is drawn from the history your own systems have built, so recommendations reflect how your environment actually behaves rather than a model of what systems like yours might typically do. And it only holds together if that data lives in one place instead of scattered across systems that don't talk to each other, so capacity planners and performance analysts are working from the same numbers rather than reconciling five exports before a meeting starts.
All of that depth only helps if the people who need it can actually reach it. OPTIMAⁿ includes a built-in AI chatbot for reporting, so a capacity planner or an operations lead can ask a plain-language question and get an answer drawn from their own environment instead of a generic template.
Say last night's batch window ran 40 minutes long. Normally, finding out whether that matters falls to an analyst pulling SMF extracts and building a spreadsheet, and everyone else waits until that person has time. Here, the operations lead asks in plain language and gets an answer built from three years of the enterprise's own month-end closes before the standup even starts. The shift isn't a sharper insight, it's who can reach it: the people who need the answer stop queuing behind the one person who can produce it.
Most shops don't fully value their historical data until they need it and realize it's not there. Six months from now, when someone asks whether current batch runtimes are actually a problem or just noise, the answer lives in the history you're building today. The value of a reporting tool isn't just what it shows you. It's how much history it can stand on when it tells you what that data means. Modernizing your tooling should never mean forfeiting it.
So here's the question worth asking:
How much history is your reporting really standing on?
If you're modernizing your tooling and wrestling with what happens to the data behind it, reach out, and let's talk about what your own history could be telling you.
Reach out to eden.nomes@21cs.com or visit 21cs.com. Let's set up time to show you what this looks like running on your own systems.
Eden Nomes is z/OS Product Manager at 21CS