GDPS licensing: a resiliency offering of code plus services.

GDPS, Geographically Dispersed Parallel Sysplex, is IBM's family of resiliency and disaster recovery offerings built on Parallel Sysplex technology. It coordinates storage replication, recovery, and site failover so that a mainframe estate can keep running through a component failure or recover at a second site after an outage, with the sequence automated rather than run by hand under pressure. GDPS orchestrates mirroring technologies such as Metro Mirror for synchronous, short distance replication and Global Mirror for asynchronous, long distance replication, and drives the z/OS automation that brings systems back in the right order. Variants span HyperSwap Manager for single site continuous availability, Metro configurations for metropolitan distance disaster recovery, and Global configurations for out of region recovery. It is the automation layer that turns a recovery runbook into a managed, repeatable process.

GDPS is typically delivered as an offering that blends licensed automation code with IBM services rather than as a single shelf product. The control code and automation carry a license, commonly scoped to the systems and configuration it manages, and IBM services deliver the design, implementation, testing, and ongoing support the solution depends on. Because GDPS sits across the resiliency architecture, the commercial position is shaped by the configuration tier chosen, the number of sites and systems in scope, the replication technology underneath, and the size of the services wrapper. That makes it a configured engagement more than a list price line, and it means the cost is set by architecture decisions, not by a simple capacity metric.

Directional and pattern level. GDPS commercial terms are configured per estate. Confirm the exact licensing basis, the services scope, and the included variant in your own IBM contract before modeling a renewal.

The first driver is the configuration tier, because a single site HyperSwap Manager deployment and a multi site Global Mirror configuration are different orders of cost for different recovery objectives. The second is scope: the number of sites, systems, and managed devices the solution coordinates scales the position. The third is the replication technology underneath, since the synchronous or asynchronous mirroring that GDPS drives carries its own storage and bandwidth cost that travels with the resiliency design. The fourth is the IBM services component, where design, implementation, recovery testing, and ongoing support are a material part of the total. Because GDPS is configured rather than shelf priced, the cost follows the resiliency architecture, and a configuration bought for yesterday's recovery target can quietly outrun today's requirement.

GDPS exposure is mostly scope and configuration drift against what the contract describes. Common traps we see at pattern level:

Because GDPS is a configured resiliency offering, the levers are about matching the configuration to the requirement and pricing the services honestly. The five that pay:

Alternatives to GDPS exist, including hand built recovery automation, third party storage replication management, and the resiliency tooling within broader vendor portfolios, but the realistic options are narrower than for most products because GDPS is tightly coupled to Parallel Sysplex and IBM storage replication and because resiliency is the wrong place to take architectural risk for a saving. Replacing GDPS means rebuilding tested recovery automation, requalifying recovery objectives, and carrying real exposure through the transition, which most estates will not accept. The practical leverage is almost always internal: match the configuration to the recovery requirement, validate the scope, and price the services component properly. Where a wider platform or hosting change is already in motion, the resiliency design belongs inside that decision rather than as a standalone renewal.