Everything on the mainframe that is not COBOL, and who owns it after you leave

← All posts

Mainframe exit programmes are scoped around application code, because application code is what the vendors price and what the business recognises. Then they overrun, in both time and cost, and only part of that overrun comes from the COBOL. Project overruns can also result from:

• COBOL complexity
• Poor code quality
• Unclear business rules
• Data conversion
• Testing and reconciliation
• Performance requirements
• Organisational decisions
• Scope changes

Those causes are well known, and a competent program plans for them. The overrun that was never in the estimate comes from the surround: the scheduler definitions, the security rules, the print and output management, the utilities, the vendor products, the interfaces to systems nobody listed, and the operational knowledge that exists only as habit. Individually, each item is small. Collectively they are a significant share of the program and the share that nobody budgeted for.This post is an inventory of that surround. It is deliberately unglamorous, because the value is in completeness rather than insight, and because the cost of discovering any one of these items late is disproportionate to its size.

Why the surround gets missed

Three structural reasons, worth naming because they are fixable.

The application inventory is produced by people who think in programs. The surround belongs to systems programming, operations and security, who are usually consulted after scope is set rather than while it is being set.

Much of the surround has no source code. A scheduler definition, a security profile and a print route are configuration, and configuration does not show up in a code analysis unless somebody deliberately looks for it.

The surround is invisible while it works. Nobody notices the job scheduler until it is not there, which is precisely the moment at which noticing is expensive.

The job scheduling and batch layer

Scheduler definitions

Whatever product runs your batch, the definitions inside it encode more business logic than anyone expects: calendars, dependencies, conditional execution, restart behaviour, and what happens when a job fails at three in the morning.

The migration question is not which modern orchestrator to use. It is whether the dependency graph in the scheduler reflects real data dependencies or accumulated convention. Estates almost always contain jobs sequenced because they have always been sequenced that way, with no underlying reason. Carrying that forward reproduces the constraint on a new platform, which is how organisations end up with a cloud batch estate that still has an overnight window.

JCL and catalogued procedures

JCL is not a wrapper around the program. It carries allocation, disposition, concatenation, condition codes, parameter passing and restart logic. Catalogued procedures add a layer of parameterised reuse that can be several levels deep.

Converting this is a translation exercise of its own, with its own semantics to preserve. Condition code logic in particular encodes decisions about what happens when a step fails, and that logic tends to be undocumented.

Generation data groups

Generation data groups provide versioned dataset access with relative references, so a program reads the previous generation without knowing its name. Restart, reprocessing and audit procedures routinely depend on that behaviour.

There is no direct equivalent on most target platforms. The behaviour has to be reconstructed, and the reconstruction has to preserve what the programs and the operational procedures both assume.

SORT and utility steps

Sort, merge, copy and dataset utility steps are a large fraction of step counts in most batch estates. Sort control statements can include field-level selection, summarisation and reformatting, which means some of them are performing application logic rather than sorting.

Sort behavior can change when data moves from an EBCDIC-based environment to a target platform with a different encoding or collating sequence. The impact depends on the sort utility, comparison rules, data representation, and target configuration r. We cover the mechanics in EBCDIC to ASCII sort order.

The data layer

File organisations

VSAM KSDS, ESDS and RRDS each have behaviour the programs rely on: key sequencing, alternate indexes, relative record access, and specific semantics around insertion and deletion.

Alternate indexes are often missed because they are defined outside the program source and may be represented in system definitions, catalogs, utilities, or operational procedures rather than in the application code itse

Sequential and partitioned datasets

Flat files with fixed or variable record formats, partitioned datasets used as source and load libraries, and the record format assumptions programs make about them. Variable-length records with an OCCURS DEPENDING ON table are the classic case where the layout cannot be understood without the program that reads it.

Databases

Db2 for z/OS, IMS DL/I, or both. Each brings its own conversion problem, and embedded SQL in COBOL brings host variable mapping, cursor semantics and dialect differences that change results rather than syntax.

Data in flight

Files transferred in and out on a schedule, often by FTP or a managed file transfer product, often to counterparties outside the organisation. These are the interfaces most likely to be undocumented, because they were set up by someone who has left and have worked ever since.

The security layer

Security profiles and rules

RACF, or its equivalent, holds dataset profiles, resource profiles, user and group definitions, and the mapping of business roles onto access.

The migration problem is not exporting the rules. It is that decades of accumulated exceptions are embedded in them, and nobody can distinguish a deliberate grant from a temporary fix that was never revoked. Mapping the rule set to a target security model without carrying forward the accumulated permissiveness is a project in its own right.

Identity and authentication

How users are authenticated, how service accounts work, how batch jobs run under whose authority, and what the surrounding audit expectations are. Regulated organisations usually have documented control objectives here, which must hold continuously through the migration rather than being re-established afterwards.

Encryption and key management

Where data is encrypted at rest or in transit, which facilities are used, where the keys live and how they rotate. This is also where post-quantum cryptography planning will land, and it is worth inventorying now rather than twice.

The output layer

Print and report distribution

Output management systems, spool handling, report distribution rules, archival retention, and downstream consumers who receive a file on a schedule and have integrated it into their own processes.

Statement and document production is frequently in this layer and frequently regulated, with retention periods and formatting requirements that are legally rather than technically determined.

Reports nobody reads

Every estate produces output whose recipients have left. The migration is the natural moment to establish which outputs are actually consumed, because the alternative is paying to reproduce them on a new platform.

The vendor layer

ISV products

Monitoring, automation, security, database tooling, file transfer, testing and scheduling products, each with its own licence, its own support matrix and its own dependency on the platform.

Three questions per product. Does an equivalent exist on the target? What does the contract say about termination and duration? And does anything call it directly from application code, which converts a product replacement into a code change?

Exits and customisations

System exits, user modifications, and locally written Assembler routines that extend vendor or system behaviour. These are the items least likely to be documented and most likely to be load-bearing.

The code you did not count

Assembler

Almost every large estate contains Assembler, usually for performance-critical routines, system interfaces or things COBOL could not express when they were written. It may have no source. It may have source that no longer assembles.

The decision per module is to translate, reimplement from observed behaviour, or retain through an interface. That decision shapes whether a complete exit is possible, and it needs to be made during scoping rather than in year two.

Other languages

PL/I, REXX, CLIST, Easytrieve, report writers and fourth generation languages bought in the 1980s. Each is a separate conversion problem with its own semantics, and each is routinely omitted from an inventory built by asking “how much COBOL do we have”.

Code with no source

Load modules running in production whose source cannot be located.Many estate has some. The number is discovered rather than known, and it constrains the options immediately, because a module with no source can only be reimplemented from behaviour.

The operational layer

Runbooks and recovery

What operations do when a job fails, how restart points work, what the recovery procedure is for each critical process, and how much of that exists only as the knowledge of people who have done it for fifteen years.

Service levels and the batch window

What the business has been promised, what actually happens, and the gap between them. Cloud architectures assume continuous operation; batch estates assume a window. Closing that gap is a business process change rather than a technical one, and it needs to be agreed rather than assumed.

Monitoring and alerting

What is watched, what triggers a page, and what thresholds encode. Thresholds are frequently the distilled experience of a decade of incidents and are worth capturing rather than reinventing.

Doing the inventory properly

The discipline that works.

Derive from artefacts, not interviews

Interviews produce the estate people remember. Analysis of source, JCL, scheduler definitions, catalogues and security rules produces the estate that exists. Do both, and reconcile the difference, because the difference is itself a finding.

Reconcile against production

What is running is the authority, not what is in the library. Load modules with no source, source never promoted, and environment-specific fixes all surface at this step.

Attribute everything to an owner

Every item needs a named owner, and the ones that cannot be attributed are the highest risk in the programme. Unowned components are what get discovered after cutover.

Classify by exit treatment

Each item is migrated, replaced, retired or retained. The retained list is the one that determines whether the platform can actually be switched off, which is the outcome the business is paying for and the one most often not achieved.

A classification that makes the inventory usable

A list of components is not yet a plan. What turns it into one is classifying every item by treatment and by the evidence behind that decision.

The four treatments

• Migrated: the item moves to the target platform in some form. Requires a target design and a verification approach.
• Replaced: the function continues but through a different product or mechanism. Requires selection, configuration and behavioural comparison rather than translation.
• Retired: the item stops existing. Requires proof that nothing depends on it, which is the step organisations skip and later regret.
• Retained: the item stays on the mainframe. Every entry here is a reason the platform cannot be switched off, which makes this the most important column in the inventory.

The evidence column

Each classification needs its basis recorded: analysis output, owner confirmation, vendor statement or assumption. Items classified on assumption are the programme’s risk register, and making that visible early changes how the schedule is built.

A worked shape

The unassigned row in that table is the kind of entry that decides whether a programme finishes on time. One unowned regulatory extract is enough to keep an LPAR running.

What programmes typically miss, and when they find it

Three patterns worth planning against, drawn from how exit programmes actually go wrong.

The interface discovered by its counterparty

A file transfer to an external party, set up years earlier, not in any inventory, discovered when the counterparty calls to ask why the file did not arrive. These are found by examining transfer product definitions and firewall rules rather than by asking, because nobody internally remembers them.

The component that only runs annually

Year-end processing, statutory reporting, annual renewal cycles. These are absent from a discovery exercise conducted over three months in the middle of the year, and they are disproportionately likely to contain special-case logic. The defence is to build the inventory from the scheduler’s full calendar rather than from observed activity.

The vendor product called from application code

A program that issues a direct call to an ISV product’s API converts a product replacement decision into a code change, and it is invisible unless the call graph includes external targets. Estates routinely discover these in the middle of a replacement, at which point both the code change and the product decision are on the critical path.

Sequencing the discovery

The inventory is not a single exercise and treating it as one produces a long phase with no output until the end.

Start with the artefacts that are machine readable

Source, JCL, scheduler definitions, catalogues, security rule exports and product installation records can all be parsed. That produces the largest share of the inventory quickly and identifies where the gaps are.

Then reconcile against production

What is running is the authority. Reconciliation against production surfaces the drift, the orphaned load modules and the components nobody expected to find.

Then attribute

Every item gets an owner. This is organisational work rather than technical, it takes longer than expected, and the items that resist attribution are the findings.

Then classify

Treatment decisions, with evidence. This is where the retained list forms, and the retained list is the programme’s real scope statement.

Then re-run it

The estate changes during the programme. An inventory built once and never refreshed is wrong by cutover. Building it from parsed artefacts rather than interviews is what makes refreshing it affordable.

The knowledge that is not in any artefact

Everything above can be derived from code and configuration. One category cannot, and it is worth naming because inventory exercises systematically miss it.

Operational judgement

When a job fails at two in the morning, the decision about whether to restart, rerun from a checkpoint, escalate, or let the business handle the consequence in the morning is made by someone applying experience. That decision tree exists in very few runbooks and in the heads of a small number of people.

Thresholds and tolerances

Why an alert fires at that value, why a job is expected to complete by that time, and what the actual business consequence of missing it is. These numbers are distilled from years of incidents and they are usually recorded without their reasoning.

The exceptions

Which counterparty needs their file early on the last working day of the month. Which report the regulator actually reads. Which process can slip and which cannot. This is the knowledge that determines whether a migrated system is operationally acceptable, and none of it is in the code.

Capturing it

The only reliable method is structured elicitation: sit with operations, walk the calendar and the failure modes, and write it down while the people are still there. It is unglamorous, it is cheap relative to its value, and it is almost always left until the people concerned have already left.

Using the inventory after the programme

The inventory has a second life, which is worth planning for because it changes how it should be built.

Compliance work reads from it, particularly component enumeration and interface mapping. Audit responses read from it. Cost attribution reads from it. Staffing risk assessment reads from it, because an inventory with owners attached is also a concentration map.

That argues for building it as derived artefacts that can be regenerated rather than as a document that ages. An inventory produced by parsing source, JCL, scheduler definitions and security rules can be refreshed on demand. One assembled manually is accurate on the day it is finished and decays from there.

It also argues for building it before the exit decision rather than after, because the inventory frequently changes the decision. Estates that look like straightforward exit candidates from the application layer sometimes turn out to have a retained list long enough that the platform cannot realistically be switched off, and that is considerably cheaper to discover during scoping.

The retained list is the real scope statement

Of the four treatments, one determines whether the programme achieves its objective, and it is the one nobody tracks as a headline number.

The business is paying to switch the platform off. Every item classified as retained is a reason it stays on. A programme with a retained list of three items and a programme with a retained list of forty have the same application scope and completely different outcomes.

Track it as a burndown

Report the retained list at every steering meeting, as a count and as a list of named items with owners. It is the only metric that moves in the direction of the actual objective. Programs converted is an activity measure; retained items remaining is a progress measure.

Categories of retained item, in order of how hard they are to clear

The bottom two categories are not engineering problems and they take longer than engineering problems. Finding them in month three rather than month twenty is the entire value of doing the inventory properly.

The single-item failure

It takes one retained item to keep an LPAR running. One quarterly regulatory extract, one file a counterparty depends on, one application nobody would claim. The platform costs do not scale down with the number of remaining workloads, which means the last item costs as much as the first hundred.

That asymmetry is why the retained list belongs on the front page of the programme report rather than in an appendix, and why an unowned row in the inventory is a schedule risk rather than an administrative gap.

Common questions

How much of a mainframe exit is non-application work?

It varies by estate, but organisations that scope only the application code routinely find the surround is a comparable or larger share of the effort. The safe assumption is that it is significant until your own inventory says otherwise.

What is most commonly missed?

Alternate indexes, condition code logic in JCL, undocumented file transfers to external counterparties, Assembler modules, and application code that calls a vendor product directly.

Can we migrate the applications and keep the mainframe for the rest?

You can, and many organisations end up there. The consequence is that the platform costs continue, which usually means the business case does not deliver. If a full exit is the goal, the retained list has to be driven to empty, and that has to be planned from the start.

Do we need this inventory if we are not exiting?

Yes. The same artefacts support compliance evidence, audit response, cost analysis and staffing risk assessment. The inventory is useful independently of the platform decision.

How long does the inventory take?

Considerably less than discovering the same items during execution. The work is mostly analysis and reconciliation, and it can run in parallel with early design.

Who should own it?

Someone with authority across application development, systems programming, operations and security, because no one of those functions can see the whole estate. The most common failure is an inventory owned by application development alone.

What is the single most useful metric for an exit programme?

Retained items remaining, reported as a count and as a named list with owners. Programs converted is an activity measure. The retained list is the only number that moves toward the actual objective, which is switching the platform off.

Which retained items take longest to clear?

Externally and contractually constrained ones: a regulatory extract whose format a third party controls, or an ISV contract running past the exit date. Neither is an engineering problem, both run on timelines you do not control, and finding them in month three rather than month twenty is the value of doing the inventory properly.

How should operational knowledge be captured?

Through structured elicitation with operations, walking the calendar and the failure modes and writing it down. Restart decisions, alert thresholds and the exceptions that matter exist in very few runbooks, and none of it can be derived from code.

Should the inventory be rebuilt during the programme?

Yes, because the estate changes and an inventory built once is wrong by cutover. That argues for deriving it from parsed artefacts rather than interviews, since a derived inventory can be refreshed cheaply and a curated one cannot.

The practical point

The COBOL is the visible part of the estate and the best understood. It is not usually what determines whether the programme succeeds.