Dead code, tools and building the backlog
Discovery usually finds code nobody uses, which can be retired carefully to shrink the estate. Tools speed up the analysis, but people must validate the results, and the final output is a prioritised, evidence-based modernization backlog.
Finding dead code
Dead code comes in two sizes. Dead programs and jobs are whole components that are never run: no caller, no transaction, no scheduler entry and no runtime evidence. Unreachable code is logic inside a live program that can never execute, such as a paragraph no PERFORM reaches or a branch whose condition can never be true. Large estates commonly contain a meaningful share of both, and every dead component still costs effort in upgrades, compiler migrations and testing.
- Static check: no callers, not referenced in any JCL, PROC, scheduler definition, CICS or IMS definition.
- Runtime check: no SMF, CICS or Db2 evidence of execution over a full business cycle.
- Owner check: the business and application owners confirm there is no seasonal, legal or disaster-recovery use.
- Quarantine: remove from production paths or move to an archive library, keeping source and load recoverable.
- Retire: after an agreed waiting period with no impact, remove it formally through change management.
Tools at concept level
Doing discovery by hand on a large estate is slow and error-prone. Analysis tools parse COBOL, PL/I, Assembler, JCL, CICS and Db2 definitions, build a repository of relationships and present graphs, reports and searches. Some also load runtime data. Well-known examples include:
- IBM Application Discovery and Delivery Intelligence (ADDI): builds a repository from mainframe source and definitions and provides call graphs, impact analysis and reports.
- OpenText (formerly Micro Focus) Enterprise Analyzer: application analysis and impact reporting for mainframe languages.
- BMC AMI DevX Code Insights: program structure, flow and runtime visualisation for developers.
- CAST Imaging and other software intelligence products that map multi-platform applications.
- Assessment tools offered by cloud providers and service companies as part of modernization programmes.
Features, language support and licensing vary by product and version. Some vendors now add AI assistance that summarises programs or suggests groupings; treat such output as a draft to be checked by people who know the system, and confirm that your source code may be processed by the tool under your data governance rules.
From evidence to backlog
The output of discovery is not a diagram; it is a modernization backlog: a list of candidate pieces of work, each with evidence, a recommended approach and a priority. Common approaches are:
| Approach | Meaning | Evidence that suggests it |
|---|---|---|
| Retire | Remove it | Dead code, duplicated function |
| Retain | Leave it as it is | Stable, rarely changed, works well |
| Refactor | Improve structure in place | Frequently changed, high complexity, many defects |
| Expose | Wrap as an API or event | Function wanted by new channels, clear inputs and outputs |
| Rehost or replatform | Move to another runtime | Loosely coupled, few links to shared data |
| Replace | Swap for a package or service | Commodity function, high cost to maintain |
Priority usually combines business value, change frequency, risk, complexity and coupling. A component with many inbound and outbound links is risky to move first; a well-bounded component with clear interfaces is often a good early candidate. Keep the evidence attached to each backlog item, so decisions can be revisited when the facts change.
Common mistakes
Code can be reached in ways analysis misses. Combine static, runtime and owner evidence, then quarantine before retiring.
Tools find relationships quickly but miss dynamic and external links and may mislabel things. People who know the system must validate results.
Discovery is only useful when it ends in a prioritised backlog with evidence and a recommended approach per item.
What you will see at work
- Application owners are asked to sign off retirement lists before anything is removed.
- Architects present the modernization backlog to management with evidence for each recommendation.
- Clean-up of dead code is often scheduled before a compiler or Db2 upgrade, to reduce testing effort.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.