Bob meets the mainframe

When we launched Bob, we said the interesting problem was not writing new code but working inside a system that already exists — finding the right place to make a change, respecting conventions a team settled on years ago, keeping behavior consistent across files that have been growing for a long time.

The longest running version of "a system that already exists" runs on a mainframe. Decades of COBOL and PL/I, millions of lines, tens of thousands of programs wired together through Db2, CICS, IMS, and batch schedulers — code that continues to run the business without any disruption they cannot afford.

Today we're making IBM Bob Premium Package for Z (Bob PP4Z) generally available. It supersedes IBM watsonx Code Assistant for Z and brings IBM Z expertise — platform languages, middleware awareness, and deterministic enterprise wide analysis — directly into the Bob experience.

This is the engineering story, not a feature tour. Rather than list everything PP4Z does, we want to do three things:

Explain why a general-purpose model gets your mainframe applications wrong more often than it admits.
Show how we ground Bob in deterministic facts about your estate instead of probabilities.
Walk through the Z-specific modes, skills, and workflows — and what you can build with them.

1. Why the mainframe is the hard case

A general-purpose model pointed at a mainframe estate runs into three problems that no amount of smart prompting really fixes. The design of PP4Z provides solutions for each of these problems.

1.1. Scale, and what it does to a context window

A single business application can be millions of lines of COBOL, tens of thousands of interconnected modules across COBOL, PL/I, and assembler, and thousands of batch jobs chained by an enterprise scheduler. Even a "small" slice of 200 programs is comfortably hundreds of thousands of lines of code.

That does not fit in a context window, and the problem is not only the window. As context grows, model performance degrades (Chroma Research Context Rot Study, 2025) — answers get incomplete, inconsistent, or confidently wrong, the same way a human drowns in information overload. Pulling in "the relevant files" assumes you already know which files are relevant, which is exactly the thing you were trying to find out in the first place.

1.2. Meaning that isn't in the code

Mainframe code is semantically dense. The business meaning lives in field names and decades of convention, not in anything a parser can read. Some of it you can guess — SERIALN is probably a serial number, TOT-STTM probably a total settlement. Most of it you cannot: what is C-M? M-CAP? Why the CCZD prefix? What separates NO-SIN, NO-EVN, and NO-CNT?

The meaning is real and it is load-bearing, but it is not guessable from the code alone. The traditional answer is a data dictionary — but the scale (millions if not billions of variables) makes it daunting to build one by hand or with brute force and a language model.

1.3. The most likely answer is not the right answer

A language model returns what is statistically probable given its training distribution. Models are non-deterministic; the same question can get different answers on different days. On a system where a wrong answer about control flow can misstate business logic, it is a significant risk.

This is a scenario you have likely encoutered yourself before, assuming you recognized it. Take a real COBOL batch application: 233 programs, 742 copybooks, 20+ MB of code, with a heavily-called date utility, N991DATE. From the metadata, the ground truth is that 30 programs call it. Now ask a frontier model directly:

Day 1. It can't load everything, so it greps for static CALL statements and reports 13. Asked about dynamic calls, it widens the regex and reports 29. The one it misses, CHKOUTB, lives in a file called ROCHKOUT.cbl — because by convention a file name usually matches its PROGRAM-ID, but is never required to.
Day 2. Same question, different heuristics, and now it reports 31 — over-counting. One false positive, N285RODR, merely declares the literal 'N991DATE' in working storage and never uses it. The model reasons its way to that only after several follow-ups.

None of these heuristics are unreasonable. They are just not good enough, and "who calls X" is one of the core questions during impact analysis and program understanding. More advanced questions developers ask to understand programs and dependencies — which tables are updated in more than one program, which files are read but never written, which variables feed the computation of WS-UIT02 in PREMPZ72 — need complete, precise analysis that pattern-matching can't deliver.

The takeaway isn't "models are not useful for mainframe program understanding." It's that model response quality substantially improves with something true to reason over. Language models excel at processing data.

2. Grounding Bob in facts, not probabilities

PP4Z's answer is to stop asking the model to reconstruct the system from source code, and instead give it a deterministic, queryable representation of the estate to reason against. Three mechanisms do the grounding: the model is prompted to flag ambiguous z/OS constructs in the request itself; prompts are enriched with authoritative IBM Z insights, IBM documentation, reference material, verified samples and more, with general-purpose programming biases actively suppressed to keep the focus on the target platform; and the model is instructed to answer from analysis metadata first. The point is to make answers traceable to the IBM Z system, not to a training distribution.

2.1. Z Understand: a queryable model of your estate

Z Understand is the static-analysis platform underneath PP4Z. It runs on a server with access to your full source, ships scanners for COBOL, PL/I, and assembler plus JCL and schedulers like Control-M and TWS, and processes thousands of programs in parallel into one queryable repository. It holds deterministic, consistent structure across estates of 10,000+ programs.

It helps to think of it as a compiler pipeline with a different output: not an executable, but structured, queryable knowledge — data definitions, control flow across programs and jobs, precise data flow (including REDEFINES and memory offsets), and subsystem interactions.

2.2. Let the model write its own queries

How the metadata is exposed matters as much as the metadata. Fixed APIs and predefined MCP query patterns are very efficient for known and expected questions, but fall apart on open-ended analysis. During open-ended analysis one real question fans out into many sub-queries that change as the reasoning proceeds.

So we have taught Bob how to go beyond the provided ready-made queries and generate and run its own queries against the metadata. This leans on what models are genuinely good at — reasoning and query generation — and it scales the way structured data scales: whether you have 10 programs or 10,000, the query is the same; only the result set grows. In practice that means higher accuracy, more consistency across runs, and lower token consumption, because Bob reasons over relationships and types and pulls only the precise snippets the metadata points it to.

2.3. Extensibility, custom scanners, and runtime data

Pure syntactic analysis misses the relationships that matter when dynamic calls, API abstractions, and preprocessors hide the real flow. The Z Understand Extensibility framework closes that gap:

API call / macro resolution maps indirect and parameter-driven calls to their real targets, replacing generic call edges with concrete caller–callee relationships, via JSON config or user exits.
Preprocessor extensibility interprets non-standard statements while preserving the original source view, mapping cleanly between pre- and post-processed code.
Custom scanners bring proprietary languages, 4GLs, and even non-code sources into one model through a schema-driven JSON interface — you handle parsing and extraction, Z Understand handles storage, relationships, and analysis.

Static analysis tells you what can happen; runtime data tells you what did. PP4Z turns the debugger into a data-collection instrument — tracing execution paths, capturing variable values, observing branch decisions and subsystem calls — and hands those precise traces to Bob for the kind of complex fix static inputs can't support on their own.

2.4. The data dictionary: relevance over completeness

Documenting billions of variables is neither feasible nor maintainable, so PP4Z doesn't try. Deterministic analysis ranks variables by how much they actually drive behavior — usage frequency, spread across code regions, participation in control flow, interaction with databases and I/O — and selects the small set that reveals a program's purpose. For each, it assembles metadata, real usage snippets, and interaction patterns, then generates a business-level description.

The useful finding here: limited coverage is enough. Defining roughly the top 10-20 variables per program materially improves comprehension without exhaustive documentation. Z Understand Services automates this across whole portfolios from the CLI, a confidence score keeps only definitions above a threshold, and a human-in-the-loop step in the IDE lets developers review, correct, and align output with existing glossaries.

3. Specializing Bob for Z

Grounding gives Bob good facts. Specialization is what makes it behave predictably in an environment where outputs have to be explainable and processes have to satisfy governance. PP4Z is built on four pieces: modes, tools, skills, and workflows.

Modes set the role and the boundaries for an interaction flow. An architect-style mode prioritizes analysis, documentation, and dependency discovery, with code modification explicitly disallowed — so exploration can't quietly become a change. A developer mode is tuned for generation and refactoring with coding-standard enforcement built in. Governance lives in the interaction model itself.
Tools give the model direct access to structured system knowledge — program scanning, metadata interrogation, data-dictionary lookup, enterprise-wide analysis services — so it queries pre-computed facts instead of inferring over raw source.
Skills codify recurring expertise into repeatable, auditable steps applied at just the right time without bloating context. The implementation-planning skill, for instance, enforces a fixed sequence: acquire and validate context, frame requirements and surface assumptions, map impact from metadata, then produce a persisted, reviewable plan. Bob doesn't improvise the order.
Workflows add stateful orchestration — enforcing ordering, validating intermediate results, halting on bad input. The data-dictionary workflow stops if it finds no variables rather than inventing some. No silent failures, no skipped steps.

Standards and governance are enforced by default through repository-level agents.md rules — no extra infrastructure. And because IBM ships these skills and workflows in the box, you don't start from a blank slate: they encode IBM's own approach to COBOL, PL/I, z/OS middleware, and modernization. The coding-standards skill can learn your conventions straight from the codebase or ingest your existing standards document and turn it into an enforcement skill applied to every code-producing interaction. You can author your own skills too, without writing code.

When these compose, a single prompt can drive an end-to-end task:

"Add a column to the Motor Policy Table that captures whether the vehicle is electric. Apply my coding standards and update all impacted programs."

Bob reads the intent, builds a plan, selects the right modes, skills, and repository rules, and securely runs the tools needed to analyze programs, extract variables, update data definitions, and produce compliant results — governance, execution, and reasoning in one pass, with you approving the changes.

4. What you can build today

Documentation that doesn't drift. Treat docs as a generated artifact grounded in deterministic metadata plus source and runtime context — regenerable on demand, aligned to the current system, not a snapshot from three years ago.
Deterministic COBOL-to-Java transition on z/OS. Rewrites fail when functional equivalence is treated as approximate; a mortgage calculation has to return the same result despite differences in rounding and COBOL runtime semantics. PP4Z uses metadata as the backbone of the transformation, building parallel models of source and target so architecture is reproducible, business logic is mapped precisely rather than summarized, and validation is first-class — generating test cases from source behavior to prove equivalence.
Targeted refactoring and function extraction. Bob produces a ranked list of refactoring candidates annotated with business function, then extracts self-contained modules with clear inputs and outputs, traceability back to the original, and integration advice — preserving your COBOL investment.
Native z/OS tooling. Licensed Z Open Editor capabilities plus new MCP tools: Dependency Based Build (DBB) to run builds on z/OS from the IDE, Z Code Scan for rule-based quality checks and fixes inside Bob's workflows, and IBM Debug for z/OS to turn live debug sessions into AI-assisted root-cause analysis.

A note on honesty, since this is an engineering post: none of this removes the developer from the loop, and it isn't meant to. The modes, the approval gates, and the human-in-the-loop data dictionary all exist because on these systems "mostly right" is the failure mode, not the goal.

5. How to get access

Bob Premium Package for Z (PP4Z) is an add-on to IBM Bob, not a separate product you need to download. PP4Z runs against a live mainframe estate within an enterprise environment, there's no self-serve checkout — entitlement is sales-led.

Start with your IBM representative, or use Contact Sales on bob.ibm.com. They set up the base IBM Bob plan and the Z add-on for your organization.
Once your Bob administrator assigns you a seat with the Z add-on, the entitlement is detected when you use IBM Bob. Install the Bob IDE, sign in, and the Z-specific modes, skills, and tools appear.

6. Get started

If you're already running Bob, PP4Z adds the Z-specific modes, skills, and tools on top of what you have.
Use the embedded understand capability to get deeper insights into the code in your workspace.
Point Z Understand at a real application that can go well beyond your workspace — somewhere you already know the right answers — and check Bob's analysis against your ground truth.
Start with a question you've never gotten a straight answer to: who really calls this utility, which tables does this job touch, what does this variable mean?
Ask more challenging questions that mix data and reasoning: "Give me a call graph with diagrams organized by topics"

Links