Why Dependency Analysis Is the Foundation of Safer Change

The difficult part is often not finding the code, but finding what the code can affect

A request arrives to change one field in a customer record. The field has a familiar name, the owning COBOL program is known, and the edit itself looks modest.

Then the questions begin:

• Is the same layout included in other programs?
• Does a JCL-controlled batch process read the record overnight?
• Is the value stored in DB2 or IMS, displayed through CICS, copied into a file, checked by PL/I or Assembler, or passed to a Java service?
• Which reports and interfaces assume its present format?

And the list goes on.

At ITP Software, this is a central reason we position Panorama as a code-comprehension and software-intelligence tool. The job is not simply to find a symbol. It is to help people investigate the relationships around it and decide what those relationships mean for change.

A small edit can have a large dependency surface. Safer change starts by finding that surface before implementation begins.

Search Finds Names. Analysis Follows Relationships.

Text search is useful. It can find a field name, program name, table, copybook, transaction, or literal that an engineer already knows to look for.

It can also return too much, too little, or the wrong kind of evidence. A common name may produce hundreds of unrelated matches. An indirect dependency may not repeat the original name at all. Generated references, shared layouts, calls, scheduling steps, database access, and data movement may connect components in ways a simple string search does not explain.

Dependency analysis asks a different set of questions:

• What calls this component, and what does it call?
• Which definitions, records, files, tables, jobs, screens, and interfaces connect to it?
• Where are the direct relationships, and where does the path continue indirectly?
• Which components can receive, transform, store, display, or transmit the affected data?
• Which findings come from system evidence, and which still need an experienced reviewer?

That last question matters: Powerful analysis gives engineering judgement better material to work with.

The Dependency Boundary Is Wider Than Source Code

Large enterprise systems are held together by more than procedure calls.

A COBOL program may use a shared copybook whose record layout is consumed across several applications. JCL may determine when programs run and which datasets they read. A CICS transaction may connect a screen to logic and data that continue through DB2, IMS, files, queues, or reports. A PL/I or Assembler module may sit on a less visible but operationally important path. A Java component may consume an output created by mainframe batch without sharing any obvious source-level reference.

For this reason, a dependency review should consider several kinds of relationship.

Structural relationships

These include calls, includes, shared definitions, imports, references, and other links visible in the application structure. They help establish which components are connected and how far an initial investigation should travel.

Data relationships

A field can move through programs, records, databases, files, screens, and interfaces. Following that movement is often necessary when a change affects format, meaning, validation, privacy, or downstream processing.

Operational relationships

Jobs, schedules, transactions, runtime configuration, and deployment boundaries affect how code participates in production. A component that looks isolated in source may still be tied into an important batch or online sequence.

Cross-language relationships

COBOL, PL/I, Assembler, C, and Java may all participate in one business process. Analysis that stops at the language boundary can produce a tidy but incomplete scope.

Dependency Analysis Improves the Change Conversation

The immediate benefit is not a claim that every surprise disappears. It is that review becomes more specific.

Instead of saying, "this looks like a small COBOL change," the team can discuss the programs, shared structures, data stores, jobs, transactions, and interfaces that appear to be involved. It can separate confirmed relationships from areas that require subject-matter expertise. It can decide where regression testing should concentrate and where a proposed scope is still based on assumption.

This helps in several kinds of work:

1. Maintenance changes, where the goal is to correct or extend behaviour without disrupting adjacent processing.
2. Incident analysis, where reviewers need to trace what could have produced or consumed an unexpected value.
3. Modernization discovery, where project scope must reflect the system that exists rather than the application boundary shown on an old diagram.
4. Documentation, where generated relationship evidence can be checked and explained by people who know the business context.
5. Onboarding, where a new developer needs a route through the system rather than a folder full of source files.

The same dependency evidence supports each task, but the decision remains human.

How Panorama Fits Into the Investigation

Panorama helps organizations examine large legacy and enterprise codebases across programs, languages, definitions, data, and runtime artefacts. An investigation can begin with a field, program, job, transaction, table, file, or other known element and follow relevant relationships outward.

The reviewer might inspect cross-references around a COBOL data item, trace related programs and shared copybooks, examine DB2 or IMS access, follow JCL-controlled processing, and check connections to CICS, PL/I, Assembler, C, Java, files, or interfaces. The purpose is to build an evidence-based view of the change surface.

Panorama does not decide whether every connected component must change or be tested. Context still matters. A referenced field may be read but not modified. A historical path may no longer execute. A generated relationship may need confirmation against runtime or operational knowledge.

This is not a weakness in the process. It is the point at which software intelligence and engineering experience meet.

Start With One Real Change

A practical dependency review does not have to begin with an estate-wide map.

Choose one pending production change. Identify the element where the request appears to start, then follow its structural, data, operational, and cross-language relationships. Record what is confirmed, what appears relevant, and what needs expert confirmation. Use that evidence to review scope and testing before implementation.

If the investigation reveals a wider boundary than the original ticket described, it has done useful work early. If it confirms that the change is genuinely contained, that is useful too.

The aim is not to make every change look large. It is to stop an unknown dependency surface from being mistaken for a small one.