Db2 for z/OS Agent: Multi-Tenant and Multi-SAF Support

Technical Reviewers: Eric Radzinski,  Abhijit Mohanty and Hariprasad Venkateshaiah

One Platform. Any Mainframe. Any Customer.

If you manage mainframe access - whether for your own enterprise environments or for multiple customers - you know the friction well: separate infrastructure for each customer, manual configuration changes every time you need to switch between mainframe systems, and the ever-present risk of getting something wrong.

This release of IBM Db2 for z/OS Agent directly addresses both of those problems. Two new capabilities, multi-tenant support and multiple SAF support, enable you to serve more customers on less infrastructure, and reach any mainframe system without touching a config file.

Multi-Tenant Support

Multiple customers or teams can now share one platform - completely isolated from each other.

Until now, if you were a service provider running Db2 for z/OS Agent for multiple customers, you needed a separate platform deployment for each one. That meant separate infrastructure, separate maintenance windows, and costs that multiplied with every new customer you brought on.

Multi-tenant support changes that model entirely. Now, all your customers share one platform instance - but each customer's agent is fully isolated. Their credentials, data, and operations are invisible to everyone else. The shared infrastructure brings your costs down; the isolation keeps their trust intact.

Picture this ... a managed service provider with 3 customers

Before: Three customers required three full platform deployments. You managed three separate stacks, paid for three sets of infrastructure, and onboarding a fourth customer meant building a fourth environment, taking days.

After: One platform. Three isolated agents. Customer A cannot see Customer B's data. Customer C operates completely independently. Adding a fourth customer takes minutes, not days and your infrastructure bill doesn't grow linearly with your customer list.

Why this matters to you

For service providers, multi-tenant support is a direct path to lower costs and faster growth — onboard new customers quickly without spinning up new environments. For large enterprises, it means different business units or teams can each have their own isolated agent on a single shared platform, with clean separation of concerns and no cross-team risk.

Multiple SAF-Support

One agent can now connect to multiple mainframe systems - each with its own security configuration.

Most enterprises run several mainframe environments: production systems (sometimes across multiple data centers), a shared development LPAR, test environments, and analytics systems. Each has its own Security Access Facility (SAF) configuration, its own credentials and security rules.

Previously, connecting to a different mainframe meant stopping the agent, manually reconfiguring it, swapping credentials, restarting, and hoping nothing went wrong. It was a 30-minute exercise with real risk attached.

Now, each mainframe connection is registered by name as a context. You specify the context you need in your request, and the agent routes you to the right system with the right credentials, automatically.

Picture this ... an enterprise with production, dev, and test mainframes

Before: Switching from Production East to the development LPAR: stop the agent → edit config files → change credentials → restart → test. Every switch was a manual process with room for error and real downtime risk.

After: Pass "context": "prod-east" and you reach Production East. Pass "context": "dev-shared" and you're on the dev LPAR. The correct credentials are resolved automatically. No restarts. No config edits. No downtime.

Why this matters to you

Development, test, and production environments all live under one agent configuration. Developers can target the right mainframe without any infrastructure changes, and the consistency across environments eliminates the configuration-drift errors that come from maintaining separate setups. Your operations team spends less time babysitting config files and more time on work that matters.

The Difference, Side by Side

The following example shows you how these capabilities deliver value in real-world scenarios:

Already using the agent?  

Nothing breaks. Existing connections without an explicit context are automatically assigned a "default" context. Your current workflows continue exactly as they are.

What This Release Means for Your Team

These two capabilities don't exist in silos. They work hand-in-hand to completely rewrite the economic and operational rules of managing mainframe access at scale.

If you're a service provider, you can grow your customer base without growing your infrastructure proportionally. If you're an enterprise IT team, your developers and DBAs can reach the right mainframe environment instantly, without creating tickets for someone to reconfigure an agent. Either way, the result is the same: less time spent managing tools, more time spent using them.

IBM Db2 for z/OS Agent is now a platform that scales with your business, not one that holds it back.