How Mixed COBOL, PL/I, Assembler, C, and Java Environments Create Hidden Dependencies

A practical view of why legacy-system analysis has to cross language boundaries.

A system is often called "the COBOL application" because that is the language most people see first.

That description may be convenient, but it can be incomplete. A production path that starts in COBOL may pass through PL/I, touch an Assembler routine, call a C utility, write to DB2 or IMS, run through JCL-controlled batch, update a file, appear on a CICS screen, and then feed a Java service or downstream reporting process.

By the time a modernization team looks at the estate, years of extensions, migrations, interfaces, acquisitions, tactical fixes, and operational workarounds may have blurred the boundaries. The system still runs. The dependency map in people's heads is much less reliable.

A legacy estate is rarely risky because one language is old. It is risky because the relationships across the estate are hard to see.

At ITP Software, this is why we describe Panorama as a code comprehension and software intelligence tool for large legacy and enterprise systems. The useful question is not only "where is the COBOL?" It is "what does this business process depend on, across every language and runtime that participates?"

The Single-Language Shortcut Is Tempting

Single-language thinking makes planning feel simpler.

If the project is described as a COBOL modernization, the discovery checklist can become COBOL-centric. Count the programs. Review the copybooks. Find the transactions. Estimate the conversion effort. Decide what can move to Java or another target architecture.

That may be a reasonable starting point. However, it is not enough.

In many long-lived systems, the interesting dependency is not inside one program. It sits at the handoff between components. A field moved by a COBOL program may be interpreted by PL/I logic. An Assembler routine may handle a performance-sensitive or platform-specific function that few people now touch. A C component may connect to an external interface. A Java service may depend on a file or database state created overnight by mainframe batch.

The system boundary is not the language boundary.

Where Hidden Dependencies Usually Appear

Mixed-language dependencies often show up in places that look ordinary until a change exposes them.

Shared data definitions

Copybooks, include files, record layouts, database structures, message formats, and interface definitions can connect programs written in different languages. A field change may look local in one module while affecting validation, reporting, or downstream processing somewhere else.

Batch and scheduling chains

JCL and batch orchestration often reveal dependencies that source-code search alone may not explain. A nightly process can connect COBOL, PL/I, Assembler utilities, files, database updates, reports, and distributed handoffs in a sequence that matters as much as the code itself.

Screens, transactions, and operational paths

CICS transactions, online screens, forms, and operational tools may expose data created or transformed elsewhere. The user-facing part of the system may depend on a long chain of jobs, tables, files, and language-specific modules.

Interfaces between old and new components

Modernization rarely replaces everything at once. Old and new components run side by side. A Java service may depend on mainframe-created data. A migration adapter may preserve a record layout because several downstream consumers still expect it. An API may hide a dependency rather than remove it.

Code that is still important but no longer familiar

Assembler, PL/I, or older C components can survive because they solve a specific problem, are stable, or sit in a sensitive part of the flow. Their stability can make them invisible until a surrounding change touches them.

What Good Analysis Should Answer

A useful analysis view should help reviewers move from a language inventory to a relationship picture.

For a mixed estate, reviewers should be able to ask:

• Which COBOL, PL/I, Assembler, C, Java, JCL, CICS, DB2, IMS, file, screen, and interface elements participate in this process?
• Where does data originate, change, get stored, get displayed, and leave the system?
• Which dependencies are direct, indirect, generated, copied, scheduled, or mediated through shared structures?
• Which paths are confirmed by code and configuration evidence?
• Which assumptions still require subject-matter expert review?

That last point is not a disclaimer. It is engineering discipline. Enterprise software analysis should make uncertainty visible, not hide it behind a confident-looking diagram.

Why This Matters Before Modernization

A modernization estimate can go wrong when discovery treats a mixed estate as if it were a clean application in one language.

The team may underestimate the number of interfaces. It may miss data paths that cross batch and online processing. It may assume a Java replacement can be scoped around a COBOL module without accounting for PL/I routines, Assembler utilities, DB2 or IMS structures, JCL, files, or reports.

The result is not just a technical surprise. It affects scope, testing, sequencing, data migration, documentation, user acceptance, and the credibility of the plan.

Mixed-language analysis is also useful when no migration is planned. Maintenance teams still have to change fields, correct logic, review incidents, onboard developers, update documentation, and decide whether code is safe to retire. Those decisions are better when cross-language dependencies are visible.

A Practical Takeaway

Before scoping a modernization project, pick one important business process and trace it across language boundaries.

Start with the visible application. Then follow the data, jobs, screens, database structures, files, interfaces, and generated or shared definitions around it. Look for COBOL, PL/I, Assembler, C, Java, IBM Z, z/OS, CICS, DB2, IMS, JCL, batch, and distributed handoffs.

If the path is difficult to explain, the organization has found useful discovery work before it has found a migration problem.

That is a better moment to ask hard questions. It is cheaper, calmer, and more honest than discovering the same dependency after a project plan, budget, or release date has already assumed it away.

How Panorama Fits

Panorama is built to help organizations understand large legacy and enterprise codebases before they change them. In a mixed-language estate, that means supporting investigation across languages, dependencies, cross-references, data movement, and documentation gaps.