Das Feld TRANS-AMT-CD in einem COBOL-Programm, das seit 1981 in Produktion ist. Der FD-Eintrag definiert es als PIC S9(9)V99 COMP-3Es handelt sich um ein gepacktes Dezimalfeld mit elf Ziffern und zwei impliziten Nachkommastellen. Das sind die technischen Metadaten. Die geschäftlichen Metadaten – was TRANS-AMT-CD tatsächlich bedeutet, in welcher Währung es angegeben ist, ob die zwei impliziten Nachkommastellen Cent oder Basispunkte darstellen, ob ein negativer Wert eine Gutschrift oder eine Belastung bedeutet und wie der Wert Null zu interpretieren ist – sind im Quellcode nicht vorhanden. Sie existierten in einem 1981 gedruckten und archivierten Funktionsspezifikationsdokument, das seitdem verschollen ist. Die beiden Entwickler, die ursprünglich die Bedeutung von TRANS-AMT-CD kannten, gingen beide 2014 in den Ruhestand.
Dies ist die Metadaten-Situation, mit der jede Organisation mit jahrzehntealten Datensystemen konfrontiert ist, und genau diese Situation wurde von modernen Data-Governance-Frameworks nicht adressiert. Collibra, Alation, Atlan und alle anderen Enterprise-Datenkatalogplattformen eignen sich hervorragend für die Verwaltung von Metadaten bereits beschriebener Daten, Cloud-Datenbanken mit dokumentierten Schemata, Data Warehouses mit definierter Spaltensemantik und API-Endpunkte mit OpenAPI-Spezifikationen. Sie sind jedoch nicht darauf ausgelegt, Metadaten zu rekonstruieren, die nie formal erfasst wurden, die lediglich im Verhalten von Programmen existieren, die vor der Etablierung des Metadatenmanagements als eigenständige Disziplin geschrieben wurden, und die über vier Jahrzehnte von Dutzenden von Entwicklern modifiziert wurden, ohne dass jemals eine zentrale Dokumentation der Bedeutung der einzelnen Felder aktualisiert wurde.
Die Metadatenverwaltung für jahrzehntealte Datensysteme unterscheidet sich grundlegend von der Metadatenverwaltung für moderne Systeme. Sie erfordert einen grundlegend anderen Ansatz, der mit der Extraktion von Metadaten aus Quellartefakten beginnt, anstatt Metadaten aus verbundenen Systemen zu übernehmen.
Finde Sinn, bevor es in Rente geht
SMART TS XL Extrahiert technische Metadaten auf Feldebene aus FD-Einträgen und Copybooks, bevor Katalogwerkzeuge diese verwalten können.
MEHR ERFAHREN…Die drei Ebenen von Legacy-Metadaten
Um das Metadatenproblem in Systemen, die über mehrere Jahrzehnte bestehen, zu verstehen, muss man erkennen, dass Metadaten in diesen Umgebungen in drei verschiedenen Schichten existieren, die jeweils unterschiedliche Extrahierbarkeit, unterschiedliche Vollständigkeit und unterschiedliche Auswirkungen auf die Governance aufweisen.
Technische Metadaten sind die am einfachsten extrahierbare Ebene. Sie beschreiben die physische Struktur der Daten: Feldnamen, Datentypen, Längen, Positionen innerhalb von Datensätzen, Spezifikationen zur numerischen Genauigkeit und die Beziehungen zwischen Feldern innerhalb eines Datensatzlayouts. In COBOL-Umgebungen befinden sich technische Metadaten in Quellcode-Artefakten: FD-Einträge definieren Datensatzlayouts, COPY-Member definieren wiederverwendbare Datenstrukturen, SELECT-Klauseln definieren die Dateiorganisation und Zugriffsmethoden, und JCL-DD-Anweisungen definieren die Datensätze, die mit jeder Programmausführung verknüpft sind. Diese Ebene ist prinzipiell maschinenlesbar; ein Parser, der die COBOL-Syntax versteht, kann sie aus dem Quellcode extrahieren. Sie ist jedoch über Tausende von Quelldateien verteilt und nicht zentral in einer Schema-Registry gespeichert.
Operative Metadaten beschreiben den Datenfluss im System: welche Programme welche Datensätze erzeugen, welche Programme sie in welcher Reihenfolge und durch welche Transformationen verarbeiten. In Mainframe-Umgebungen sind operative Metadaten auf JCL-Jobstreams (die Ausführungssequenzen und Datensatzzuordnungen definieren), Programmaufrufgraphen (die den Datenfluss zwischen Programmen definieren) und die Scheduler-Konfiguration (die Timing und Abhängigkeiten definiert) verteilt. Diese Ebene lässt sich auch maschinell aus den Quellartefakten extrahieren, wobei die Extraktion jedoch nicht nur das Verständnis einzelner Programme, sondern auch ihrer Beziehungen erfordert.
Geschäfts- oder semantische Metadaten ist die am wenigsten extrahierbare und gleichzeitig wertvollste Ebene. Sie beantwortet Fragen, die technische Metadaten nicht beantworten können: Was bedeutet das? TRANS-AMT-CD Was bedeutet das konkret in geschäftlichen Begriffen? Welche Werte sind gültig für ACCT-TYPE-CD Und was bedeutet jeder Wert? Welche Geschäftsregel legt fest, wann? CUST-STATUS-FLG Übergänge von A zu IDiese Ebene existiert, sofern sie überhaupt existiert, in Spezifikationsdokumenten, im Gedächtnis der Entwickler, im institutionellen Wissen von Mitarbeitern, die möglicherweise bereits im Ruhestand sind, und in der prozeduralen Logik von Programmen, die Geschäftsregeln durch IF-Anweisungen und EVALUATE-Blöcke anstatt durch Datenbankbeschränkungen durchsetzen.
Die Herausforderung bei Metadaten für Systeme, die über Jahrzehnte hinweg bestehen, liegt darin, dass diese drei Ebenen im Laufe der Systementwicklung unterschiedlich oder gar nicht verwaltet wurden. Technische Metadaten wurden zwar im Quellcode erfasst, aber nie in einem Datenwörterbuch formalisiert. Operative Metadaten waren implizit in JCL-Jobstreams enthalten, wurden aber nie als Herkunftsnachweis dokumentiert. Geschäftsbezogene Metadaten wurden zum Zeitpunkt der ursprünglichen Entwicklung in Spezifikationen dokumentiert und im Zuge der Systementwicklung nie aktualisiert.
Das Problem der Metadaten-Drift
Jedes Jahr, wenn ein über Jahrzehnte betriebenes System ohne systematisches Metadatenmanagement arbeitet, vergrößert sich die Kluft zwischen den in der formalen Dokumentation vorhandenen Metadaten und den Metadaten, die das aktuelle Verhalten des Systems widerspiegeln. Diese Abweichung erfolgt durch vier Mechanismen:
Feld bedeutet Evolution. Ein Fachgebiet, das 1978 mit einer einzigen wirtschaftlichen Bedeutung definiert wurde, kann im Laufe der folgenden Jahrzehnte zusätzliche Bedeutungen angesammelt haben. ACCT-TYPE-CD Ursprünglich diente der Code möglicherweise der Unterscheidung von Giro- und Sparkonten. Im Laufe von über vierzig Jahren wurden weitere Codes für Geldmarktkonten, Festgeldanlagen, IRA-Konten und Treuhandkonten hinzugefügt. Jede dieser Ergänzungen wurde lediglich im Programmcode dokumentiert, der den neuen Codewert verarbeitet, nicht in einer zentralen Felddefinition. Feldname und -typ sind unverändert; seine semantische Bedeutung ist jedoch deutlich komplexer geworden.
Stille Wiederverwendung. Felder werden gelegentlich ohne Umbenennung wiederverwendet. Ein Feld, das ursprünglich für einen bestimmten Zweck verwendet wurde, lässt sich nur schwer erweitern, und ein Entwickler nutzt einen zuvor ungenutzten Wert eines benachbarten Flag-Felds, um eine andere Information zu kodieren. TRANS-FLAG-1 Das Feld kann nun in verschiedenen Programmkontexten drei unterschiedliche Konzepte kodieren, die sich nur dadurch unterscheiden lassen, welche Programme das Feld unter welchen Bedingungen lesen. Die technischen Metadaten – Feldname, Typ, Länge – geben keinen Hinweis darauf, dass das Feld semantisch überladen ist.
REDEFINES-Akkumulation. Wie in VSAM-Analysekontexten erläutert, überlagern REDEFINES-Klauseln denselben physischen Speicher mit unterschiedlichen Feldinterpretationen. Jede REDEFINES-Variante kann zu einem anderen Zeitpunkt in der Systemgeschichte, von verschiedenen Entwicklern und für unterschiedliche Geschäftszwecke hinzugefügt worden sein. Die vollständige semantische Bedeutung einer REDEFINES-Hierarchie – welche Variante wann angewendet wird und was die Felder jeder Variante bedeuten – lässt sich nur durch die Analyse aller Programme rekonstruieren, die auf die jeweilige Variante zugreifen, sowie der Bedingungen, unter denen dies geschieht.
Abweichungen im Copybook. Wird ein Standard-COBOL-Copybook an eine neue Anforderung angepasst, können Programme, die das Copybook einbinden, aber nicht für die Verarbeitung des neuen Felds aktualisiert wurden, fehlerhaft funktionieren oder das neue Feld einfach ignorieren. Im Laufe der Jahrzehnte können in verschiedenen Bibliotheken mehrere Versionen desselben Copybooks existieren, die von unterschiedlichen Programmen verwendet werden. Die Metadaten eines im Copybook definierten Felds können sich je nach eingebundener Copybook-Version unterscheiden.
Was moderne Metadaten-Tools für Legacy-Daten nicht leisten können
Der Markt für Enterprise-Datenkataloge hat sich deutlich weiterentwickelt. Collibra, Alation, Atlan, Microsoft Purview und Informatica Axon sind hochentwickelte Plattformen zur Metadatenverwaltung in modernen Datenumgebungen. Sie zeichnen sich durch folgende Merkmale aus: automatische Erkennung von Schemas aus verbundenen Datenbanken, Nachverfolgung der Datenherkunft auf Spaltenebene in ETL-Pipelines, Pflege von Fachglossaren mit kuratierten Begriffsdefinitionen und Anzeige von Datenqualitätsmetriken zusammen mit Metadatensätzen.
Was diese Tools für jahrzehntealte COBOL- und Mainframe-Systeme nicht leisten können:
Sie können keine Verbindung zu dem herstellen, was sie nicht sehen. Moderne Kataloge ermitteln Metadaten über Konnektoren, JDBC-Verbindungen zu Datenbanken, API-Integrationen mit Cloud-Diensten und Scanner-Integrationen mit unterstützten Plattformen. VSAM-Dateien, COBOL-Programme und JCL-Jobstreams verfügen über keine Standard-Katalogkonnektoren. Der Katalog kann nicht ermitteln, was ihm nicht zugänglich ist. Die von diesen Systemen verwalteten Daten sind für den Katalog praktisch unsichtbar, was bedeutet, dass die Herkunftsdatensätze für nachgelagerte Cloud-Analysen, die auf diesen Daten basieren, unvollständig oder nicht vorhanden sind.
Metadaten, die ausschließlich im Code existieren, können nicht extrahiert werden. Ein Datenkatalog, der mit einer DB2-Datenbank verbunden ist, kann das Datenbankschema, Tabellendefinitionen, Spaltennamen, Datentypen und Indizes lesen. Er kann jedoch nicht das COBOL-Programm lesen, das die DB2-Tabelle befüllt, um zu verstehen, welche Geschäftsregeln die Befüllung steuern, welche REDEFINES-Varianten im Quelldatensatz vorhanden sind oder welche 88-stufigen Bedingungsnamen die semantische Gültigkeit jedes Feldes definieren. Die Metadaten auf Codeebene, die Ebene, auf der die geschäftliche Bedeutung von Altdaten tatsächlich enthalten ist, erfordern eine Codeanalyse, keine Katalogprüfung.
Sie können keine Bedeutung rekonstruieren, die nie erfasst wurde. Selbst bei einer perfekten technischen Metadatenextraktion lässt sich die geschäftliche Bedeutung von Feldern, die nie formal dokumentiert wurden, nicht automatisch rekonstruieren. Diese Ebene erfordert eine Kombination aus Codeanalyse (um die Geschäftsregeln aufzudecken, die Programme auf die Daten anwenden und die als Stellvertreter für die geschäftliche Bedeutung dienen) und menschlicher Überprüfung (um die rekonstruierte Bedeutung anhand des institutionellen Wissens zu validieren, solange dieses Wissen noch vorhanden ist).
Der Ansatz zur Metadatenrekonstruktion
Bei Systemen, die über Jahrzehnte hinweg bestanden und in denen formale Metadaten nie erfasst wurden oder die sich erheblich von der aktuellen Realität entfernt haben, erfordert das Metadatenmanagement vor der Governance-Phase eine Rekonstruktionsphase. Der Rekonstruktionsansatz extrahiert die wiederherstellbaren Ebenen und identifiziert die Lücken, in denen menschliches Wissen erforderlich ist.
Phase 1: Extraktion technischer Metadaten aus Quellartefakten.
Analysiere jeden COBOL-FD-Eintrag, jedes COPY-Element, jede SELECT-Klausel und jede JCL-DD-Anweisung, um ein technisches Metadateninventar auf Feldebene zu erstellen:
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).Aus diesem einzelnen FD-Eintrag werden durch die Extraktion technischer Metadaten folgende Informationen gewonnen: Feldnamen, Datentypen, Längen, Positionen, die gepackte Dezimalgenauigkeit von TRANS-AMT-CD (9 Ziffern, 2 Dezimalstellen, mit Vorzeichen), die vier semantischen Werte von TRANS-TYPE-CD wie durch die Bedingungsnamen der Ebene 88 definiert und durch die REDEFINES-Struktur, die zwei sich überschneidende Interpretationen der Bytes 10-105 des Datensatzes erzeugt.
Die Zustandsbezeichnungen der 88er-Ebene sind als Metadaten besonders wertvoll: TRANS-PAYMENT, TRANS-REFUND, TRANS-ADJUSTMENT, TRANS-REVERSAL Es handelt sich um vier Begriffe des Geschäftsvokabulars, die der COBOL-Code selbst bereitstellt und die aussagekräftiger sind als der zugrunde liegende PM, RF, AJ, RV Werte, die ein Datenkatalog beim Scannen der Datenbank sehen würde.
Phase 2: Extraktion von operationellen Metadaten aus Programmabhängigkeiten.
Erstellen Sie die operative Herkunftskarte, indem Sie die Datenflüsse durch den Programmabhängigkeitsgraphen verfolgen:
- Welche Programme schreiben an
TRANSACTION-FILE(Produzenten) - Welche Programme lesen von
TRANSACTION-FILE(Verbraucher) - Welche JCL-Jobschritte rufen welchen Produzenten und Konsumenten in welcher Reihenfolge auf?
- Welche nachgelagerten Datensätze und Datenbanken erhalten die transformierten Daten?
TRANSACTION-FILE
Diese Herkunftskarte stellt die operationellen Metadaten dar, die Datenkatalogwerkzeuge für die Visualisierung der Herkunft benötigen, aber ohne Zugriff auf den Quellprogrammcode und JCL nicht erstellen können.
Phase 3: Extraktion von Geschäftsregeln als semantischer Metadaten-Proxy.
In der COBOL-PROCEDURE-DIVISION-Logik kodierte Geschäftsregeln sind Stellvertreter für die geschäftliche Bedeutung. Ein Programm, das validiert TRANS-AMT-CD Um sicherzustellen, dass der Wert vor der Verarbeitung innerhalb bestimmter Bereiche liegt, liefert ein Programm Hinweise auf den gültigen Wertebereich des Feldes. TRANS-AMT-CD Die Verwendung einer anderen Einheit vor dem Schreiben in ein nachgelagertes System offenbart eine implizite Dezimal- oder Einheitenkonvention.
Die Extraktion dieser Geschäftsregeln durch Codeanalyse erzeugt einen Satz abgeleiteter semantischer Metadaten: die Validierungsbereiche der einzelnen Felder, die Transformationen zwischen Quell- und Zielcode sowie die Ausführungsbedingungen verschiedener Codepfade. Diese abgeleiteten semantischen Metadaten sind ungenau; sie zeigen, wie Programme mit den Daten umgehen, nicht unbedingt deren ursprüngliche Bedeutung. Sie lassen sich jedoch aus dem Code extrahieren, was mit dem ursprünglichen Spezifikationsdokument nicht möglich ist.
Phase 4: Menschliche Validierung und semantische Anreicherung.
Die extrahierten technischen und betrieblichen Metadaten sowie die abgeleiteten semantischen Metadaten bilden die Grundlage für Validierungssitzungen mit Fachexperten und ausscheidenden Entwicklern. Ziel ist es, die abgeleitete Semantik in bestätigte Semantik umzuwandeln und zu validieren, dass TRANS-AMT-CD bedeutet, was der Code nahelegt, Fälle zu identifizieren, in denen das Verhalten des Codes nicht mehr der beabsichtigten geschäftlichen Bedeutung entspricht, und institutionelles Wissen über die Geschichte des Fachgebiets zu erfassen, das durch eine Codeanalyse nicht wiederhergestellt werden kann.
Diese Phase ist zeitlich durch die Verfügbarkeit von Fachwissen begrenzt: Mit jedem Jahr, das vergeht, geht ein Teil dieses Wissens mit den Menschen, die es besitzen, in den Ruhestand.
Die Lücke der Legacy-Metadaten an der Grenze moderner Systeme
Das durch jahrzehntelange Systeme entstandene Metadatendefizit beschränkt sich nicht auf die Altsysteme. Es wirkt sich nachgelagert aus: Jedes Analysesystem, jedes Data Warehouse und jede Machine-Learning-Pipeline, die Daten aus Altsystemen verwendet, erbt die Metadatenlücke.
Ein Cloud-Data-Warehouse, das nächtlich einen Flatfile-Extrakt aus einem COBOL-Batchprogramm empfängt, verwendet in seinen Spaltendefinitionen die vom Data-Engineering-Team beim Erstellen der ETL-Pipeline festgelegten Spaltennamen. Wenn das ursprüngliche Feld TRANS-AMT-CD und der ETL-Entwickler benannte die Zielspalte transaction_amountDas Data Warehouse scheint über vollständige Metadaten zu verfügen: Spaltenname, Datentyp und Geschäftsbeschreibung wurden dem Katalog hinzugefügt. Was der Katalog jedoch nicht erfasst, ist Folgendes: transaction_amount stammt aus TRANS-AMT-CD in TRANSACTION-FILE, das von einem COBOL-Programm namens TRNSRC01, das im JCL-Job ausgeführt wird TRANSDAY jede Nacht um 2 Uhr morgens, und dabei wird eine bestimmte Währungsumrechnung angewendet, die 1987 auf der Grundlage einer Wechselkurskonvention fest einprogrammiert wurde, die möglicherweise nicht mehr aktuell ist.
Der nachgelagerte Metadatensatz scheint vollständig zu sein. Die Datenherkunft ist an der Grenze zum Altsystem unterbrochen. Jegliche analytische oder KI-gestützte Anwendung, die auf dem Verständnis der Herkunft und Bedeutung dieser Daten basiert, ist dadurch beeinträchtigt. transaction_amount weist eine Lücke auf, da die eigentliche Entstehungsgeschichte dieses Wertes nicht dokumentiert ist.
Gartners Feststellung, dass 60 Prozent der KI-Projekte ohne KI-fähige Daten bis 2026 aufgegeben werden, ist teilweise eine Aussage über Metadaten. KI-Modelle, die Daten verbrauchen transaction_amount Das Modell trainiert Daten, deren Herkunft unklar ist, ohne zu wissen, dass sie aus einem gepackten COBOL-Dezimalfeld mit impliziter Dezimalstelle stammen und in einer Währung denominiert sind, die möglicherweise nach dem Wechselkurskonvention von 1987 umgerechnet wurde. Das Modell kann diesen Kontext weder erkennen noch berücksichtigen, da die entsprechenden Metadaten in keinem Katalog vorhanden sind, auf den das Modell oder seine Datenpipeline zugreifen kann.
Aufbau eines Metadatenverwaltungsprogramms für Legacy-Systeme
Ein Metadatenverwaltungsprogramm für jahrzehntelange Datensysteme besteht aus vier Komponenten, die sich von Standardimplementierungen für Unternehmensdatenkataloge unterscheiden:
Komponente 1: Extraktion von Quellcode-Metadaten. Bevor ein Katalogisierungstool Legacy-Metadaten verwalten kann, müssen diese aus den Quellartefakten extrahiert werden. Die Extraktion umfasst: FD-Einträge und Copybooks (technische Metadaten für Datenstrukturen), SELECT-Klauseln (Dateiorganisation und Zugriffsmethoden), JCL-DD-Anweisungen (Datensatzzuordnungen und Dateieigenschaften) sowie Bedingungsnamen der Ebene 88 (semantisches Wertevokabular im Quellcode). Das Ergebnis ist ein Metadateninventar auf Feldebene, das als Ausgangspunkt für die Geschäftsdatenanreicherung in einen Katalog geladen werden kann.
Komponente 2: Rekonstruktion der Datenherkunft. Die Datenherkunft von Altsystemen muss anhand der Programmabhängigkeitsanalyse und nicht anhand der Herkunftsverfolgung von ETL-Tools rekonstruiert werden. Die Herkunftskarte verfolgt die Daten vom ursprünglichen COBOL-Programm über zwischengeschaltete Transformationsprogramme bis hin zu den Endnutzern, einschließlich der ETL-Prozesse, die die Daten an moderne Analysesysteme übermitteln. Diese Rekonstruktion schließt die Lücke in der Datenherkunft an der Schnittstelle zum Altsystem und verbindet die Metadaten der Spalten im Cloud-Data-Warehouse mit den Metadaten der COBOL-FD-Einträge über eine dokumentierte Kette von Programmabhängigkeiten.
Komponente 3: Semantische Anreicherung mit Domänenexpertise. Die extrahierten technischen Metadaten liefern die Struktur; die bestätigte geschäftliche Bedeutung erfordert Fachkenntnisse. Der Anreicherungsprozess nutzt die technischen Metadaten als strukturierte Grundlage für Experteninterviews: „Dieses Feld ist definiert als PIC S9(9)V99 COMP-3Es wurde in 14 Programmen als nicht-negativ validiert und wird vor dem Schreiben in die nachgelagerte Datenbank in eine andere Skala umgerechnet. Können Sie bestätigen, was es darstellt und was die Umrechnung bedeutet?“ Dieser strukturierte Ansatz nutzt die Codeanalyse, um den Informationswert jeder Experteninteraktion zu maximieren und ermöglicht so eine schnellere und umfassendere Anreicherung als unstrukturierte Dokumentationsprüfungen.
Komponente 4: Governance-Integration mit modernen Katalogplattformen. Nach der Extraktion, Rekonstruktion und Anreicherung der Legacy-Metadaten müssen diese in die moderne Metadaten-Governance-Infrastruktur integriert werden. Diese Integration verbindet das Legacy-Metadateninventar mit dem unternehmensweiten Datenkatalog und stellt Folgendes bereit: Datenherkunft auf Spaltenebene von der COBOL-Quelle zum Cloud-Ziel, Verknüpfung von Fachbegriffen mit Legacy-Felddefinitionen sowie Datenqualitätsmetadaten für Legacy-Datensätze, die in dasselbe Governance-Framework wie die Metadaten des modernen Systems einfließen.
Wie SMART TS XL Extrahiert Legacy-Metadaten
SMART TS XL behandelt die ersten beiden Komponenten des Legacy-Metadatenmanagementprogramms, die Extraktion von Quellcode-Metadaten und die Rekonstruktion der Quellcode-Herkunft, indem eine statische Analyse auf das gesamte COBOL-, JCL- und Copybook-Portfolio angewendet wird.
Die statische Codeanalyse durchsucht alle FD-Einträge, COPY-Elemente, SELECT-Klauseln und Definitionen der Ebene 88 im gesamten COBOL-Portfolio und erstellt ein umfassendes technisches Metadateninventar auf Feldebene: alle Feldnamen, Datentypen, Längen, COMP-Spezifikationen, REDEFINES-Mitgliedschaften und Bedingungsnamen der Ebene 88 für jedes Programm und Copybook in der Umgebung. Bei Tausenden von COBOL-Programmen liefert diese Extraktion innerhalb weniger Stunden das technische Metadateninventar, für dessen Erstellung eine manuelle Dokumentation Jahre dauern würde – sofern sie überhaupt vollständig erstellt werden könnte.
Die Abbildung der Anwendungsabhängigkeiten erstellt die operative Datenherkunftskarte: Sie erfasst jede Programm-zu-Datensatz-Beziehung (welche Programme welche Datensätze erzeugen und welche sie verwenden), jede Programm-zu-Programm-Abhängigkeit (welche Programme welche anderen aufrufen und welche Daten zwischen ihnen fließen) und jede JCL-zu-Programm-Beziehung (welche Jobschritte welche Programme in welcher Reihenfolge aufrufen). Diese Datenherkunftskarte bildet die operative Metadatenebene, die die Lücke zwischen bestehenden Quellsystemen und den Herkunftsdatensätzen des modernen Datenkatalogs schließt.
Die JCL-Erweiterungsfunktion verfolgt die gesamte Ausführungskette jedes JCL-Jobs: Auflösung von PROC-Referenzen, Erweiterung symbolischer Parameter und Erstellung der vollständigen operativen Metadaten für die Produktion und den Verbrauch jedes Datensatzes, den Planungskontext, die abhängigen Jobs und die Ausführungsreihenfolge, die die Aktualität und Aktualität jedes Datensatzes bestimmt.
Die unternehmensweite Suchfunktion ermöglicht die Abfrage des extrahierten Metadateninventars im gesamten Metadatenmanagementsystem: Sie findet jedes als COMP-3 definierte Feld (präzisionssensible Felder, die eine sorgfältige Zielzuordnung erfordern), jedes Programm, das ein bestimmtes Feld liest (Identifizierung aller Nutzer eines bestimmten Datenelements für Herkunfts- und semantische Anreicherung), und jeden Bedingungsnamen der Ebene 88, der einem bestimmten Geschäftsbegriff entspricht (Zuordnung von Geschäftsvokabular zu technischen Felddefinitionen). Diese Suchfunktion unterstützt die semantische Anreicherung und ermöglicht es Fachexperten, alle Verwendungen eines bestimmten Feldes oder Werts zu finden, bevor sie dessen geschäftliche Bedeutung bestätigen.
Für Organisationen, die Modernisierung des Altbestands Programme, SMART TS XLDie Metadatenextraktion von bildet die Grundlage für die Migration: die technischen Metadaten auf Feldebene, die Migrationswerkzeuge benötigen, um Quellfelder Zielschemata zuzuordnen, die operative Herkunft, die Migrationsprogramme benötigen, um Datensatzmigrationen korrekt zu sequenzieren, und das semantische Vokabular der 88-stufigen Ebene, das eine genaue Zuordnung von COBOL-Codewerten zu relationalen Einschränkungsdefinitionen ermöglicht.
Die Dringlichkeit der Metadatenwiederherstellung, bevor Wissen verloren geht
Das Problem der Metadatenrekonstruktion hat eine natürliche Frist, die für die meisten Herausforderungen im Bereich Data Governance nicht gilt: die Pensionierung der Entwickler, die über das institutionelle Wissen verfügen, das durch Codeanalyse nicht wiederhergestellt werden kann. Fast ein Drittel der COBOL-Programmierer wird bis 2030 in den Ruhestand gehen. Das Durchschnittsalter von Mainframe-Ingenieuren liegt bei 58.7 Jahren. Jedes Jahr, das ohne systematische Metadatenextraktion und semantische Anreicherung vergeht, verringert das Zeitfenster, in dem eine menschliche Validierung der wiederhergestellten Metadaten möglich ist.
Die technischen Metadaten – Felddefinitionen, Typspezifikationen, Programmabhängigkeiten und Datenherkunft – lassen sich aus dem Quellcode unbegrenzt wiederherstellen, solange dieser existiert. Die semantischen Metadaten hingegen – die Bedeutung der einzelnen Felder im Geschäftskontext, die historischen Entscheidungen hinter der Feldgestaltung und die impliziten Konventionen, die in den technischen Spezifikationen nicht dokumentiert sind – können nur von denjenigen abgerufen werden, die darüber Bescheid wissen, und zwar nur solange, wie diese Personen verfügbar sind.
Ein Metadatenmanagementprogramm für Systeme, die über Jahrzehnte hinweg genutzt werden und mit der technischen Extraktion beginnen und anschließend die semantische Anreicherung fortsetzen, solange noch Fachwissen vorhanden ist, schafft eine vollständige und wiederherstellbare Metadatengrundlage. Wird dasselbe Programm erst nach dem Verlust des Fachwissens eingesetzt, erzeugt es zwar eine technische Metadatengrundlage, die zwar korrekt, aber unvollständig ist – sie beschreibt zwar die Struktur der Daten, lässt aber deren Bedeutung offen.
Metadaten sind die Karte. Jahrzehntelange Systeme haben sie vergraben.
Die Datenverwaltung moderner Systeme beginnt mit Metadaten, die aktuell, zugänglich und zumindest teilweise dokumentiert sind. Die Datenverwaltung jahrzehntelanger Systeme beginnt hingegen mit Metadaten, die über Tausende von Quellcodedateien verteilt sind, teilweise in Spezifikationen aus der Zeit vor dem Internet dokumentiert sind und teilweise im Gedächtnis von Entwicklern schlummern, die kurz vor dem Ruhestand stehen.
Der Weg von verborgenen zu nutzbaren Daten führt über Extraktion, Rekonstruktion und Anreicherung – in dieser Reihenfolge. Technische Metadaten aus dem Quellcode bilden die Ausgangsbasis. Die aus Programmabhängigkeiten rekonstruierte Betriebshistorie liefert die Herkunftskarte. Die durch Fachexpertise validierte semantische Anreicherung verleiht den technischen Metadaten ihre geschäftliche Bedeutung und macht sie so für Analysen, KI und Governance nutzbar.
Moderne Datenkatalogplattformen sind das Ziel dieser Metadaten, nicht ihr Ausgangspunkt. Bevor Collibra sie verwalten, Alation sie katalogisieren und Datenwissenschaftler ihnen vertrauen können, müssen die Metadaten, die Systeme aus mehreren Jahrzehnten enthalten, erst gefunden werden – in den FD-Einträgen, in den Copybooks, in den 88-stufigen Bedingungsnamen und in den Geschäftsregeln, die in vierzig Jahren PROCEDURE DIVISION-Logik kodiert sind.
Die Karte existiert. Man muss sie nur lesen.
