VSAM-Dateistrukturanalyse für Datenmodernisierungsprojekte

Datenmigration kann nicht isoliert erfolgen, sondern muss parallel zu den COBOL-Anwendungen, die diese Datensätze lesen und schreiben, entwickelt werden. Diese Einschränkung definiert die gesamte Herausforderung der VSAM-Modernisierung. VSAM (Virtual Storage Access Method) ist nicht einfach nur ein Dateiformat. Es ist der Datenvertrag zwischen Programmen, die implizite Spezifikation, die nirgendwo außer in FD-Einträgen und SELECT-Klauseln definiert ist und regelt, wie jedes Programm in einem Unternehmenssystem seine wichtigsten Geschäftsdaten erzeugt und verarbeitet. Eine einzelne Änderung des Datensatzlayouts, die nicht in jedem Programm, das diesen Datensatz liest, berücksichtigt wird, führt zu Datenbeschädigung, die möglicherweise erst bei der Erstellung eines behördlichen Berichts auffällt – Daten, die nicht mehr die Bedeutung haben, die das verarbeitende Programm erwartet hat.

Organisationen, die bei der Modernisierung ihrer VSAM-Daten erfolgreich sind, beginnen nicht mit dem Zielschema. Sie beginnen mit einem umfassenden, evidenzbasierten Verständnis des Inhalts der VSAM-Dateien, ihrer Struktur, der darauf zugreifenden Programme, der verwendeten Zugriffsmuster und der impliziten Vereinbarungen zwischen Produzenten und Konsumenten. Dieses Verständnis, die Analyse der VSAM-Dateistruktur, ist die Voraussetzung für jede weitere Entscheidung: Welche VSAM-Datensätze lassen sich relationalen Tabellen zuordnen, welche erfordern unterschiedliche Zielarchitekturen, welche Datensatzlayouts benötigen präzisionserhaltende Datentypkonvertierungen und welche gemeinsam genutzten Datensätze müssen als koordinierte Einheiten und nicht unabhängig voneinander migriert werden.

Die vier VSAM-Organisationen und ihre jeweiligen Anforderungen

VSAM-Datensätze sind in vier verschiedenen Organisationsstrukturen organisiert. Jede Struktur weist unterschiedliche Merkmale, typische Zugriffsmuster und eine jeweils eigene Zuordnung zu modernen Zielarchitekturen auf. Werden alle VSAM-Datensätze gleich behandelt und per Massenkonvertierung in relationale Tabellen umgewandelt, ergeben sich Zielarchitekturen, die für einige Datensätze funktionieren, für andere jedoch nur unzureichend oder gar nicht.

KSDS (Key-Sequenced Data Set) ist die gängigste VSAM-Organisation. Datensätze werden physisch über einen Primärschlüssel (den Prime Key) geordnet, was sowohl den direkten Zugriff über den Schlüssel als auch den sequenziellen Zugriff in Schlüsselreihenfolge ermöglicht. KSDS-Dateien verfügen optional über alternative Indizes, sekundäre Schlüsselpfade, die den Abruf über andere Felder als den Prime Key erlauben. Das ideale Ziel für eine KSDS-Datei ist eine relationale Tabelle, in der der Prime Key zum Primärschlüssel wird und alternative Indizes zu SQL-Indizes werden.

ESDS (Entry-Sequenced Data Set) speichert Datensätze in der Reihenfolge ihrer Erstellung. Es gibt keinen Schlüssel; die Datensätze werden über ihren physischen Byte-Offset (RBA: Relative Byte Address) adressiert. ESDS-Dateien werden typischerweise für protokollartige Daten verwendet: Audit-Trails, Transaktionsjournale und Ereignisströme. Je nachdem, wie die konsumierenden Programme auf die Daten zugreifen, eignet sich ein ESDS ideal als Ziel für eine relationale Tabelle (nur Anhängen), einen Ereignisstrom (Kafka-Topic) oder eine Zeitreihendatenbank.

RRDS (Relative Record Data Set) speichert Datensätze fester Länge, die über ihre relative Datensatznummer adressiert werden. Jeder Eintrag in der Datei entspricht einer Datensatznummer; Einträge können leer (gelöscht) sein. RRDS-Dateien werden für Szenarien mit direktem Zugriff verwendet, in denen die Datensatznummer für die Anwendung relevant ist, beispielsweise als einfache Nachschlagetabellen oder Hash-basierte Speicher. Das natürliche Ziel ist eine relationale Tabelle mit einem numerischen Sequenzbezeichner oder, bei kleinen und häufig abgerufenen Datensätzen, eine In-Memory-Lookup-Struktur.

LDS (Linear Data Set) ist ein byteadressierbarer Speicher, dessen Datensatzstruktur für VSAM nicht sichtbar ist. Er wird von Anwendungen (typischerweise DB2, Java-Workloads oder benutzerdefinierten Programmen) verwendet, die ihr eigenes internes Format innerhalb des VSAM-Bytebereichs verwalten. LDS-Dateien können nicht über Standard-COBOL-FD-Einträge analysiert werden; ihre Struktur existiert ausschließlich in der Anwendungsschicht, die sie schreibt.

Die Analyseergebnisse für jeden Datensatz müssen die verwendete Organisation identifizieren, da die Organisation alles nachgelagerte bestimmt: Zielarchitektur, Zugriffsmuster und die spezifischen Analysen, die zum Verständnis ihrer Struktur erforderlich sind.

Das Problem der Datensatzlayoutanalyse

Das Layout der Datensätze ist die analytisch komplexeste Dimension der VSAM-Strukturanalyse. Anders als in einem relationalen Schema, wo jede Spalte einen definierten Typ, Namen und eine vom Datenbanksystem durchgesetzte Einschränkung besitzt, weisen VSAM-Datensätze keine selbstbeschreibende Struktur auf. Das Layout ist vollständig im COBOL-FD-Eintrag definiert, und FD-Einträge sind selten einfach.

FD-Einträge und COPY-Mitglieder

Die Datensatzstruktur eines VSAM-Datasets wird im Eintrag FILE DESCRIPTION (FD) in der COBOL DATA DIVISION definiert. In gut gepflegten Codebasen verweist der FD-Eintrag auf ein COPY-Member, ein gemeinsam genutztes Copybook, das das Datensatzlayout definiert und von jedem Programm eingebunden wird, das auf das Dataset zugreift:

Cobol

       FILE SECTION.
       FD  CUSTOMER-FILE
           LABEL RECORDS ARE STANDARD
           RECORD CONTAINS 250 CHARACTERS.
       01  CUSTOMER-RECORD.
           COPY CUSTMSTR.

Das COPY-Mitglied CUSTMSTR definiert das tatsächliche Feldlayout. Wenn 47 Programme enthalten sind CUSTMSTRDann haben 47 Programme eine gemeinsame Abhängigkeit vom definierten Datensatzlayout. Eine Feldumbenennung in CUSTMSTR Betrifft alle 47. Dies ist das Copybook-Kopplungsproblem, angewendet auf Daten: Das VSAM-Datensatzlayout ist eine gemeinsame Abhängigkeit, die nicht geändert werden kann, ohne jedes Programm, das es verwendet, zu koordinieren.

Für die Migrationsanalyse muss jeder FD-Eintrag seinem Copybook zugeordnet und jedes Copybook jedem Programm, das es enthält, zugeordnet werden. Der Shared-Layout-Abhängigkeitsgraph bildet die Grundlage für das Verständnis des Migrationsumfangs.

NEU DEFINIERT: Mehrere Layouts, ein Datensatz

Das REDEFINES Die Analyse von VSAM-Datensätzen wird in der REDEFINES-Klausel besonders komplex. REDEFINES ermöglicht es, unterschiedliche Feldinterpretationen auf demselben physischen Speicher abzubilden. Ein VSAM-Datensatz, der einen Transaktionstypcode enthält, kann REDEFINES verwenden, um die verbleibenden Bytes je nach diesem Code unterschiedlich zu interpretieren.

Cobol

       01  TRANSACTION-RECORD.
           05  TXN-TYPE        PIC X(2).
           05  TXN-COMMON-DATA PIC X(48).
           05  TXN-DETAIL      REDEFINES TXN-COMMON-DATA.
               10  TXN-PAYMENT.
                   15  PAY-AMOUNT     PIC S9(11)V99 COMP-3.
                   15  PAY-CURRENCY   PIC X(3).
                   15  PAY-METHOD     PIC X(2).
                   15  FILLER         PIC X(28).
           05  TXN-WITHDRAWAL  REDEFINES TXN-COMMON-DATA.
               10  WDR-AMOUNT     PIC S9(11)V99 COMP-3.
               10  WDR-ACCOUNT    PIC 9(12).
               10  WDR-BRANCH     PIC 9(5).
               10  FILLER         PIC X(18).

Dieser Datensatz hat nicht nur ein Layout, sondern drei, je nachdem TXN-TYPEIm angestrebten relationalen Schema erfordert dies typischerweise entweder ein polymorphes Tabellendesign (eine breite Tabelle mit Spalten, die für jede Variante Nullwerte zulassen), ein normalisiertes Design (übergeordnete Zeile plus typspezifische untergeordnete Zeilen) oder eine JSON-Spalte, die die Variantendaten enthält. Keine dieser Entscheidungen kann ohne eine Analyse dessen getroffen werden, was TXN-TYPE In den Daten sind Werte vorhanden, und es werden die REDEFINES-Varianten angezeigt, die tatsächlich verwendet werden.

Eine vollständige Analyse des Datensatzlayouts muss Folgendes beinhalten:

• Identifizieren Sie jede REDEFINES-Hierarchie in jedem FD-Eintrag.
• Ermitteln, welche REDEFINES-Variante unter welchen Bedingungen aktiv ist (erfordert eine Programmlogikanalyse, nicht nur eine FD-Analyse).
• Dokumentieren Sie die Feldtypen, Längen und die Genauigkeit der gepackten Dezimalzahlen für jede Variante.
• Empfehlen Sie die geeignete Normalisierungsstrategie für das Zielschema.

COMP-3 und numerische Genauigkeit

COBOLs PIC S9(11)V99 COMP-3 (Packed Decimal) weist spezifische Genauigkeits- und Skalierungsmerkmale auf, die kein direktes Äquivalent in den SQL-Standarddatentypen haben. V Das Symbol kennzeichnet einen impliziten Dezimalpunkt; der Wert wird als ganze Zahl mit einer impliziten Skala von 2 Dezimalstellen gespeichert. COMP-3 packt zwei Dezimalziffern pro Byte, wobei das letzte Halbbyte das Vorzeichen enthält.

Wenn dieses Feld in eine relationale Datenbank migriert wird, ist das korrekte SQL-Ziel folgendes: DECIMAL(13, 2)nicht FLOATwas Rundungsfehler verursachen würde, und nicht INTEGERDadurch würden die Dezimalstellen verloren gehen. Für Finanzsysteme, in denen COMP-3-Felder Geldbeträge enthalten, ist die Genauigkeitsanforderung unabdingbar. Eine Migration, die konvertiert PIC S9(11)V99 COMP-3 Die Umwandlung in einen Gleitkommadatentyp im Zielschema führt zu Rundungsfehlern, die sich bei Batch-Läufen anhäufen und Auswirkungen auf die Meldepflichten haben können.

Jedes COMP-3-Feld in jedem FD-Eintrag muss vor Beginn der Zielschema-Entwicklung mit seiner genauen Genauigkeit, Skalierung und Vorzeichenkonvention dokumentiert werden.

Analyse von VSAM-Zugriffsmustern in COBOL-Quellcode

Der FD-Eintrag beschreibt den Inhalt des Datensatzes. Die COBOL-PROZESSDIVISION beschreibt, wie das Programm ihn verwendet. Beide sind für eine vollständige Strukturanalyse erforderlich. Die Zugriffsmusteranalyse untersucht jedes Dateizugriffsverb in jedem Programm, das auf den Datensatz zugreift.

Die SELECT-Klausel: Erstes Signal

Die SELECT-Klausel in der ENVIRONMENT DIVISION legt fest, wie das COBOL-Programm auf die VSAM-Datei zugreift:

Cobol

       ENVIRONMENT DIVISION.
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT CUSTOMER-FILE
               ASSIGN TO CUSTFILE
               ORGANIZATION IS INDEXED
               ACCESS MODE IS DYNAMIC
               RECORD KEY IS CUST-PRIME-KEY
               ALTERNATE RECORD KEY IS CUST-ALT-KEY
                   WITH DUPLICATES
               FILE STATUS IS WS-CUST-STATUS.

Diese SELECT-Klausel zeigt Folgendes:

• ORGANIZATION IS INDEXED → KSDS
• ACCESS MODE IS DYNAMIC → Das Programm verwendet sowohl sequenziellen als auch wahlfreien Zugriff
• ALTERNATE RECORD KEY IS CUST-ALT-KEY WITH DUPLICATES → Es existiert ein alternativer Index, und dieses Programm verwendet ihn.

Der dynamische Zugriffsmodus ist besonders wichtig: Ein Programm, das im dynamischen Modus auf ein KSDS zugreift, kann Folgendes verwenden: READ mit einem Schlüssel für den direkten Zugang und READ NEXT Für sequentielles Scannen von einem positionierten Punkt aus. Beide Zugriffsmuster müssen im Ziel repliziert werden, was sowohl die Unterstützung von direktem Lookup (Primärschlüsselabfrage) als auch von Bereichsscans (geordnete Traversierung) im relationalen Schema erfordern kann.

Zugriffsverben und ihre Auswirkungen auf die Migration

Jedes Dateizugriffsverb offenbart eine andere Dimension der Interaktion des Programms mit dem VSAM-Datensatz:

LESEN (direkt): READ CUSTOMER-FILE KEY IS WS-CUST-KEYDirekte Schlüsselsuche. Zuordnungen zu SELECT ... WHERE primary_key = ?Die meisten KSDS-Programme verwenden dieses Muster; es lässt sich direkt in eine relationale indizierte Suche übersetzen.

LESEN (sequenziell): READ CUSTOMER-FILE NEXT RECORDSequenzieller Scan von der aktuellen Position. Karten bis SELECT ... ORDER BY primary_key mit Cursorpositionierung. Die implizite Reihenfolgeabhängigkeit, Programme, die auf die natürliche Tastenreihenfolge von VSAM für die sequentielle Verarbeitung angewiesen sind, müssen im Ziel explizit beibehalten werden.

ZÜNDUNG: START CUSTOMER-FILE KEY >= WS-SEARCH-KEY gefolgt von READ NEXTBereichsscan von einer Teilposition des Schlüssels aus. Entspricht einer Bereichsabfrage: SELECT ... WHERE primary_key >= ? ORDER BY primary_keyProgramme, die START verwenden, legen eine untere Grenze für sequentielle Scans fest; dies ist ein kritisches Zugriffsmuster für KSDS-Dateien, für das es kein einfaches Äquivalent gibt, es sei denn, die Zieltabelle hat die gleiche Schlüsselreihenfolge.

SCHREIBEN: Fügt einen neuen Datensatz anhand des Schlüssels ein. Zuordnung zu INSERT INTOWenn die VSAM-Datei alternative Indizes enthält, muss der Schreibvorgang die Konsistenz mit diesen Indizes gewährleisten; in VSAM geschieht dies automatisch; in einer relationalen Datenbank ist entweder ein Datenbanktrigger oder Anwendungscode erforderlich, um äquivalente sekundäre Indextabellen zu verwalten.

UMSCHREIBEN: Aktualisiert einen bestehenden Datensatz. Der Datensatz muss aktuell vorhanden sein (nach einem Lesevorgang mit Halteabsicht). (Zuordnung zu) UPDATE ... WHERE primary_key = ?REWRITE ist ein Lese-Änderungs-Schreib-Muster; die Migration muss die Transaktionsintegrität beim Lesen und Schreiben gewährleisten.

LÖSCHEN: Entfernt einen Datensatz anhand seines Schlüssels. In KSDS-Dateien entspricht LÖSCHEN einem physischen Löschen. Programme, die erwarten, dass der gelöschte Speicherplatz für nachfolgende sequentielle Scans nicht mehr verfügbar ist, verlassen sich auf dieses physische Löschverhalten. Ein Soft-Delete (logisches Löschflag) im Zielsystem führt nur dann zum gleichen Ergebnis, wenn alle verarbeitenden Programme so aktualisiert werden, dass sie logisch gelöschte Datensätze filtern.

Alternative Indexnutzung: Die versteckte Abhängigkeit

Alternative Indizes für KSDS-Dateien gehören zu den am häufigsten übersehenen Abhängigkeiten bei der VSAM-Migration. Ein alternativer Index ermöglicht es einem Programm, auf eine KSDS-Datei über ein anderes Feld als den Primärschlüssel zuzugreifen. Der alternative Index selbst ist ein separates VSAM-Dataset (ein PATH), das mit dem Basiscluster synchronisiert werden muss.

Ein Programm, das auf CUSTOMER-FILE durch seinen alternativen Schlüssel CUST-ALT-KEY Es besteht eine Abhängigkeit, die unsichtbar ist, wenn nur der FD-Eintrag des Basisclusters analysiert wird. Die Migration muss Folgendes beinhalten:

1. Ermitteln Sie, welche Programme welche alternativen Schlüssel verwenden (sichtbar in der SELECT-Klausel). ALTERNATE RECORD KEY Deklarationen)
2. Ordnen Sie jeden alternativen Schlüssel dem entsprechenden SQL-Index in der Zieltabelle zu.
3. Stellen Sie sicher, dass INSERT- und DELETE-Operationen auf der Zieltabelle das Äquivalent des alternativen Index automatisch beibehalten, typischerweise durch SQL-Eindeutigkeits- oder Nicht-Eindeutigkeitsindizes, die von der Datenbank-Engine transparent verwaltet werden.

Die Analyse muss jeden alternativen Index für jeden KSDS-Datensatz auflisten und jeden den entsprechenden Programmen zuordnen.

Das Problem der gemeinsam genutzten Datensätze: Implizite Datenverträge

VSAM-Dateien werden häufig von mehreren Programmen und JCL-Jobschritten gemeinsam genutzt. Diese gemeinsame Nutzung erzeugt implizite Datenverträge – Vereinbarungen zwischen Programmen über Datensatzlayout, Schlüsselbereiche und Zugriffsmuster, die nur im Code selbst existieren.

Die Abhängigkeit vom gemeinsamen Datensatz hat zwei Dimensionen:

Produzenten-Konsumenten-Beziehungen. Programm A schreibt Datensätze, die Programm B liest. Das Layout, die Schlüsselwerte und die Reihenfolge der von Programm A erzeugten Datensätze müssen exakt den Erwartungen von Programm B entsprechen. Werden A und B unabhängig voneinander in unterschiedliche Zielschemata migriert, ohne den gemeinsamen Datenvertrag abzustimmen, führt dies zu stillschweigenden Datenbeschädigungen: Die Lesezugriffe von B auf die Zieldatenbank sind zwar erfolgreich, die zurückgegebenen Daten liegen jedoch in einem Format vor, das die Logik von B nicht korrekt verarbeiten kann.

Gleichzeitiger Zugriff über mehrere Jobschritte hinweg. Ein JCL-Jobstream kann mehrere Schritte umfassen, die jeweils nacheinander ein anderes Programm auf demselben VSAM-Datensatz ausführen. Schritt 1 schreibt, Schritt 2 liest und transformiert, Schritt 3 schreibt die Ergebnisse. Die Migration muss diese sequentielle Abhängigkeit beibehalten; die Reihenfolge, in der Programme auf den gemeinsam genutzten Datensatz zugreifen und ihn ändern, ist Teil der Verhaltensspezifikation des Systems.

Eine vollständige Analyse gemeinsam genutzter Datensätze muss Folgendes beinhalten:

• Alle VSAM-Datensätze und alle Programme, die darauf zugreifen, werden aufgelistet.
• Klassifizieren Sie den Zugriff jedes Programms als Produzent (SCHREIBEN/ÜBERSCHREIBEN/LÖSCHEN), Konsument (LESEN) oder beides.
• Dokumentieren Sie den JCL-Jobkontext, in dem jedes Programm ausgeführt wird, welchen Schritt es in welchem ​​Job durchläuft und in welcher Scheduler-Abhängigkeitskette es sich befindet.
• Identifizieren Sie Produzenten-Konsumenten-Paare, bei denen das Ausgabeformat des Produzenten exakt mit dem erwarteten Eingabeformat des Konsumenten übereinstimmen muss.

Diese Analyse kann nicht durch die isolierte Betrachtung eines einzelnen Programms erfolgen. Sie erfordert eine programmübergreifende, JCL-übergreifende Strukturanalyse.

Die vor der Migration zu erbringenden Leistungen: Was die Analyse ergeben muss

Eine für die Planung der Datenmodernisierung ausreichende VSAM-Strukturanalyse liefert sechs Ergebnisse:

Ergebnis 1: VSAM-Datensatzinventar

Jeder VSAM-Datensatz in der Umgebung, mit folgenden Angaben: Datensatzorganisation (KSDS/ESDS/RRDS/LDS), durchschnittliche und maximale Datensatzlänge, geschätzte Datensatzanzahl (aus JCL SPACE-Parametern oder Katalogeinträgen), Schlüsselstruktur (Primärschlüssel-Offset, Länge; alternative Schlüsselstrukturen) und ob der Datensatz alternative Indizes besitzt.

Liefergegenstand 2: Datensatzlayoutkatalog

Für jeden Datensatz, jeden FD-Eintrag und die von ihm referenzierten Copybooks, mit: allen Felddefinitionen einschließlich REDEFINES-Hierarchien, jedem COMP-3-Feld mit seiner genauen Genauigkeit und Skalierung, jedem binären (COMP/COMP-5)-Feld mit seiner Byte-Länge, jedem Element variabler Länge (OCCURS DEPENDING ON mit seinem steuernden Feld) und jeder durch REDEFINES implizierten bedingten oder Layoutvariante.

Ergebnis 3: Zugriffsmusterklassifizierung pro Programm

Für jedes Programm, das auf einen Datensatz zugreift: die Merkmale der SELECT-Klausel (Organisation, Zugriffsmodus, Verwendung alternativer Schlüssel), die vollständige Menge der verwendeten Zugriffsverben (READ/START/WRITE/REWRITE/DELETE), ob das Programm sequenziellen Zugriff verwendet und von der Schlüsselreihenfolge abhängt, welche alternativen Indizes das Programm verwendet und ob das Programm Lese-Änderungs-Schreib-Muster (implizite Transaktionsanforderungen) aufweist.

Ergebnis 4: Gemeinsame Datensatzkarte

Ein gerichteter Graph, dessen Knoten VSAM-Datensätze und -Programme darstellen und dessen Kanten Zugriffsbeziehungen mit ihrem Typ (Lesen/Schreiben) repräsentieren. Der Graph zeigt jeden Produzenten, jeden Konsumenten, Produzenten-Konsumenten-Paare und den JCL-Jobsequenzkontext für jeden Zugriff.

Ergebnis 5: Empfehlungen zum Zielschema

Für jeden VSAM-Datensatz die empfohlene Zielarchitektur basierend auf seiner Organisation und seinen Zugriffsmustern:

VSAM-Typ	Primäres Zugriffsmuster	Empfohlenes Ziel
KSDS, nur direkter Schlüsselzugriff	Punktabfragen über den Primärschlüssel	Relationale Tabelle, indiziert
KSDS, mit START/WEITERLESEN	Bereichsscans in Schlüsselreihenfolge	Relationale Tabelle mit gruppiertem Index
KSDS mit alternativen Indizes	Mehrpfad-Schlüsselzugriff	Relationale Tabelle mit mehreren Indizes
ESDS, nur zum Anhängen	Sequenzielles Anhängen, kein Schlüssel	Nur-Anhängen-Tabelle, Ereignisstrom oder Protokoll
ESDS mit RBA-Zugang	Byte-Offset-Positionierung	Objektspeicher mit Metadatenindex
RRDS	Zugriff auf Datensatznummern	Relationale Tabelle mit Sequenzspalte
Großes KSDS (Bulk, Analytik)	Vollständige sequentielle Scans	Spaltenorientierte Speicherung oder Data Lake
LDS	Anwendungsverwaltetes internes Format	Erfordert eine Analyse auf Anwendungsebene.

Ergebnis 6: Präzisionssensibles Feldregister

Jedes COMP-3-, COMP-, COMP-5- und Gleitkommafeld in jedem Datensatz, mit seiner COBOL-Definition, der korrekten SQL-Datentypzuordnung und einem Kennzeichen für jedes Feld, bei dem die Zuordnung vor und nach der Migration eine Genauigkeitsprüfung erfordert.

Was unterscheidet die VSAM-Analyse von der relationalen Schemaanalyse?

Teams mit Erfahrung in der Migration zwischen relationalen Datenbanken unterschätzen mitunter die Bedeutung der VSAM-Analyse, da sie das gängige Schema-Migrationsmodell anwenden: DDL extrahieren, Schema neu gestalten, Daten migrieren. VSAM kennt jedoch kein DDL im herkömmlichen Sinne. Das Schema ist über den Quellcode verteilt: in FD-Einträgen, Copybooks, SELECT-Klauseln und in der PROCEDURE DIVISION-Logik, die die für jeden Datensatz aktive REDEFINES-Variante bestimmt.

Drei Eigenschaften unterscheiden die VSAM-Analyse strukturell:

Das Schema ist im Code definiert. Das Datensatzlayout für ein VSAM-Dataset wird im COBOL-Quellcode und nicht in einem Datenbankkatalog festgelegt. Um es zu finden, muss der Quellcode analysiert werden. Änderungen erfordern die Abstimmung aller Programme, die das Copybook verwenden. Das Verständnis aller Varianten setzt die Analyse der Programmlogik voraus, nicht nur des FD-Eintrags.

Zugriffsmuster sind im Programmverhalten implizit. Eine relationale Datenbank legt Abfragemuster über EXPLAIN-Pläne und Abfrageprotokolle offen. VSAM-Zugriffsmuster sind nur in der PROCEDURE DIVISION der Programme sichtbar, die auf die Datei zugreifen. Um zu verstehen, ob ein Programm von der Schlüsselreihenfolge, dem alternativen Indexzugriff oder Bereichsscans abhängt, ist eine Codeanalyse erforderlich.

Gemeinsam genutzte Datensätze erzeugen versteckte Verträge. In einer relationalen Datenbank ist das Schema ein Artefakt auf Datenbankebene, das alle Nutzer gemeinsam nutzen und einsehen können. In VSAM ist das Datensatzlayout in das Copybook jedes Programms eingebettet. Zwei Programme können unterschiedliche Kopien desselben nominell identischen Datensatzlayouts aufweisen. Um diese Abweichung zu erkennen, müssen die Copybook-Definitionen der verschiedenen Programme verglichen werden, anstatt eine einzelne Schemadefinition zu untersuchen.

Wie SMART TS XL Führt VSAM-Strukturanalysen durch

SMART TS XL statische Code-Analyse Die Analyse durchsucht jedes Element der VSAM-Struktur im COBOL-Quellcode: FD-Einträge, COPY-Member-Erweiterungen, SELECT-Klauseldeklarationen (Organisation, Zugriffsmodus, Primär- und Alternativschlüsselspezifikationen) sowie alle Dateizugriffsverben in der PROCEDURE DIVISION. Für jeden VSAM-Datensatz liefert die Analyse die Zugriffsmusterklassifizierung, das Datensatzlayout mit vollständiger REDEFINES-Auflösung und das COMP-3-Feldregister mit präzisen Metadaten.

Die Abhängigkeitsabbildung der Anwendung erstellt die Übersicht der gemeinsam genutzten Datensätze: Jedes Programm, das auf einen VSAM-Datensatz zugreift, wird nach Zugriffstyp klassifiziert, wobei Produzenten-Konsumenten-Beziehungen identifiziert und der Copybook-Sharing-Graph aufgelöst wird. Wenn 47 Programme ein Copybook gemeinsam nutzen, das ein VSAM-Datensatzlayout definiert, macht die Abhängigkeitsabbildung alle 47 sichtbar, bevor eine Migrationsentscheidung getroffen wird – und nicht erst, nachdem eine Layoutänderung 47 Programme unerwartet beeinträchtigt hat.

Die JCL-Erweiterungsfunktion liefert den operativen Kontext: Welche JCL-Jobschritte referenzieren welche VSAM-Datasets in ihren DD-Anweisungen, in welcher Reihenfolge und in welchen Jobstreams? Die auf JCL-Jobebene bestehenden Produzenten-Konsumenten-Beziehungen, bei denen Schritt 1 in ein VSAM-Dataset schreibt, das Schritt 3 liest, werden in der JCL-Abhängigkeitsanalyse sichtbar. Dies ermöglicht eine Migrationssequenzierung, die die vom Batch-Plan vorgegebenen Abhängigkeiten beibehält.

Die Auswirkungsanalyse beantwortet die Frage, die jeder VSAM-Migrationsentscheidung vorausgeht: Welche Programme sind betroffen, wenn sich das Layout dieses Datensatzes ändert? Der gesamte Wirkungsbereich – jedes Programm, das das relevante Copybook verwendet, jeder JCL-Schritt, der auf den Datensatz verweist – wird vor Beginn der Migrationsarbeiten aufgelistet. Dies bildet die Grundlage für eine koordinierte Migrationsplanung, anstatt betroffene Programme einzeln und fehlerhaft zu ermitteln.

Die unternehmensweite Suchfunktion ermöglicht die Abfrage des gesamten VSAM-Inventars während des gesamten Modernisierungsprogramms: Finden Sie jedes Programm, das auf einen bestimmten VSAM-Datensatz zugreift, jedes Copybook, das ein bestimmtes Datensatzlayout definiert, jedes Programm, das START/READ NEXT-Muster verwendet (was auf Abhängigkeiten in der Reihenfolge hinweist), jedes Feld, das als COMP-3 definiert ist (was eine präzise Zielzuordnung erfordert), in Sekundenschnelle, über Millionen von COBOL-Zeilen hinweg.

Wie im Kontext von Migration von IMS- und VSAM-Datenstrukturen zusammen mit COBOL-ProgrammenDatenmigration und Codeanalyse müssen parallel erfolgen. SMART TS XLDie VSAM-Strukturanalyse liefert das Inventar, das diese Parallelität handhabbar macht, die gemeinsamen Datensatzlayouts, die Zugriffsmuster und die Produzenten-Konsumenten-Beziehungen, die bestimmen, ob die Datenmigration unabhängig erfolgen kann oder mit Programmänderungen koordiniert werden muss.

Die Struktur, die Sie verstehen, ist die Struktur, die Sie migrieren können.

Die Analyse der VSAM-Dateistruktur ist in einem Modernisierungsprogramm kein zusätzlicher Aufwand. Sie bildet die Grundlage für fundierte Entscheidungen. Ohne Kenntnis der Datensatzlayoutvarianten lässt sich das Zielschema nicht entwerfen. Die Migration kann nicht sequenziert werden, ohne die Produzenten-Konsumenten-Beziehungen zu kennen. Die Genauigkeit der COMP-3-Felder kann nicht erhalten bleiben, ohne zu wissen, welche Felder dezimalfähige Zieldatentypen benötigen.

Jedes Modernisierungsprogramm, das diese Analyse auslässt, entdeckt die übersehenen Fehler erst während der Migration: etwa wenn eine nicht analysierte REDEFINES-Variante fehlerhafte Datensätze im Zielsystem erzeugt, wenn ein gemeinsam genutzter Datensatz migriert wird, ohne alle Nutzer zu koordinieren, oder wenn ein Bereichsscan, der auf der Schlüsselsortierung von VSAM basiert, Ergebnisse mit undefinierter Reihenfolge aus einer Zieltabelle liefert, die nicht mit einem gruppierten Index entworfen wurde. Diese Entdeckungen während der Ausführung verursachen ein Vielfaches der Kosten, die die Analyse in der Planungsphase verursacht hätte.

Zuerst die Struktur verstehen. Dann die Daten migrieren. Die Reihenfolge ist keine Formalität. Sie entscheidet darüber, ob die Migration korrekte Ergebnisse liefert oder ob die Daten nur so lange korrekt erscheinen, bis die erste behördliche Prüfung stattfindet.