Analisi della struttura dei file VSAM per progetti di modernizzazione dei dati.

La migrazione dei dati non può avvenire in modo isolato, deve evolversi parallelamente alle applicazioni COBOL che leggono e scrivono tali dataset. Questo vincolo definisce l'intera sfida della modernizzazione di VSAM. VSAM (Virtual Storage Access Method) non è semplicemente un formato di file. È il contratto dati tra i programmi, la specifica implicita, definita solo nelle voci FD e nelle clausole SELECT, che regola il modo in cui ogni programma in un sistema aziendale produce e utilizza i suoi dati aziendali più critici. Una singola modifica al layout di un record che non si riflette in ogni programma che legge quel record produce un danneggiamento dei dati che potrebbe non emergere fino a quando non viene eseguito un report normativo su dati che non hanno più il significato previsto dal programma che li utilizza.

Le organizzazioni che hanno successo nella modernizzazione dei dati VSAM non sono quelle che partono dallo schema di destinazione. Sono quelle che partono da una comprensione completa e basata su dati concreti del contenuto dei file VSAM, della loro struttura, dei programmi che vi accedono, delle modalità di accesso e dei contratti impliciti esistenti tra produttori e consumatori. Tale comprensione, ovvero l'analisi della struttura dei file VSAM, è il prerequisito per ogni decisione successiva: quali dataset VSAM corrispondono a tabelle relazionali, quali richiedono architetture di destinazione diverse, quali layout di record necessitano di conversioni di tipo dati che preservino la precisione e quali dataset condivisi devono migrare come unità coordinate anziché in modo indipendente.

Le quattro organizzazioni VSAM e i requisiti di ciascuna

I dataset VSAM sono suddivisi in quattro organizzazioni distinte. Ognuna presenta caratteristiche strutturali diverse, un modello di accesso tipico differente e una mappatura naturale differente verso le moderne architetture di destinazione. Trattare tutti i dataset VSAM allo stesso modo, convertendoli in blocco in tabelle relazionali, produce destinazioni che funzionano per alcuni dataset e che presentano prestazioni scadenti o falliscono completamente per altri.

KSDS (Key-Sequenced Data Set) è il formato di organizzazione VSAM più comune. I record sono fisicamente ordinati in base a una chiave primaria, consentendo sia l'accesso diretto tramite chiave che l'accesso sequenziale in base all'ordine della chiave. I file KSDS possono facoltativamente includere indici alternativi, ovvero percorsi di chiave secondaria che consentono il recupero dei dati in base a campi diversi dalla chiave primaria. Il formato ideale per un KSDS è una tabella relazionale in cui la chiave primaria diventa la chiave primaria e gli indici alternativi diventano indici SQL.

ESDS (Entry-Sequenced Data Set) memorizza i record nell'ordine in cui sono stati scritti. Non esiste una chiave, i record sono indirizzati tramite il loro offset fisico in byte (RBA: Relative Byte Address). I file ESDS sono tipicamente utilizzati per dati di tipo log: registri di controllo, registri delle transazioni, flussi di eventi. La destinazione naturale per un file ESDS è una tabella relazionale di tipo append-only, un flusso di eventi (argomento Kafka) o un database di serie temporali, a seconda di come i programmi che utilizzano i dati vi accedono.

RRDS (Relative Record Data Set) memorizza record a lunghezza fissa, indirizzati tramite un numero di record relativo. Ogni slot nel file corrisponde a un numero di record; gli slot possono essere vuoti (eliminati). I file RRDS vengono utilizzati in scenari di accesso diretto in cui il numero di record è significativo per l'applicazione, spesso come semplici tabelle di ricerca o come archivio basato su hash. La destinazione naturale è una tabella relazionale con un identificatore di sequenza numerica, oppure una struttura di ricerca in memoria se il dataset è piccolo e viene acceduto frequentemente.

LDS (Linear Data Set) è un tipo di memoria indirizzabile a byte, la cui struttura di record non è visibile a VSAM. Viene utilizzato da applicazioni (tipicamente DB2, carichi di lavoro Java o programmi personalizzati) che gestiscono il proprio formato interno all'interno dell'intervallo di byte di VSAM. I file LDS non possono essere analizzati tramite le voci FD COBOL standard; la loro struttura esiste solo nel livello applicativo che li scrive.

L'output dell'analisi per ciascun dataset deve identificare l'organizzazione a cui si riferisce, poiché l'organizzazione determina tutto ciò che segue: architettura di destinazione, modello di accesso e analisi specifica necessaria per comprenderne la struttura.

Il problema dell'analisi del layout dei record

La struttura dei record è la dimensione analiticamente più complessa dell'analisi della struttura VSAM. A differenza di uno schema relazionale in cui ogni colonna ha un tipo, un nome e un vincolo definiti e imposti dal motore del database, i record VSAM non hanno una struttura auto-descrittiva. La struttura esiste interamente nella voce FD COBOL, e le voci FD sono raramente semplici.

Iscrizioni FD e membri COPY

La struttura dei record di un dataset VSAM è definita nella voce FILE DESCRIPTION (FD) nella COBOL DATA DIVISION. Nei codebase ben mantenuti, la voce FD fa riferimento a un membro COPY, un copybook condiviso che definisce il layout dei record e viene incluso da ogni programma che accede al dataset:

cobolo

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

Il membro COPY CUSTMSTR definisce il layout effettivo del campo. Se 47 programmi includono CUSTMSTR, quindi 47 programmi condividono una dipendenza dal layout del record che definisce. Un campo rinominato in CUSTMSTR Riguarda tutti e 47. Questo è il problema di accoppiamento del copybook applicato ai dati: il layout del record VSAM è una dipendenza condivisa che non può essere modificata senza coordinare ogni programma che lo utilizza.

Per l'analisi della migrazione, ogni voce FD deve essere tracciata fino al relativo copybook e ogni copybook deve essere mappato a ogni programma che lo include. Il grafico delle dipendenze del layout condiviso è fondamentale per comprendere la portata della migrazione.

RIDEFINISCE: Layout multipli, un solo disco

Migliori REDEFINES La clausola REDEFINES è dove l'analisi dei record VSAM diventa veramente complessa. REDEFINES consente diverse interpretazioni dei campi per sovrapporsi alla stessa memoria fisica. Un record VSAM che contiene un codice di tipo di transazione può utilizzare REDEFINES per interpretare i byte rimanenti in modo diverso a seconda di tale codice:

cobolo

       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).

Questo disco non ha un layout ma tre, a seconda di TXN-TYPENello schema relazionale di destinazione, ciò richiede in genere una progettazione di tabella polimorfica (una singola tabella larga con colonne nullable per ogni variante), una progettazione normalizzata (riga padre più righe figlio specifiche per tipo) o una colonna JSON contenente i dati della variante. Nessuna di queste decisioni può essere presa senza analizzare cosa TXN-TYPE valori presenti nei dati e quali varianti di REDEFINES vengono effettivamente utilizzate.

Un'analisi completa del layout dei record deve:

• Identifica ogni gerarchia REDEFINES in ogni voce FD
• Determinare quale variante di REDEFINES è attiva in quali condizioni (richiede un'analisi della logica del programma, non solo un'analisi delle dipendenze).
• Documentare i tipi di campo, le lunghezze e la precisione decimale compressa per ogni variante
• Raccomandare la strategia di normalizzazione appropriata per lo schema di destinazione

COMP-3 e precisione numerica

COBOL PIC S9(11)V99 COMP-3 (decimale compresso) ha caratteristiche di precisione e scala specifiche che non hanno un equivalente diretto nei tipi di dati standard SQL. V indica un punto decimale implicito, il valore viene memorizzato come un numero intero con una scala implicita di 2 cifre decimali. COMP-3 comprime due cifre decimali per byte, con l'ultimo mezzo byte che contiene il segno.

Quando questo campo viene migrato in un database relazionale, il target SQL corretto è DECIMAL(13, 2)non, FLOAT, il che introdurrebbe errori di arrotondamento e non INTEGER, che perderebbe le cifre decimali. Per i sistemi finanziari in cui i campi COMP-3 contengono importi monetari, il requisito di precisione non è negoziabile. Una migrazione che converte PIC S9(11)V99 COMP-3 La conversione a un tipo a virgola mobile nello schema di destinazione introduce errori di arrotondamento che si accumulano nelle esecuzioni batch e possono influire sulla rendicontazione normativa.

Ogni campo COMP-3 in ogni voce FD deve essere documentato con la sua precisione esatta, scala e convenzione di segno prima che inizi la progettazione dello schema di destinazione.

Analisi dei modelli di accesso VSAM nel codice sorgente COBOL

La voce FD descrive il contenuto del record. La sezione COBOL PROCEDURE DIVISION descrive come il programma lo utilizza. Entrambe sono necessarie per un'analisi strutturale completa. L'analisi dei modelli di accesso esamina ogni verbo di accesso al file in ogni programma che interagisce con il dataset.

La clausola SELECT: Primo segnale

La clausola SELECT nella sezione ENVIRONMENT definisce come il programma COBOL accederà al file VSAM:

cobolo

       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.

Questa clausola SELECT rivela:

• ORGANIZATION IS INDEXED → KSDS
• ACCESS MODE IS DYNAMIC → il programma utilizza sia l'accesso sequenziale che quello casuale
• ALTERNATE RECORD KEY IS CUST-ALT-KEY WITH DUPLICATES → esiste un indice alternativo e questo programma lo utilizza

La modalità di accesso dinamico è particolarmente significativa: un programma che accede a un KSDS in modalità DINAMICA può utilizzare READ con una chiave per l'accesso diretto e READ NEXT per la scansione sequenziale da un punto posizionato. Entrambi i modelli di accesso devono essere replicati nella destinazione, il che potrebbe richiedere il supporto sia della ricerca diretta (query con chiave primaria) che della scansione di intervallo (attraversamento ordinato) nello schema relazionale.

Verbi di accesso e le loro implicazioni in ambito migratorio

Ciascun verbo di accesso al file rivela una diversa dimensione di come il programma interagisce con il dataset VSAM:

LEGGI (direttamente): READ CUSTOMER-FILE KEY IS WS-CUST-KEY, ricerca chiave diretta. Mappa a SELECT ... WHERE primary_key = ?La maggior parte dei programmi KSDS utilizza questo schema; esso si traduce direttamente in una ricerca indicizzata relazionale.

LEGGI (in sequenza): READ CUSTOMER-FILE NEXT RECORD, scansione sequenziale dalla posizione corrente. Mappa a SELECT ... ORDER BY primary_key con posizionamento del cursore. La dipendenza implicita dall'ordinamento, ovvero i programmi che si basano sull'ordine naturale dei tasti di VSAM per l'elaborazione sequenziale, deve essere preservata esplicitamente nel sistema di destinazione.

ACCENSIONE: START CUSTOMER-FILE KEY >= WS-SEARCH-KEY seguito da READ NEXT, scansione di intervallo da una posizione chiave parziale. Corrisponde a una query di intervallo: SELECT ... WHERE primary_key >= ? ORDER BY primary_keyI programmi che utilizzano START stabiliscono un limite inferiore per la scansione sequenziale; questo è uno schema di accesso critico per i file KSDS che non ha un equivalente semplice a meno che la tabella di destinazione non abbia lo stesso ordine delle chiavi.

SCRIVERE: Inserisce un nuovo record tramite chiave. Mappa a INSERT INTOSe il file VSAM ha indici alternativi, la scrittura deve mantenere la coerenza con tali indici; in VSAM, questo avviene automaticamente; in un database relazionale, richiede un trigger di database o codice a livello di applicazione per mantenere tabelle di indice secondarie equivalenti.

RISCRIVERE: Aggiorna un record sul posto. Il record deve essere attualmente bloccato (dopo una LETTURA con intento di blocco). Mappa a UPDATE ... WHERE primary_key = ?REWRITE segue uno schema di lettura-modifica-scrittura; la migrazione deve preservare l'integrità transazionale sia durante la lettura che durante la scrittura.

CANCELLA: Rimuove un record tramite chiave. Nei file KSDS, CANCELLA è una cancellazione fisica. I programmi che si aspettano che lo slot eliminato non sia disponibile per le scansioni sequenziali future dipendono da questo comportamento di cancellazione fisica; una cancellazione logica (flag di cancellazione logica) nel sistema di destinazione non produce un comportamento equivalente a meno che ogni programma utilizzatore non venga aggiornato per filtrare i record eliminati logicamente.

Utilizzo alternativo dell'indice: la dipendenza nascosta

Gli indici alternativi sui file KSDS sono una delle dipendenze più spesso trascurate nella migrazione VSAM. Un indice alternativo consente a un programma di accedere a un file KSDS tramite un campo diverso dalla chiave primaria. L'indice alternativo è a sua volta un dataset VSAM separato (un PATH) che deve essere mantenuto sincronizzato con il cluster di base.

Un programma che accede CUSTOMER-FILE attraverso la sua chiave alternativa CUST-ALT-KEY presenta una dipendenza invisibile se si analizza solo la voce FD del cluster base. La migrazione deve:

1. Identifica quali programmi utilizzano quali chiavi alternative (visibili nella clausola SELECT) ALTERNATE RECORD KEY dichiarazioni)
2. Associa ciascuna chiave alternativa all'indice SQL equivalente sulla tabella di destinazione.
3. Assicurarsi che le operazioni INSERT e DELETE sulla tabella di destinazione mantengano automaticamente l'equivalente dell'indice alternativo, in genere tramite indici SQL unici o non unici che il motore del database gestisce in modo trasparente.

L'analisi deve enumerare ogni indice alternativo per ogni dataset KSDS e mappare ciascuno di essi ai programmi che lo utilizzano.

Il problema dei dataset condivisi: contratti impliciti sui dati

I file VSAM vengono spesso condivisi tra più programmi e più fasi di job JCL. Questa condivisione crea contratti di dati impliciti, accordi tra i programmi sulla struttura dei record, sugli intervalli di chiavi e sui modelli di accesso che esistono solo nel codice stesso.

La dipendenza dal dataset condiviso ha due dimensioni:

Relazioni produttore-consumatore. Il programma A scrive record che il programma B legge. La struttura dei record, i valori chiave e l'ordine prodotti dal programma A devono corrispondere esattamente a ciò che il programma B si aspetta di leggere. Se A e B vengono migrati indipendentemente a schemi di destinazione diversi senza coordinare il contratto dati condiviso, il risultato è un danneggiamento silenzioso dei dati: le letture di B hanno successo sul database di destinazione, ma restituiscono dati in un formato che la logica di B non gestisce correttamente.

Accesso simultaneo tra le fasi del job. Un flusso di job JCL può avere più fasi, ognuna delle quali esegue un programma diverso sullo stesso dataset VSAM in sequenza. La fase 1 scrive, la fase 2 legge e trasforma, la fase 3 scrive i risultati. La migrazione deve preservare questa dipendenza sequenziale; l'ordine in cui i programmi accedono e modificano il dataset condiviso fa parte delle specifiche comportamentali del sistema.

Un'analisi completa del set di dati condiviso deve:

• Elenca ogni dataset VSAM e ogni programma che vi accede.
• Classifica l'accesso di ciascun programma come produttore (SCRITTURA/RISCRITTURA/ELIMINA), consumatore (LETTURA) o entrambi.
• Documentare il contesto del job JCL in cui viene eseguito ciascun programma, quale passaggio, in quale job, in quale catena di dipendenze dello scheduler
• Identificare le coppie produttore-consumatore in cui il formato di output del produttore deve corrispondere esattamente al formato di input previsto dal consumatore.

Questa analisi non può essere effettuata esaminando un singolo programma isolatamente. Richiede un'analisi strutturale interprogrammatica e inter-JCL.

I risultati preliminari alla migrazione: cosa deve produrre l'analisi

Un'analisi strutturale VSAM sufficiente per la pianificazione della modernizzazione dei dati produce sei risultati:

Risultato finale 1: Inventario del dataset VSAM

Ogni dataset VSAM presente nell'ambiente, con: organizzazione del dataset (KSDS/ESDS/RRDS/LDS), lunghezza media e massima dei record, numero stimato di record (dai parametri JCL SPACE o dalle voci del catalogo), struttura della chiave (offset della chiave primaria, lunghezza; strutture di chiave alternative) e se il dataset ha indici alternativi.

Risultato finale 2: Catalogo del layout dei record

Per ogni dataset, ogni voce FD e i copybook a cui fa riferimento, con: tutte le definizioni dei campi, comprese le gerarchie REDEFINES, ogni campo COMP-3 con la sua precisione e scala esatte, ogni campo binario (COMP/COMP-5) con la sua lunghezza in byte, ogni elemento a lunghezza variabile (OCCURS DEPENDING ON) con il relativo campo di controllo e ogni variante condizionale o di layout implicata da REDEFINES.

Risultato 3: Classificazione dei modelli di accesso per programma

Per ogni programma che accede a ciascun dataset: le caratteristiche della clausola SELECT (organizzazione, modalità di accesso, utilizzo di chiavi alternative), l'insieme completo dei verbi di accesso utilizzati (READ/START/WRITE/REWRITE/DELETE), se il programma utilizza l'accesso sequenziale e dipende dall'ordine delle chiavi, quali indici alternativi utilizza il programma e se il programma ha modelli di lettura-modifica-scrittura (requisiti impliciti di transazione).

Risultato atteso n. 4: Mappa del set di dati condiviso

Un grafo orientato in cui i nodi rappresentano i dataset e i programmi VSAM, e gli archi rappresentano le relazioni di accesso con il relativo tipo (lettura/scrittura). Il grafo mostra ogni produttore, ogni consumatore, le coppie produttore-consumatore e il contesto della sequenza di job JCL per ogni accesso.

Risultato atteso 5: Raccomandazioni sullo schema di destinazione

Per ciascun dataset VSAM, l'architettura di destinazione consigliata in base alla sua organizzazione e ai modelli di accesso:

Tipo VSAM	Punto di accesso principale	Obiettivo consigliato
KSDS, accesso diretto solo tramite chiave	Ricerche puntuali tramite chiave primaria	Tabella relazionale indicizzata
KSDS, con AVVIA/LEGGI IL PROSSIMO	Scansioni di intervallo in ordine chiave	Tabella relazionale con indice clusterizzato
KSDS con indici alternativi	Accesso tramite chiave multi-percorso	Tabella relazionale con indici multipli
ESDS, solo aggiunta	Aggiunta sequenziale, senza chiave	Aggiungi solo alla tabella, al flusso di eventi o al registro
ESDS, con accesso RBA	Posizionamento offset byte	Archiviazione di oggetti con indice dei metadati
RRDS	accesso al numero di record	Tabella relazionale con colonna di sequenza
KSDS di grandi dimensioni (in massa, analisi)	Scansioni sequenziali complete	Archiviazione a colonne o data lake
LDS	Formato interno gestito dall'applicazione	Richiede un'analisi a livello applicativo

Risultato atteso n. 6: Registro di campo sensibile alla precisione

Ogni campo COMP-3, COMP, COMP-5 e a virgola mobile in ogni dataset, con la relativa definizione COBOL, la corretta mappatura del tipo di dati SQL e un flag per ogni campo per il quale la mappatura richiede una convalida della precisione prima e dopo la migrazione.

Cosa distingue l'analisi VSAM dall'analisi degli schemi relazionali?

I team con esperienza nella migrazione tra database relazionali a volte sottovalutano l'analisi VSAM perché applicano il modello mentale della migrazione dello schema: estrarre il DDL, riprogettare lo schema, migrare i dati. VSAM non ha un DDL nel senso del database. Lo schema è distribuito nel codice sorgente, nelle voci FD, nei copybook, nelle clausole SELECT e nella logica PROCEDURE DIVISION che determina quale variante REDEFINES è attiva per un dato record.

Tre proprietà rendono l'analisi VSAM strutturalmente diversa:

Lo schema risiede nel codice. La struttura dei record per un dataset VSAM è definita nel codice sorgente COBOL, non in un catalogo di database. Trovarla richiede l'analisi del codice sorgente. Modificarla richiede il coordinamento di ogni programma che condivide il copybook. Comprendere tutte le sue varianti richiede l'analisi della logica del programma, non solo della voce FD.

I modelli di accesso sono impliciti nel comportamento del programma. Un database relazionale espone i modelli di query tramite i piani EXPLAIN e i log delle query. I modelli di accesso VSAM sono visibili solo nella PROCEDURE DIVISION dei programmi che accedono al file. Comprendere se un programma dipende dall'ordinamento delle chiavi, dall'accesso tramite indice alternativo o dalla scansione di intervalli richiede l'analisi del codice.

I dataset condivisi creano contratti impliciti. In un database relazionale, lo schema è un artefatto a livello di database che tutti i consumatori condividono e visualizzano. In VSAM, il layout dei record è incorporato nel copybook di ciascun programma. Due programmi possono avere copie divergenti di quello che nominalmente è lo stesso layout dei record, e scoprire questa divergenza richiede il confronto delle definizioni del copybook tra i programmi, non l'ispezione di una singola definizione di schema.

Come SMART TS XL Esegue l'analisi strutturale VSAM

SMART TS XL'S analisi statica del codice Analizza ogni elemento della struttura VSAM presente nel codice sorgente COBOL: voci FD, espansioni dei membri COPY, dichiarazioni della clausola SELECT (organizzazione, modalità di accesso, specifiche della chiave primaria e alternativa) e ogni verbo di accesso ai file nella PROCEDURE DIVISION. Per ogni dataset VSAM, l'analisi produce la classificazione del modello di accesso, il layout del record con risoluzione completa di REDEFINES e il registro dei campi COMP-3 con metadati precisi.

La mappatura delle dipendenze delle applicazioni crea la mappa del dataset condiviso: ogni programma che accede a ciascun dataset VSAM, classificato per tipo di accesso, con le relazioni produttore-consumatore identificate e il grafo di condivisione del copybook risolto. Quando 47 programmi condividono un copybook che definisce il layout di un record VSAM, la mappa delle dipendenze li rende visibili tutti e 47 prima che venga presa qualsiasi decisione di migrazione, non dopo che una modifica del layout ha compromesso il funzionamento di 47 programmi in modi imprevisti.

La funzionalità di espansione JCL fornisce il contesto operativo: quali fasi del job JCL fanno riferimento a quali dataset VSAM nelle loro istruzioni DD, in quale sequenza e in quali flussi di job. Le relazioni produttore-consumatore che esistono a livello di job JCL, dove la Fase 1 scrive su un dataset VSAM che la Fase 3 legge, sono visibili nell'analisi delle dipendenze JCL, consentendo una sequenza di migrazione che preserva le dipendenze dell'ordine operativo imposte dalla pianificazione batch.

La funzionalità di analisi dell'impatto risponde alla domanda che precede ogni decisione di migrazione VSAM: se la struttura di questo dataset cambia, quali programmi ne risentiranno? L'ambito dell'impatto, ovvero ogni programma che condivide il copybook pertinente e ogni passaggio JCL che fa riferimento al dataset, viene enumerato prima dell'inizio di qualsiasi attività di migrazione, fornendo la base per una pianificazione coordinata della migrazione anziché scoprire i programmi interessati uno alla volta.

La funzionalità di ricerca aziendale rende l'intero inventario VSAM interrogabile durante l'intero programma di modernizzazione: trova ogni programma che accede a uno specifico dataset VSAM, ogni copybook che definisce un layout di record specifico, ogni programma che utilizza pattern START/READ NEXT (che indicano dipendenze di ordinamento), ogni campo definito come COMP-3 (che richiede una mappatura di destinazione precisa), in pochi secondi, attraverso milioni di righe di COBOL.

Come descritto nel contesto di Migrazione delle strutture dati IMS e VSAM insieme ai programmi COBOLLa migrazione dei dati e l'analisi del codice devono procedere in parallelo. SMART TS XLL'analisi strutturale VSAM fornisce l'inventario che rende gestibile tale parallelismo, ovvero i layout dei record condivisi, i modelli di accesso e le relazioni produttore-consumatore che determinano se la migrazione dei dati può procedere in modo indipendente o deve essere coordinata con le modifiche al programma.

La struttura che comprendi è la struttura che puoi migrare

L'analisi della struttura dei file VSAM non rappresenta un onere aggiuntivo in un programma di modernizzazione, bensì la base per il processo decisionale. Lo schema di destinazione non può essere progettato senza conoscere le varianti di layout dei record. La migrazione non può essere sequenziata senza conoscere le relazioni produttore-consumatore. La precisione dei campi COMP-3 non può essere preservata senza sapere quali campi richiedono tipi di destinazione che supportino i decimali.

Ogni programma di modernizzazione che omette questa analisi scopre ciò che gli è sfuggito durante l'esecuzione della migrazione: quando una variante REDEFINES non analizzata produce record non validi nella destinazione, quando un dataset condiviso viene migrato senza coordinare tutti i suoi utilizzatori, quando una scansione di intervallo basata sull'ordinamento delle chiavi di VSAM restituisce risultati in un ordine indefinito da una tabella di destinazione non progettata con un indice cluster. Queste scoperte durante l'esecuzione hanno un costo di gran lunga superiore a quello che l'analisi avrebbe comportato in fase di pianificazione.

Prima di tutto, è fondamentale comprendere la struttura. Solo in un secondo momento si procede alla migrazione dei dati. L'ordine non è una formalità, ma fa la differenza tra una migrazione che produce risultati corretti e una che produce dati apparentemente a posto solo in attesa del primo audit normativo.