zos 2.5 leaves standard support on 30 September 2026

← All posts

IBM’s published lifecycle record for z/OS 2.5 gives three dates. General availability on 30 September 2021. Withdrawal from marketing on 29 January 2024. Transition to extended or sustained support, which is the end of standard support, on 30 September 2026.

The last of those is a few weeks away. Nothing stops running on 1 October. What changes is the support position, the cost structure behind it, and the currency requirements that ripple outward from the operating system into compilers, subsystems and vendor products.

This post covers what the date actually means, what it triggers across the rest of the estate, and why a support cliff is a better moment to inventory than to panic.

What “transition to extended or sustained support” means

z/OS runs under IBM’s Enhanced lifecycle policy: a minimum of five years of standard support with an extension of three years available. The 30 September 2026 date is the boundary between those two phases, not the end of the product.

What you keep

Systems continue to run. Applications continue to run. Existing fixes remain available. Under an extended support agreement, service continues for the defined extension window, which under the Enhanced policy runs three years beyond the standard support end.

What changes

Extended support is a separately priced agreement. The practical effects reported by teams that have been through a previous cycle are consistent: an additional line in the software budget that finance did not plan for, a narrower scope of what is covered, and a weaker position when a defect requires a fix that would otherwise have been produced as ordinary maintenance.

What the ecosystem does

The more consequential change is external. Independent software vendors set their own support matrices against z/OS releases. New product versions target current releases. Some vendors withdraw support for a release once IBM moves it out of standard support; others follow after a delay. Each of those decisions is made by a different vendor on a different schedule, and the aggregate is a slow narrowing of what you can run and still get help with.

The currency chain this sets off

Operating system currency is rarely a single decision. It is the head of a chain.

Hardware architecture levels

Each IBM Z generation introduces instructions and facilities that compilers exploit through architecture level options. Running a current machine under an older operating system and older compilers means paying for hardware capability you cannot address. The relationship runs in the other direction too: newer z/OS releases carry minimum hardware requirements, which is why an operating system upgrade sometimes surfaces as a hardware conversation.

Compiler currency

The compiler position deserves its own attention, because the dates have moved recently and many estates are further behind than they believe.

Enterprise COBOL 6.3 left standard support in September 2025, with extended availability running to 30 September 2028. Estates that completed a version 4 to version 6 migration a few years ago and considered the matter closed are frequently sitting on a release that is itself now out of standard support.

The distinction that matters: moving from version 4 to version 6 is a significant change because the compiler front end and back end both changed, and code that compiled cleanly under version 4 can reveal latent data problems under version 6. Moving between version 6 releases is a far smaller exercise. Teams that conflate the two postpone a minor upgrade because they remember a major one.

We covered the behavioural side of this separately in what breaks when you recompile old COBOL.

Subsystem currency

CICS, Db2, IMS and MQ each carry their own lifecycle dates and their own compatibility matrices against z/OS releases. A z/OS upgrade usually requires at least checking, and often moving, one or more of them. Sequencing those upgrades is most of the planning work in a currency programme.

Language Environment and runtime

Compiled code depends on runtime services supplied by Language Environment, which ships as part of z/OS. This is the mechanism that lets modules compiled by long-withdrawn compilers keep executing: the compiler is out of service, the runtime is not. It is also the reason “our code still runs” is a weak argument against currency work. The code runs because the operating system underneath it is maintained. That maintenance is what the 30 September date changes.

Where z/OS 3 currently sits

For planning purposes, the current release positions are worth stating plainly.

z/OS 3.1 became generally available on 29 September 2023 and was withdrawn from marketing on 26 January 2026. z/OS 3.2 became generally available on 30 September 2025. Both run under the same Enhanced lifecycle policy.

A team moving off 2.5 now is choosing between a release already past its marketing withdrawal and the current one. The arithmetic usually favours moving to the current release, because it maximises the distance to the next forced decision, but hardware requirements and subsystem compatibility can constrain the choice.

Why this is an inventory moment

The temptation at a support boundary is to run the upgrade as a technical project, complete it, and return to normal. That is a missed opportunity, because the upgrade forces an estate-wide survey that nobody funds in ordinary conditions.

What the survey reveals

Currency projects consistently surface four findings.

• Load modules with no matching source. Programs are running that cannot be recompiled because the source was lost, superseded or never checked in. This is discovered at exactly the wrong moment, when a recompile is required.
• Compiler version spread. Large estates rarely sit on one compiler version. Different applications, acquired systems and vendor-supplied components compile under different releases, and the spread is wider than the inventory suggests.
• Programs nobody owns. Every estate has components whose owning application is genuinely unclear. Currency work forces the question because someone has to sign off on the recompile.
• Dead code. Programs and copybooks that no live path invokes, carried forward through every upgrade because removing them was never anyone’s mandate.

What to do with the findings

A currency project can treat those findings as obstacles to work around. It can also treat them as the deliverable.

The second approach costs slightly more during the upgrade and produces an inventory, a dependency map and a list of genuinely unreachable code that the organisation keeps afterwards. That output feeds compliance work, audit responses, staffing decisions and any later modernisation scoping. The techniques are the same ones described in how deterministic software transformation works.

Doing the upgrade without discovering data problems in production

The specific risk in a compiler currency step is behavioural rather than syntactic. Version 6 compilers are stricter about numeric validity than version 4 was. Data that was never valid but was tolerated for decades can produce different behaviour once recompiled.

Find the invalid data before the recompile does

Fields declared numeric that receive non-numeric content, unchecked moves between incompatible pictures, and arithmetic on fields that were never initialised are all detectable by static analysis. Running that analysis before the recompile converts a production surprise into a work item.

Test with production-shaped data

Synthetic test data tends to be valid, which is exactly what you do not want here. The cases that break are the ones the original programmers never anticipated, and those live in production history. Capturing representative production input, masking what needs masking, and running comparison tests is the approach that finds them.

Compare outputs, do not just check for abends

A clean run is not a correct run. Numeric handling differences produce different values, not failures. The verification standard is output comparison against a baseline captured before the change.

Building the case internally

Currency work is hard to fund because it delivers no visible feature. Three framings tend to work.

The support position is a risk statement, not a preference

After 30 September, the estate depends on an extended support agreement for its operating system. That is a documented, dated fact that risk and audit functions understand immediately, which is often more effective than a technical argument.

Currency is a precondition for everything else

Hardware exploitation, cost optimisation, subsystem features and most modernisation paths all assume reasonably current software. Deferred currency is not a neutral choice; it constrains every other option on the roadmap.

The work compounds if deferred

Each skipped release increases the size of the next move. Estates that upgrade steadily run small projects. Estates that skip cycles eventually run a large one, usually under time pressure created by a date exactly like this one.

The shape of an upgrade programme

Currency projects are planned badly more often than they are executed badly. The sequence below reflects what the dependencies actually require rather than what a Gantt chart prefers.

Establish the current position precisely

Before any target is chosen: which z/OS release each LPAR runs, which subsystem versions are installed, which compiler versions produced the modules in production, which ISV products are installed and at what version, and what hardware each partition runs on.

Most estates cannot answer the compiler question without analysis, because the answer is not one version. Modules compiled over two decades sit in the same load libraries, and the compile-time evidence is in the listings rather than the load modules.

Build the vendor compatibility matrix

Every installed ISV product has a support statement against z/OS releases. Collecting those statements is tedious and it is the item that most often determines the achievable target release.

The questions per product: is the installed version supported on the target z/OS release, is an upgrade available, what does that upgrade cost, does it carry its own prerequisites, and does any application code call the product directly. The last question converts a product upgrade into an application change, which is why it belongs in this exercise rather than in a later one.

Sequence subsystems against the operating system

CICS, Db2, IMS and MQ each have their own supported combinations. In practice this means an ordering constraint rather than a free choice, and identifying that ordering early prevents a plan that assumes parallel upgrades which the compatibility matrices forbid.

Decide the compiler position separately

The compiler decision is related to, but not the same as, the operating system decision. Modules keep executing under Language Environment regardless of the compiler that produced them, so a z/OS upgrade does not force a recompile. What forces the compiler conversation is support status, hardware exploitation and the features newer compilers provide.

The practical recommendation is to treat them as two workstreams with a defined handoff, rather than as one project, because the risk profiles are entirely different. An operating system upgrade is a systems programming exercise with a well-understood test approach. A compiler upgrade can change numeric behaviour in application code and requires application testing.

Testing an upgrade properly

The standard for a currency project should be the same as for a migration, for the same reason: a change that alters behaviour without failing is the one that causes damage.

Baseline before you change anything

Capture the outputs of a representative processing cycle before the upgrade, including month-end if the schedule allows. That baseline is the comparison reference and it cannot be reconstructed afterwards.

Compare outputs, not just completion codes

Jobs completing successfully is a weak signal. Numeric handling differences, collation differences where character set handling changed, and date processing differences all produce different values rather than failures. Field-level comparison against the baseline is what detects them.

Prioritise by what recompilation touches

If the programme includes recompilation, the test priority follows the recompiled modules, weighted by whether they perform arithmetic, handle numeric fields that may contain invalid data, or produce output that leaves the organisation.

Plan for the findings

Currency projects that find nothing usually did not look. Budget for a defect queue and for the analysis to work through it, and treat the absence of findings as a reason to check the test coverage rather than as a result.

Modelling the cost of deferral

Currency work competes for budget against visible deliverables and usually loses. Framing the comparison correctly helps.

The direct costs

Extended support charges for each product past its standard support date, which accumulate across the operating system, compilers and subsystems simultaneously. These are quantifiable and they appear in the software budget, which makes them the easiest part of the argument.

The scope cost

Each deferred cycle increases the size of the next move. An estate one release behind runs a routine upgrade. An estate three releases behind runs a project, usually with hardware implications, usually under a deadline created by a support date rather than chosen.

The option cost

Deferred currency constrains everything else. Hardware exploitation, subsystem features, cost optimisation levers and most modernisation paths assume reasonably current software. An estate that is materially behind has fewer available moves, and that constraint is invisible in any budget line.

The risk position

After a support boundary, the estate depends on a separately negotiated agreement for its operating system. That is a documented, dated fact that risk and audit functions act on, and stating it plainly is frequently more effective than any technical argument about features.

What to do in the next few weeks

For teams reading this close to the date, the realistic question is not whether the upgrade can be completed but what position to be in when the date passes.

Confirm the entitlement position

Establish whether an extended support agreement is in place, what it covers, what it costs and when it expires. That is a procurement question with a definite answer, and being unable to answer it is itself a finding worth escalating.

Record the position formally

A dated statement of which components are past standard support, what the mitigation is and when remediation is planned belongs in the risk register rather than in an engineer’s head. Audit and risk functions respond to that document, and its existence frequently releases budget that technical argument does not.

Start the analysis, not the upgrade

The upgrade cannot be planned credibly without knowing what the estate contains, which compiler versions produced it, what has no source and what nothing calls. That analysis can start immediately, runs in parallel with procurement, and produces an artefact that stays useful long after the upgrade.

Separate the urgent from the merely overdue

Not everything past a support date carries the same exposure. A compiler version out of standard support is a different risk from an operating system in the same position, because the operating system carries the runtime everything depends on. Sequencing by exposure rather than by date produces a defensible plan.

The wider currency picture

One useful habit that comes out of a forced upgrade is treating currency as a standing position rather than a periodic project.

Maintain a currency register

A single view listing every platform component, its installed version, its standard support end date and its extension end date. It takes an afternoon to build once the inventory exists and it removes the recurring surprise entirely.

Set a target distance

Organisations that decide how far behind current they are willing to be, and hold that line, run small upgrades continuously. Those that upgrade when forced run large ones under pressure. The total cost of the first pattern is lower and considerably more predictable.

Tie currency to the roadmap

Most modernisation options, cost optimisation levers and hardware exploitation assume reasonably current software. Making that dependency explicit on the roadmap turns currency from a cost into a precondition, which is a materially easier conversation with a budget holder.

Measuring currency debt

Currency is usually discussed as a binary: supported or not. That framing is why it loses budget arguments, because most of the estate is technically supported most of the time and the risk looks abstract.

A more useful measure is distance. For each platform layer, how many releases behind current are you, and what is the support status of that position?

The number that changes the conversation

The application row is the one worth computing first, because it is usually the most surprising. Very few estates can state what proportion of running modules were compiled under a currently supported compiler, and the answer is almost always lower than expected.

That single percentage does more to secure a currency budget than any description of features, because it is unambiguous, it is auditable, and it gets worse on its own.

What good distance looks like

Organisations that hold a deliberate position, typically no more than one release behind current on the operating system and on supported compiler versions throughout, run small continuous upgrades. Those without a stated position drift until a date like 30 September forces a large one.

Setting the target distance explicitly, and reporting against it quarterly, converts currency from a recurring emergency into a maintained metric. It costs almost nothing to start and it is the single practice that most reliably prevents the situation this post describes.

Common questions

Does z/OS 2.5 stop working on 30 September 2026?

No. Systems continue to run. The date marks the end of standard support and the transition to extended or sustained support, which is available as a separately priced agreement.

How long is extended support available?

Under the Enhanced lifecycle policy z/OS follows, standard support runs a minimum of five years with an extension of three years available. Confirm the specific dates for your entitlement against IBM’s published lifecycle page for the release.

Should we go to z/OS 3.1 or 3.2?

z/OS 3.1 was withdrawn from marketing on 26 January 2026 and 3.2 became generally available on 30 September 2025. Moving to the current release usually maximises the interval before the next forced decision, subject to hardware requirements and subsystem compatibility.

Do we have to upgrade our COBOL compiler at the same time?

Not necessarily at the same moment, but the two are linked. Compiled modules keep running under Language Environment regardless of compiler version, but compiler currency determines which hardware architecture levels you can exploit, and several COBOL releases are themselves out of standard support.

What is the riskiest part of a compiler upgrade?

Numeric behaviour. Data that was invalid but tolerated under an older compiler can behave differently after recompilation under version 6. Static analysis before the recompile, and output comparison testing after it, are what convert that risk into a managed work item.

Can we use this project to reduce the size of the estate?

Yes, and it is the natural moment. Identifying and removing code that no live path invokes changes no behaviour, shrinks what future upgrades have to touch, and reduces the surface that compliance work has to account for.

Is extended support a reasonable long-term position?

It is a bridge rather than a destination. It is separately priced, narrower in scope, and it accumulates across the operating system, compilers and subsystems at the same time. Organisations that treat it as a permanent arrangement find the combined cost and the narrowing vendor support matrix force the decision eventually.

What determines which z/OS release we can actually move to?

In practice the ISV compatibility matrix does, more often than the operating system itself. Each installed vendor product has a support statement against z/OS releases, and collecting those statements usually identifies the constraint before any technical work begins.

Should the operating system and compiler upgrades run as one project?

Better as two workstreams with a defined handoff. An operating system upgrade is systems programming with a well-understood test approach. A compiler upgrade can change numeric behaviour in application code and needs application testing. Combining them makes the risk profile of the whole project the worse of the two.

What proportion of our estate is likely to be on an unsupported compiler?

Higher than expected, because large estates are never on one compiler version. Modules compiled across two decades sit in the same load libraries, and the compile-time evidence is in the listings rather than the modules. Establishing the actual distribution requires analysis and is usually the most surprising number in a currency review.

Where to start

The decision in front of most teams is not which z/OS release to target. It is whether they have an accurate enough picture of the estate to plan the move confidently.

If the answer is uncertain, the useful first step is analysis rather than scheduling: what programs exist, what compiles under which version, what has no source, what nothing calls, and what depends on what. That picture makes the upgrade plannable and stays useful long after the upgrade is done.