Pole TRANS-AMT-CD in a COBOL program has been in production since 1981. The FD entry defines it as PIC S9(9)V99 COMP-3, a packed decimal signed numeric field, eleven digits, two implied decimal places. That is the technical metadata. The business metadata, what TRANS-AMT-CD actually means, what currency it is denominated in, whether the two implied decimal places mean cents or basis points, whether a negative value represents a credit or a debit, and how a zero value should be interpreted, exists nowhere in the codebase. It existed in a functional specification document that was printed in 1981, archived in a filing cabinet, and has not been seen since. The two developers who originally knew what TRANS-AMT-CD means both retired in 2014.
This is the metadata situation that every organization with multi-decade data systems faces, and it is the metadata situation that modern data governance frameworks were not designed to address. Collibra, Alation, Atlan, and every other enterprise data catalog platform are excellent at governing metadata for data that is already described, cloud databases with documented schemas, data warehouses with defined column semantics, API endpoints with OpenAPI specifications. They are not designed to reconstruct metadata that was never formally captured, that exists only in the behavior of programs written before metadata management was a discipline, and that has been modified by dozens of developers over four decades without anyone updating a central record of what each field means.
Metadata management for multi-decade data systems is not the same problem as metadata management for modern systems. It requires a fundamentally different approach, one that begins with metadata extraction from source artifacts rather than metadata ingestion from connected systems.
Find Meaning Before It Retires
SMART TS XL extracts field-level technical metadata from FD entries and copybooks before catalog tools can govern it.
ZJISTĚTE VÍCE…The Three Layers of Legacy Metadata
Understanding the metadata problem in multi-decade systems requires recognizing that metadata in these environments exists in three distinct layers, each with different extractability, different completeness, and different governance implications.
Technická metadata is the most extractable layer. It describes the physical structure of data: field names, data types, lengths, positions within records, numeric precision specifications, and the relationships between fields within a record layout. In COBOL environments, technical metadata exists in source code artifacts: FD entries define record layouts, COPY members define reusable data structures, SELECT clauses define file organization and access methods, and JCL DD statements define the datasets associated with each program execution. This layer is machine-readable in principle, a parser that understands COBOL syntax can extract it from source code, but it is distributed across thousands of source files rather than centralized in a schema registry.
Provozní metadata describes how data moves through the system: which programs produce which datasets, which programs consume them, in what sequence, and through what transformations. In mainframe environments, operational metadata is distributed across JCL job streams (which define execution sequences and dataset associations), program call graphs (which define inter-program data flow), and the scheduler configuration (which defines timing and dependencies). This layer is also machine-extractable from the source artifacts, though the extraction requires understanding not just individual programs but the relationships between them.
Business or semantic metadata is the least extractable and most valuable layer. It answers the questions that technical metadata cannot: what does TRANS-AMT-CD actually mean in business terms? What are the valid values for ACCT-TYPE-CD and what does each value signify? What business rule determines when CUST-STATUS-FLG přechody z A na I? This layer exists, when it exists at all, in specification documents, in developer memory, in institutional knowledge held by employees who may have retired, and in the procedural logic of programs that enforce business rules through IF statements and EVALUATE blocks rather than through database constraints.
The metadata challenge for multi-decade systems is that these three layers have been managed differently, or not managed at all, across decades of system evolution. Technical metadata was captured in source code but never formalized into a data dictionary. Operational metadata was implicit in JCL job streams but never documented as a lineage record. Business metadata was documented in specifications at the time of initial development and never updated as the systems evolved.
The Metadata Drift Problem
Every year a multi-decade system operates without systematic metadata management, the gap between the metadata that exists in formal documentation and the metadata that reflects the system’s actual current behavior widens. This drift occurs through four mechanisms:
Field meaning evolution. A field that was defined with one business meaning in 1978 may have accumulated additional meanings over subsequent decades. ACCT-TYPE-CD may have originally distinguished checking from savings accounts. Over forty years, additional codes may have been added to represent money market accounts, certificates of deposit, IRA accounts, and escrow accounts, each addition documented only in the program code that handles the new code value, not in any central field definition. The field’s name and type are unchanged; its semantic meaning has grown substantially more complex.
Silent repurposing. Fields are occasionally repurposed without renaming. A field that was used for one purpose becomes inconvenient to extend, and a developer uses a previously unused value of an adjacent flag field to encode a different piece of information. TRANS-FLAG-1 may now encode three different concepts across different program contexts, distinguishable only by examining which programs read the field and under what conditions. The technical metadata, field name, type, length, provides no indication that the field is semantically overloaded.
REDEFINES accumulation. As discussed in VSAM analysis contexts, REDEFINES clauses overlay the same physical storage with different field interpretations. Each REDEFINES variant may have been added at a different point in the system’s history, by different developers, for different business purposes. The complete semantic meaning of a REDEFINES hierarchy, which variant applies when, what each variant’s fields mean, can only be reconstructed by analyzing all the programs that access each variant and the conditions under which they do so.
Copybook divergence. When a standard COBOL copybook is modified to accommodate a new requirement, programs that included the copybook and were not updated to handle the new field may behave incorrectly or may simply ignore the new field. Over decades of evolution, multiple versions of what is nominally the same copybook may exist in different libraries, with different programs using different versions. The metadata for a field defined in the copybook may differ across programs depending on which version of the copybook each program includes.
What Modern Metadata Tools Cannot Do for Legacy Data
The enterprise data catalog market has matured significantly. Collibra, Alation, Atlan, Microsoft Purview, and Informatica Axon are sophisticated platforms for governing metadata across modern data environments. They excel at: auto-discovering schemas from connected databases, tracking column-level data lineage across ETL pipelines, maintaining business glossaries with curated term definitions, and surfacing data quality metrics alongside metadata records.
What these tools cannot do for multi-decade COBOL and mainframe systems:
They cannot connect to what they cannot see. Modern catalogs discover metadata through connectors, JDBC connections to databases, API integrations with cloud services, scanner integrations with supported platforms. VSAM files, COBOL programs, and JCL job streams have no standard catalog connectors. The catalog cannot discover what it has no mechanism to reach. The data managed by these systems is effectively invisible to the catalog, which means the lineage records for downstream cloud analytics that derive from this data are incomplete or absent.
They cannot extract metadata that exists only in code. A data catalog that is connected to a DB2 database can read the database schema, table definitions, column names, data types, indexes. It cannot read the COBOL program that populates the DB2 table to understand what business rules govern the population, what REDEFINES variants exist in the source record, or what 88-level condition names define the semantic validity of each field. The code-level metadata, the layer where the business meaning of legacy data actually lives, requires code analysis, not catalog scanning.
They cannot reconstruct meaning that was never captured. Even with a perfect technical metadata extraction, the business meaning of fields that were never formally documented cannot be reconstructed automatically. This layer requires a combination of code analysis (to surface the business rules that programs apply to the data, which are proxies for business meaning) and human review (to validate reconstructed meaning against institutional knowledge while that knowledge still exists).
The Metadata Reconstruction Approach
For multi-decade systems where formal metadata was never captured or has drifted significantly from current reality, metadata management requires a reconstruction phase before a governance phase. The reconstruction approach extracts the recoverable layers and identifies the gaps where human knowledge is required.
Phase 1: Technical metadata extraction from source artifacts.
Parse every COBOL FD entry, COPY member, SELECT clause, and JCL DD statement to produce a field-level technical metadata inventory:
cobol
* Source FD entry -- technical metadata extraction target
FD TRANSACTION-FILE
LABEL RECORDS ARE STANDARD
RECORD CONTAINS 200 CHARACTERS.
01 TRANSACTION-RECORD.
05 TRANS-DATE PIC 9(8). *> YYYYMMDD format
05 TRANS-TYPE-CD PIC XX. *> See 88-level values
88 TRANS-PAYMENT VALUE 'PM'.
88 TRANS-REFUND VALUE 'RF'.
88 TRANS-ADJUSTMENT VALUE 'AJ'.
88 TRANS-REVERSAL VALUE 'RV'.
05 TRANS-AMT-CD PIC S9(9)V99 COMP-3.
05 TRANS-CURRENCY-CD PIC X(3). *> ISO 4217
05 TRANS-DETAIL REDEFINES TRANS-TYPE-CD.
10 TRANS-MERCH-ID PIC X(12).
10 TRANS-AUTH-CD PIC X(6).
10 FILLER PIC X(84).From this single FD entry, technical metadata extraction produces: field names, data types, lengths, positions, the packed decimal precision of TRANS-AMT-CD (9 digits, 2 decimal places, signed), the four semantic values of TRANS-TYPE-CD as defined by the 88-level condition names, and the REDEFINES structure that creates two overlapping interpretations of bytes 10-105 of the record.
The 88-level condition names are particularly valuable as metadata: TRANS-PAYMENT, TRANS-REFUND, TRANS-ADJUSTMENT, TRANS-REVERSAL are four items of business vocabulary that the COBOL code itself provides, more meaningful than the underlying PM, RF, AJ, RV values that a data catalog scanning the database would see.
Phase 2: Operational metadata extraction from program dependencies.
Build the operational lineage map by tracing data flows through the program dependency graph:
- Which programs write to
TRANSACTION-FILE(producers) - Which programs read from
TRANSACTION-FILE(spotřebitelé) - Which JCL job steps invoke each producer and consumer, in what sequence
- Which downstream datasets and databases receive data transformed from
TRANSACTION-FILE
This lineage map is the operational metadata that data catalog tools need for lineage visualization but cannot construct without access to the source program code and JCL.
Phase 3: Business rule extraction as semantic metadata proxy.
Business rules encoded in COBOL PROCEDURE DIVISION logic are proxies for business meaning. A program that validates TRANS-AMT-CD to ensure it falls within certain ranges before processing is providing evidence about the valid range of the field. A program that converts TRANS-AMT-CD to a different unit before writing to a downstream system is revealing an implied decimal or unit convention.
Extracting these business rules through code analysis produces a set of inferred semantic metadata: the validation ranges applied to each field, the transformations that occur between source and target, and the conditions under which different code paths execute. This inferred semantic metadata is imprecise, it shows what programs do with the data, not necessarily what the data was intended to mean, but it is recoverable from the code in a way that the original specification document is not.
Phase 4: Human validation and semantic enrichment.
The extracted technical and operational metadata and the inferred semantic metadata form the basis for human validation sessions with domain experts and retiring developers. The goal is to convert inferred semantics into confirmed semantics, validating that TRANS-AMT-CD means what the code suggests it means, identifying cases where the code behavior no longer reflects the intended business meaning, and capturing institutional knowledge about field history that code analysis cannot recover.
This phase is time-bounded by the availability of domain expertise: each year that passes, more of this knowledge retires with the people who hold it.
The Legacy Metadata Gap at the Modern System Boundary
The metadata deficit created by multi-decade systems does not remain contained within the legacy environment. It propagates downstream: every analytical system, data warehouse, and machine learning pipeline that consumes data from legacy systems inherits the metadata gap.
A cloud data warehouse that receives a nightly flat file extract from a COBOL batch program has, in its column definitions, whatever the data engineering team chose to name the columns when they built the ETL pipeline. If the original field was TRANS-AMT-CD and the ETL developer named the target column transaction_amount, the data warehouse appears to have complete metadata: column name, data type, business description added to the catalog. What the catalog does not record is that transaction_amount původem z TRANS-AMT-CD in TRANSACTION-FILE, which is produced by a COBOL program named TRNSRC01, which runs in JCL job TRANSDAY every night at 2 AM, and which applies a specific currency conversion that was hardcoded in 1987 based on an exchange rate convention that may or may not still be current.
The downstream metadata record looks complete. The lineage is broken at the legacy boundary. Any analytical or AI workload that depends on understanding the provenance and meaning of transaction_amount has a gap where the actual origin story of that value is not documented.
Gartner’s finding that 60 percent of AI projects unsupported by AI-ready data will be abandoned through 2026 is partly a metadata statement. AI models that consume transaction_amount without knowing it originated from a packed decimal COBOL field with an implied decimal place, denominated in a currency that may have been converted using a 1987 exchange rate convention, are training on data whose provenance is opaque. The model cannot know to distrust or adjust for this context because the metadata that would communicate it does not exist in any catalog the model or its data pipeline can access.
Building a Metadata Management Program for Legacy Systems
A metadata management program for multi-decade data systems has four components that differ from standard enterprise data catalog implementations:
Component 1: Source-code metadata extraction. Before any catalog tool can govern legacy metadata, the metadata must be extracted from the source artifacts where it lives. This extraction must cover: FD entries and copybooks (technical metadata for data structures), SELECT clauses (file organization and access method), JCL DD statements (dataset associations and file characteristics), and 88-level condition names (semantic value vocabulary embedded in source code). The output is a field-level metadata inventory that can be loaded into a catalog as the starting point for business enrichment.
Component 2: Lineage reconstruction. Data lineage for legacy systems must be reconstructed from program dependency analysis rather than from ETL tool lineage tracking. The lineage map traces data from its originating COBOL program through intermediate transformation programs to its eventual consumers, including the ETL processes that deliver it to modern analytical systems. This reconstruction closes the lineage gap at the legacy boundary, connecting the cloud data warehouse column metadata to the COBOL FD entry metadata through a documented chain of program dependencies.
Component 3: Semantic enrichment with domain expertise. Extracted technical metadata provides the structure; confirmed business meaning requires domain expertise. The enrichment process uses the technical metadata as a structured prompt for expert interviews: “This field is defined as PIC S9(9)V99 COMP-3, it is validated to be non-negative in 14 programs, and it is converted to a different scale before writing to the downstream database, can you confirm what it represents and what the conversion means?” This structured approach uses code analysis to maximize the information value of each expert interaction, enabling faster and more complete enrichment than unstructured documentation reviews.
Component 4: Governance integration with modern catalog platforms. Once legacy metadata is extracted, reconstructed, and enriched, it must be integrated with the modern metadata governance infrastructure. This integration connects the legacy metadata inventory to the enterprise data catalog, providing: column-level lineage from COBOL source to cloud target, business glossary terms linked to legacy field definitions, and data quality metadata for legacy datasets that populates the same governance framework as modern system metadata.
Jak SMART TS XL Extracts Legacy Metadata
SMART TS XL addresses the first two components of the legacy metadata management program, source-code metadata extraction and lineage reconstruction, by applying static analysis to the full COBOL, JCL, and copybook portfolio.
Jedno statická analýza kódu capability parses every FD entry, COPY member, SELECT clause, and 88-level definition across the COBOL portfolio, producing the field-level technical metadata inventory: every field name, data type, length, COMP specification, REDEFINES membership, and 88-level condition name across every program and copybook in the environment. For a portfolio of thousands of COBOL programs, this extraction produces in hours the technical metadata inventory that manual documentation would require years to produce, if it could be produced completely at all.
Jedno mapování závislostí aplikací builds the operational lineage map: every program-to-dataset relationship (which programs produce which datasets and which consume them), every program-to-program dependency (which programs call which others and what data flows between them), and every JCL-to-program relationship (which job steps invoke which programs in which sequence). This lineage map is the operational metadata layer that closes the gap between legacy source systems and the modern data catalog’s lineage records.
Jedno Expanze JCL capability traces the complete execution chain of every JCL job: resolving PROC references, expanding symbolic parameters, and building the full operational metadata for each dataset’s production and consumption, the scheduling context, the dependent jobs, and the execution sequence that determines the timeliness and freshness characteristics of each dataset.
Jedno podnikové vyhledávání capability makes the extracted metadata inventory queryable throughout the metadata management program: find every field defined as COMP-3 (precision-sensitive fields requiring careful target mapping), every program that reads a specific field (identifying all consumers of a specific piece of data for lineage and semantic enrichment), every 88-level condition name that matches a specific business term (mapping business vocabulary to technical field definitions). This search capability supports the semantic enrichment process, enabling domain experts to find all uses of a specific field or value before confirming its business meaning.
Pro organizace provádějící starší modernizace programy, SMART TS XL’s metadata extraction provides the pre-migration foundation: the field-level technical metadata that migration tools need to map source fields to target schemas, the operational lineage that migration programs need to sequence dataset migrations correctly, and the 88-level semantic vocabulary that enables accurate mapping from COBOL code values to relational constraint definitions.
The Urgency of Metadata Recovery Before Knowledge Retires
The metadata reconstruction problem has a natural deadline that does not apply to most data governance challenges: the retirement of the developers who hold the institutional knowledge that code analysis cannot recover. Nearly one-third of COBOL programmers will retire by 2030. The average mainframe engineer age is 58.7. Every year that passes without systematic metadata extraction and semantic enrichment narrows the window in which human validation of recovered metadata is possible.
The technical metadata, field definitions, type specifications, program dependencies, data lineage, is recoverable from source code indefinitely, as long as the source code exists. The semantic metadata, what each field means in business terms, what the historical decisions behind field design were, what the implied conventions are that the technical specifications do not document, is recoverable only from the people who know it, and only while they remain available.
A metadata management program for multi-decade systems that begins with technical extraction and proceeds to semantic enrichment while domain expertise is still available produces a complete, recoverable metadata foundation. The same program deferred until after the knowledge retires produces a technical metadata foundation that is accurate but incomplete, correct about the structure of the data, silent about its meaning.
Metadata Is the Map. Multi-Decade Systems Buried It.
Data governance for modern systems begins with metadata that is current, accessible, and at least partially documented. Data governance for multi-decade systems begins with metadata that is distributed across thousands of source code files, partially documented in specifications that predate the internet, and partially held in the memory of developers who are approaching retirement.
The path from buried to governed runs through extraction, reconstruction, and enrichment, in that order. Technical metadata extracted from source code provides the starting inventory. Operational lineage reconstructed from program dependencies provides the provenance map. Semantic enrichment validated by domain expertise provides the business meaning that makes the technical metadata actionable for analytics, AI, and governance.
Modern data catalog platforms are the destination for this metadata, not the starting point. Before Collibra can govern it and Alation can catalog it and data scientists can trust it, the metadata that multi-decade systems contain must first be found, in the FD entries, in the copybooks, in the 88-level condition names, and in the business rules encoded in forty years of PROCEDURE DIVISION logic.
The map exists. It just needs to be read.
