The developer joined three months ago. Her first assignment: find every program that reads from the CUST-BALANCE field in the customer master record. Her manager told her the answer was probably around forty programs. She started with the CMDB, incomplete, last updated in 2021. She checked the application inventory, documents the systems but not the programs inside them. She asked the senior developer who has been on the team for twelve years, he guessed fifty, maybe sixty, hard to say for certain. She opened the mainframe source library and began reading COBOL files one at a time.
Six days later, she had a list of forty-seven programs. She was not confident it was complete.
That six-day manual search is the legacy codebase’s equivalent of looking for a document by opening every filing cabinet drawer in a building with no floor map. The filing cabinets exist. The documents are in them. The building has no index, no search bar, and no way to ask “where is everything that mentions this?” Enterprise search for legacy codebases exists to solve exactly that problem, to make the implicit inventory of a COBOL or mainframe application estate explicitly queryable, in seconds, with answers that can be verified against source rather than assembled from memory.
Find Anything in Seconds
SMART TS XL makes every field, program, copybook, and job in your legacy codebase queryable.
FIND OUT MORE…What Enterprise Search Means for Legacy Code
Enterprise search for modern environments, SharePoint, Confluence, Slack, Google Workspace, is well understood. You type a query, the index returns ranked results, you click through. The search works because modern content systems carry metadata: title, author, date, tags, and enough text for a full-text index to produce meaningful results.
Legacy codebases are different in every dimension that matters for search:
The content is code, not prose. A full-text search for “CUST-BALANCE” in a COBOL source library returns every file that contains that exact string, including comments, data definitions, and procedure division references. The search engine that is useful for this content must understand COBOL syntax, not just text.
The relationships are in the code, not in a catalog. The connection between CUSTPROC and CUSTMSTR is not in a database. It is in the COPY statement inside CUSTPROC. Finding these connections requires parsing the code, not indexing the text.
The inventory is incomplete by definition. An undocumented legacy codebase has no reliable catalog of what programs exist, what they do, or what relates them. The search must be the discovery mechanism.
The questions are structural, not keyword-based. A developer searching a legacy codebase is looking for a structural pattern: every program that calls a specific subprogram, every program that reads a specific dataset at a specific key. These are graph traversal queries, not keyword queries.
The Six Most Valuable Legacy Codebase Searches
| # | Query pattern | Who asks it | What it produces |
|---|---|---|---|
| 1 | Field cross-reference | Developer, architect | Every program that reads, writes, or redefines a field |
| 2 | Impact scope | Change board, tech lead | Blast radius of a proposed schema change |
| 3 | Dead code | Modernization team | Programs with zero inbound production references |
| 4 | Pattern search | Compliance, security | Every program matching a structural code pattern |
| 5 | Business rule extraction | Analyst, BA, auditor | Plain-language explanation and rule catalog |
| 6 | Regulatory exposure | GDPR, HIPAA, PCI team | Every program that accesses PII or regulated fields |
1. Field-level cross-reference: where is this data used?
“Find every program that reads, writes, or redefines CUST-BALANCE.” This is the question the developer in the introduction spent six days answering manually. An enterprise search for legacy code answers it in seconds by traversing the dependency graph from the field definition in the copybook to every program that includes the copybook and every paragraph that accesses the field.
The result is not just a list of programs, it is a structured inventory that distinguishes readers from writers from redefines from comments. The developer looking at this result knows not just that forty-seven programs reference CUST-BALANCE but which fourteen of them write to it, which two redefine it with a different layout, and which six reference it only in comments.
2. Impact scope for a proposed change
“If I extend CUST-BALANCE from nine digits to eleven, what breaks?” This is the impact analysis question that every change advisory board needs answered before approving a schema change. The search traverses outward from the changed field: which programs include the copybook that defines it (compile-time scope), which of those programs write the field to a flat file (data contract scope), which downstream systems read those flat files (cross-system scope). The answer is the blast radius, structured and verifiable.
3. Dead code identification: what never runs?
“Which programs in the CUSTMGMT library are never called by any production JCL job?” This query requires tracing inbound dependencies for every program in scope and filtering for those with zero inbound production references. The result is the dead code inventory, programs that exist in the library but never execute, which is the migration scope reduction that every modernization program needs before committing a budget.
4. Pattern search: find every program that does X
“Find every program that opens a file without checking FILE STATUS.” This is a compliance search, identifying a specific code pattern across the full portfolio. Unlike a keyword search, this requires structural analysis: the search engine must understand COBOL syntax well enough to recognize that an OPEN statement followed by a FILE STATUS check is different from one that is not. Finding this pattern across a portfolio of four thousand programs in minutes is the difference between a compliance posture that is assessed systematically and one that is assessed when an incident exposes a gap.
5. Business rule extraction: what does this do?
“Explain what GLPOST7 does and list every rule it applies.” This is a documentation query, the user wants to understand a program’s purpose and logic without reading four thousand lines of COBOL. The enterprise search surfaces the structural outline: what files the program reads and writes, what EVALUATE conditions it contains, what subprograms it calls, and what data it transforms. Combined with AI comprehension, this structural outline becomes a plain-language explanation with a structured rule catalog.
6. Regulatory exposure: where is regulated data processed?
“Find every program that accesses PII fields, name, SSN, date of birth, address.” This is a compliance inventory query. The search engine scans field definitions across all copybooks, identifies fields matching PII naming patterns and data type signatures (PIC 9(9) for SSN, PIC X(30) for name), and traces every program that includes those copybooks. The result is the PII processing inventory that GDPR data subject access requests and HIPAA assessments require.
Why Standard Search Tools Cannot Do This
The tools that work for general enterprise search, Elasticsearch, Coveo, Glean, Microsoft Search, are built for document and knowledge search. They excel at indexing natural language content, ranking by relevance, and surfacing the closest semantic match to a query. None of them understand COBOL.
Applying a text search engine to a COBOL source library produces results that match the query string but not the query intent. A search for “CUST-BALANCE” returns files that contain those characters, but it cannot tell you whether the match is a field definition, a MOVE statement, a READ key, or a comment. It cannot traverse the COPY dependency graph to find programs that reference the field through a copybook rather than directly. It cannot distinguish programs that run in production from programs that are dead code. It cannot follow a JCL DD statement to the program it invokes.
These are not limitations of the search engine’s quality, they are limitations of the search model. Text search against code is a category error. The questions legacy codebases require answered are dependency graph queries, structural pattern matches, and semantic code analysis. The tool that answers them must understand the language the code is written in.
ASK AI: Natural Language Over Verified Enterprise Context
The six search patterns above all require precise structural queries. Developers who work with COBOL every day can form those queries. Architects, analysts, compliance officers, and project managers who need the answers, but do not read COBOL, cannot.
ASK AI bridges this gap. It sits on top of the indexed, structured, verified application intelligence that SMART TS XL produces and accepts questions in plain language:
“Which of these programs apply the late-payment penalty, and where?”
“Explain this 40-year-old program in plain language.”
“Map every job and program that touches the CLAIMS table.”
“Extract every validation rule from the payment cycle.”
The critical distinction between ASK AI and a generic AI chat tool is the starting context. A generic chat tool begins with an empty prompt box, the user must find the right files, paste the right code, and hope nothing important was missed. ASK AI begins from an enterprise-discovered, controlled result set: the actual programs, copybooks, DB2 tables, and JCL jobs that SMART TS XL has indexed and structured. Every answer stays connected to the source evidence. Every finding is traceable to its source line.
This is not AI operating on best guesses from training data. It is AI operating on verified context from the actual codebase, the difference between asking someone who read a COBOL manual once and asking someone who has read every line of your specific COBOL.
Three layers, one intelligence stack:
- Enterprise Search, structural queries answered in seconds, no AI required
- ASK AI, natural language over verified enterprise context, inside SMART TS XL
- MCP Connector, same intelligence, available to any approved AI assistant from any device
| Generic AI Chat | SMART TS XL + ASK AI | |
|---|---|---|
| Starting context | Manually pasted snippets | Enterprise-discovered result sets |
| Application relationships | Absent from prompt | Code, data, jobs, schemas, dependencies |
| Scale | One file at a time | Thousands of programs in background analysis |
| Traceability | Answer separated from source | Findings linked to source lines |
| Repeatability | Depends on individual prompting | Saved, shared, parameterized prompts |
| Model choice | Vendor’s model | Organization-approved model |
The MCP Connector: Enterprise Search From Any AI Assistant
The Model Context Protocol (MCP) is the open standard that lets AI assistants call external tools. The SMART TS XL MCP Connector exposes the full application intelligence layer, enterprise search, cross-reference reports, field lineage, control flow analysis, impact analysis, as tools that any MCP-compatible assistant can call.
The practical result: a developer using Claude, ChatGPT, Microsoft Copilot, Gemini, or Grok can ask legacy codebase questions in plain language from the assistant they already use, and receive answers grounded in verified, source-connected SMART TS XL analysis, without opening a different tool, without exporting data, without copy-pasting code.
The interaction from the MCP Connector page demonstrates exactly what this looks like:
User asks: “Explain program GLPOST7 and show me everything it touches.”
MCP calls:
get_member_content,get_control_flow,cross_reference_reportResponse: “GLPOST7 posts daily GL transactions from the claims feed. It reads 2 DB2 tables, is called by 4 batch jobs, and shares 3 copybooks with the payment cycle. Here is the plain-language walkthrough, with each step linked to its source line.”
That answer, previously achievable only by a COBOL expert spending hours reading source files, JCL, and batch scheduler documentation, arrives in seconds from any approved AI assistant. The knowledge is not in the LLM’s training data. It is in SMART TS XL’s application intelligence layer, surfaced through the MCP connector on demand.
The MCP Connector exposes six core capabilities to any connected assistant:
| Capability | What it does |
|---|---|
| Enterprise-wide search | Programs, fields, jobs, and data types across every indexed environment |
| Source on demand | Member content and preprocessed code for any program or copybook |
| Cross-reference reports | Where-used analysis across programs, copybooks, tables, and jobs |
| Field and data lineage | Field relationships and redefinitions through COBOL data structures |
| Control flow and AST | Structured program understanding: syntax trees, complexity, call graph |
| Organizational context | Client, user, and domain context so assistants answer in your terms |
All of this is read-only, authenticated, and role-based, the AI assistant accesses the intelligence that SMART TS XL has, within the permissions the organization has granted.
From Six Days to Seconds: What Changes
Return to the developer at the beginning of this article. Her question, “find every program that reads CUST-BALANCE”, is a cross-reference query. With SMART TS XL’s enterprise search, she types the field name and receives the cross-reference report: forty-seven programs, structured by access type (read/write/redefine), each linked to the source line where the access occurs. The six days becomes thirty seconds.
The senior developer who guessed fifty or sixty is not wrong to be uncertain, that uncertainty is the honest answer when you are working from memory against a codebase that has never been systematically indexed. The uncertainty disappears when the codebase is indexed. The guess becomes a verified count, and the verified count becomes the foundation for every analysis that follows: the impact assessment before the field extension, the migration scope before the modernization wave, the test coverage before the regression suite.
Enterprise search for undocumented legacy codebases is not a productivity tool. It is the prerequisite for confident decisions about systems that have been managed by memory and intuition for decades. The inventory emerges from the query. The dependencies emerge from the analysis. The knowledge that was locked in the code becomes accessible to every member of the team, through structured search, through plain-language AI queries, and through every approved AI assistant that connects through the MCP.
How SMART TS XL Delivers Enterprise Search for Legacy Codebases
SMART TS XL’s enterprise search indexes the complete application landscape, COBOL programs, JCL job streams, copybooks, DB2 tables, datasets, and every dependency between them, and makes it queryable through a search interface that understands COBOL syntax, JCL structure, and cross-program dependencies. The queries that return answers in seconds are the same queries that previously required days of manual investigation.
ASK AI extends this capability to natural language: architects, analysts, compliance officers, and project managers can ask questions about the legacy codebase in plain English and receive answers grounded in verified structural analysis, not in the general knowledge of a language model that has never seen the specific codebase. The answers are scoped to the actual programs, linked to the actual source lines, and repeatable through saved and shared prompt templates.
The MCP Connector puts this intelligence into every AI assistant the organization approves: Claude, ChatGPT, Copilot, Gemini, Grok. A developer asking a legacy codebase question from a phone gets an answer from SMART TS XL’s application intelligence, structured, verified, source-connected, without switching tools or exporting data. The MCP connector is read-only, authenticated, and role-based: the approved AI works within the organization’s permissions, not around them.
The application dependency mapping is the foundation that makes cross-reference queries accurate: every CALL, every COPY, every dataset flow, every JCL program reference is in the dependency graph before any search is run. The cross-reference reports that enterprise search produces are derived from this structural model, not from keyword matching against source text.
The static code analysis adds the structural layer that distinguishes a search engine from a code intelligence platform: the queries that find every program with cyclomatic complexity above a threshold, every program that opens a file without checking FILE STATUS, every program that references a field in a REDEFINES variant, these are structural queries, not text searches, and they require the parsed, analyzed understanding that static analysis provides.
The transformation in one line: Six days of manual search across COBOL files → thirty seconds with a verified cross-reference report, structured by access type, linked to source lines.
The Codebase Knows. Now You Can Ask It.
The knowledge that six days of manual search eventually produces was always in the codebase. Every program that reads CUST-BALANCE was always in the source library. The COPY statements that link each program to the copybook were always in the source. The JCL that defines the execution context was always in the job library. The problem was not the absence of information, it was the absence of a mechanism to surface it.
Enterprise search for legacy codebases is that mechanism. Indexed, structured, queryable application intelligence that answers structural questions about code in seconds rather than days, and that, through ASK AI and the MCP Connector, answers those questions in plain language from any approved AI assistant the organization uses.
The codebase has always known the answer. Now anyone on the team can ask it.
