For organisations with large COBOL estates, performance optimisation can look deceptively simple.
A newer compiler becomes available. IBM says it can generate more efficient machine code. The logical conclusion seems obvious:
Recompile the application and collect the savings.
Sometimes that works.
But compiler optimisation is more nuanced than that.
Modern Enterprise COBOL can transform the generated program in ways that were not possible — or not performed as aggressively — by older compiler generations. It can eliminate duplicated calculations, replace expensive operations with cheaper ones, reorganise execution and exploit instructions available on newer IBM Z processors. (ibm.com)
At the same time, performance depends on the nature of the application, the compiler options selected, the hardware on which the program runs and whether the underlying data and program behaviour conform to the assumptions the optimiser is allowed to make.
The result is that newer compilers offer genuine opportunities, but performance modernisation should be measured rather than assumed.
Optimisation is no longer just a compiler switch
Older discussions of COBOL optimisation often focused on a relatively simple choice: compile normally or enable optimisation.
Enterprise COBOL 6 provides a much richer optimisation model.
IBM recommends OPT(2) together with appropriately selected ARCH and TUNE settings when organisations want maximum runtime performance. (ibm.com)
Those three settings address different parts of the problem.
OPTIMIZE controls how aggressively the compiler transforms the program.
ARCH determines which processor instructions the generated program is allowed to use.
TUNE tells the compiler which target processor it should optimise instruction choices for.
Together they allow the compiler to make much more sophisticated decisions than simply translating individual COBOL statements directly into machine instructions.
What OPTIMIZE actually does
The improvements introduced by OPTIMIZE(1) and OPTIMIZE(2) are important because many are invisible at source-code level.
A COBOL developer may write perfectly reasonable code without realising that several operations can be collapsed, moved or removed entirely by the compiler.
With OPTIMIZE(1), Enterprise COBOL can perform transformations including:
- eliminating duplicate calculations
- simplifying expensive arithmetic
- reducing unnecessary branches
- pre-computing constants at compile time
- removing unreachable code
- combining certain adjacent move operations
- inlining some
PERFORMlogic to avoid branching overhead
IBM describes examples where multiplication or division by powers of ten can be replaced by cheaper decimal shift operations, while binary operations involving powers of two may become simpler shift instructions. (ibm.com)
OPTIMIZE(2) goes further.
It can perform more aggressive instruction scheduling and optimisations that operate across basic blocks rather than only within them. IBM specifically documents techniques such as global value propagation and moving loop-invariant calculations outside loops. (ibm.com)
These transformations matter because performance improvements can come from doing less work, not merely executing individual instructions more quickly.
Repeated calculations are an obvious target
Consider code inside a loop.
If the same value is calculated repeatedly but does not change during the loop, a more advanced optimiser may be able to calculate it once and reuse the result.
Similarly, if several expressions contain identical intermediate calculations, the compiler may remove the duplication.
That sounds trivial in isolation.
Across programs that process millions of records or transactions, these small efficiencies can accumulate.
This is particularly relevant to mature COBOL applications.
Source code written decades ago may have been structured around the capabilities and compiler behaviour of hardware that bears little resemblance to today’s IBM Z systems.
Modern optimisation allows some of that code to benefit from newer hardware without requiring developers to redesign the underlying business logic.
ARCH lets the compiler exploit newer processors
The compiler can only use instructions that will exist on the hardware where the program needs to run.
That is where the ARCH option becomes important.
IBM defines ARCH as the architecture level the generated executable is allowed to target. Selecting a higher architecture level gives the compiler access to newer processor instructions. (ibm.com)
For example, Enterprise COBOL 6.5 supports architecture levels corresponding to several IBM Z generations.
But choosing the newest available level is not always correct.
An organisation may run production workloads on a newer IBM Z system while retaining an older machine for disaster recovery.
If the application must be capable of running on that older disaster-recovery hardware, its ARCH level needs to reflect the oldest environment on which execution may occur.
Otherwise the compiler could generate instructions that simply do not exist on the fallback system.
This turns compiler configuration into an infrastructure decision, not merely a development decision.
TUNE separates compatibility from optimisation
TUNE is particularly interesting because it allows organisations to distinguish between:
Where the program must be capable of running
and
Where the program normally runs.
ARCH governs the first question.
TUNE helps answer the second.
IBM says TUNE influences how the compiler selects among the instructions permitted by the chosen ARCH level in order to optimise the executable for a specific hardware generation. (ibm.com)
Imagine an organisation using a z16 in production and a z15 for disaster recovery.
The application needs an ARCH level compatible with the z15.
But the organisation would still prefer generated code to be tuned for the z16, because that is where it runs almost all of the time.
That is precisely the sort of scenario TUNE is designed to address.
IBM even documents examples where choosing a more appropriate TUNE level while retaining an older ARCH compatibility level produced significant performance improvements for certain workloads. (ibm.com)
The broader lesson is that compiler optimisation increasingly understands hardware deployment topology.
New instructions matter, but so does instruction selection
It is easy to imagine hardware exploitation simply as:
new processor = new instruction = faster program.
The reality is more subtle.
Even when multiple instruction sequences are available within the same architecture constraints, one sequence may perform better on a particular processor generation than another.
That means the compiler’s optimisation decisions can matter even when the generated program is not using instructions that are unique to the newest machine.
IBM explains that TUNE can influence these choices cumulatively across the program. Individual differences may be small, but together they can become noticeable. (ibm.com)
This reinforces an important point:
Compiler optimisation is no longer independent of infrastructure architecture.
Teams responsible for application builds need to know where those programs are expected to execute.
Not every workload benefits equally
This is where organisations should be careful.
A CPU-intensive COBOL program spending large amounts of time performing arithmetic, processing records or executing heavily repeated logic may be an excellent optimisation candidate.
A program whose elapsed time is dominated by database calls, network activity or external I/O may see less dramatic improvement.
The compiler cannot optimise away time spent waiting for another system.
Likewise, a batch workload consuming significant general-purpose CPU may have a stronger financial justification for optimisation than an infrequently executed utility.
That is why optimisation projects should begin with workload information.
Useful questions include:
- Which COBOL programs consume the most CPU?
- Which run most frequently?
- Which execute inside high-volume transaction paths?
- Which are repeatedly invoked by large batch jobs?
- Which are constrained by CPU rather than I/O?
- Which applications can be regression-tested confidently?
Optimising the right 10 percent of an estate may be far more valuable than recompiling 100 percent of it indiscriminately.
Compiler options involve trade-offs
Some compiler options can improve runtime performance while changing other characteristics.
IBM’s performance documentation highlights several such trade-offs. For example, certain options influence debugging capability, binary handling, floating-point register usage and threading overhead. (ibm.com)
OPTIMIZE itself introduces one important consideration.
Optimisation assumes that the program and its data are valid according to the compiler’s rules and selected options.
If an application contains invalid data or depends on behaviour outside those assumptions, changing optimisation levels can expose differences in runtime behaviour. (ibm.com)
That links directly to the compiler-modernisation problem discussed elsewhere on Inside Tech Talk.
The fact that a program has run successfully for years does not prove that every data condition it encounters conforms cleanly to its declarations.
More aggressive optimisation can expose problems that older generated code happened to tolerate.
Performance testing therefore matters twice
Benchmarking modern COBOL applications serves two purposes.
The first is obvious:
Did performance actually improve?
The second is just as important:
Did behaviour remain correct?
A responsible compiler-modernisation programme therefore needs both regression testing and performance measurement.
For performance comparisons, the test environment should be as controlled as possible.
The same representative workload should run against comparable data and ideally on the same hardware when comparing old and newly compiled modules.
Otherwise it becomes difficult to determine whether a performance change came from the compiler, the processor, workload variation or something else.
And organisations should measure the metrics that actually matter.
That may be CPU consumption rather than elapsed time.
For some batch processes, elapsed time matters enormously.
For others, reducing CPU use while maintaining similar elapsed time may produce greater economic benefit.
Performance gains may have direct financial value
On distributed infrastructure, developers sometimes treat small runtime improvements as interesting but economically marginal.
Mainframe economics can make the calculation different.
Large enterprise systems may execute enormous transaction volumes and batch workloads.
CPU consumption can therefore have direct capacity and software-cost implications.
If recompiling a heavily used program reduces the amount of processing required for every transaction, the aggregate effect may become meaningful.
That is particularly attractive because the application can sometimes gain those improvements without a business-logic rewrite.
The source remains COBOL.
The platform remains IBM Z.
The business process remains unchanged.
What changes is the efficiency of the generated executable.
That makes compiler optimisation one of the lower-disruption forms of application modernisation available to mainframe organisations.
But optimisation is not a substitute for architecture
There is a limit to what the compiler can do.
If an application performs unnecessary database queries, repeatedly transfers excessive amounts of data or uses an inefficient overall algorithm, compiler optimisation cannot transform it into a well-designed system.
Similarly, if an application is constrained primarily by I/O or an external dependency, faster arithmetic may have little impact on user-visible performance.
This matters because optimisation projects sometimes focus on what is easiest to change rather than what creates the bottleneck.
A newer compiler should therefore sit within a wider performance-engineering process.
Profile the workload.
Find where resources are actually being consumed.
Then decide whether compiler optimisation is one of the appropriate interventions.
Code written for old compilers may no longer need old tricks
There is another interesting consequence of improved optimisation.
Developers historically used coding techniques designed to help older compilers generate efficient machine code.
Some of those techniques may no longer provide the same advantage.
A sophisticated modern optimiser can recognise patterns and transform code in ways earlier compilers could not.
That means application teams should be cautious about perpetuating obscure coding conventions simply because they were once considered faster.
Readable, maintainable COBOL plus strong compiler optimisation can sometimes be preferable to source that has been manually contorted around assumptions from another generation of hardware.
That does not mean all historical optimisation advice is obsolete.
It means it should be tested against current compiler behaviour rather than treated as permanent truth.
The best candidates are not necessarily the oldest programs
When deciding what to recompile first, age alone is a poor prioritisation metric.
A thirty-year-old utility that runs once a month may offer almost no economic return from performance optimisation.
A fifteen-year-old transaction program called hundreds of millions of times may be much more interesting.
A sensible prioritisation model could consider:
CPU consumption
High-CPU applications offer obvious potential.
Execution frequency
Small savings multiplied across enormous volumes can become significant.
Business importance
Improving critical workloads may have operational value beyond CPU savings.
Hardware alignment
Programs built without awareness of newer processors may offer more opportunity.
Test coverage
Well-tested applications are safer early migration candidates.
Application knowledge
Teams need enough understanding to investigate behavioural differences.
Future lifespan
Optimising an application scheduled for retirement next year may have little value.
This makes performance optimisation a portfolio decision rather than a purely technical exercise.
What a practical optimisation programme looks like
A disciplined approach might look like this:
1. Profile the estate.
Identify the COBOL applications consuming significant resources.
2. Understand deployment hardware.
Document production, development and disaster-recovery processor levels.
3. Select appropriate ARCH and TUNE settings.
Compatibility and optimisation should reflect the real infrastructure.
4. Establish behavioural baselines.
Know what the existing application produces before recompilation.
5. Recompile initially with suitable diagnostics and testing.
Resolve invalid data and hidden assumptions before chasing maximum optimisation.
6. Evaluate OPT(1) and OPT(2) where appropriate.
Measure rather than assume the effect.
7. Benchmark representative workloads.
Compare CPU, elapsed time and other meaningful operational metrics.
8. Roll out by application or workload.
Start where the potential return justifies the testing effort.
9. Capture results.
Build internal evidence about which types of applications respond best to compiler optimisation.
Over time, that evidence can make future migration decisions much more precise.
Modern compilation is itself a form of modernisation
When people talk about modernising COBOL, the conversation often jumps immediately to rewriting applications, translating source code or moving workloads away from the mainframe.
Those can all be legitimate strategies.
But they are not the only forms of modernisation.
An application can remain COBOL and still benefit substantially from improvements in:
- compiler technology
- processor exploitation
- source control
- automated testing
- CI/CD
- observability
- development tooling
- application knowledge
That matters because many mature enterprise applications do not need to be replaced simply because their implementation is old.
They need to become easier to operate, understand and maintain.
Compiler optimisation is one part of that story.
The opportunity is in measuring, not believing
Modern Enterprise COBOL compilers are capable of sophisticated transformations that were unavailable to earlier generations.
They can remove redundant work, simplify calculations, schedule instructions more effectively and generate executables tailored to modern IBM Z processors.
Those capabilities are real.
But there is no universal percentage improvement that applies to every COBOL program.
IBM itself cautions that customer performance results vary according to source code, compiler settings and other factors. (ibm.com)
The strongest modernisation teams therefore do not approach optimisation with the question:
How much faster does COBOL 6 make our applications?
They ask:
Which of our applications can benefit, what configuration makes sense for our hardware, and what does the benchmark actually show?
That is a much more useful question.
And for organisations still running large COBOL estates in 2026, the answer may reveal that some of the easiest performance improvements are hiding not in a rewrite, but in the compiler they are already using.
