IMS non è un sistema legacy nel senso di obsoleto. È il motore di database alla base della contabilità clienti delle principali banche, dell'amministrazione delle polizze delle compagnie assicurative e dell'elaborazione dei sinistri degli enti pagatori del settore sanitario. IBM continua a svilupparlo. Il problema non è che IMS abbia smesso di funzionare, il problema è che tutti gli sviluppatori che sapevano come navigare nella sua struttura gerarchica ad albero dei segmenti stanno andando in pensione, ogni modifica a un sistema basato su IMS richiede la comprensione di un modello dati che non ha SQL e ogni piano di migrazione che tratta IMS come un database relazionale scopre la differenza a proprie spese.
La strada più difficile è scoprire, a metà della migrazione, che un programma COBOL accede a IMS non tramite una semplice ricerca per chiave, ma attraverso una traversata gerarchica che deve essere replicata nel sistema di destinazione con una logica di navigazione equivalente. Oppure scoprire che una relazione logica tra due database IMS fisici crea una dipendenza che nessuno dei due database documenta completamente nei rispettivi DBD, e che la migrazione ha convertito entrambi i database in modo indipendente, interrompendo silenziosamente ogni programma che utilizzava tale relazione logica. O ancora scoprire che un database di indice secondario, una struttura che la maggior parte dei piani di migrazione non inventaria mai, era l'unico percorso attraverso il quale un programma di reporting critico accedeva ai propri dati.
Nessuna di queste sorprese resiste al confronto con una rigorosa analisi delle dipendenze pre-migrazione. Resistono invece al confronto con le ipotesi.
Analisi delle dipendenze IMS su scala di portafoglio
SMART TS XL Identifica le dipendenze IMS tra database che sono invisibili nel solo codice sorgente COBOL.
Maggiori InformazioniCosa rende diversa l'analisi delle dipendenze di IMS?
L'analisi delle dipendenze per un ambiente di database relazionale, come DB2, Oracle o SQL Server, segue un percorso ben definito. Si analizza il codice SQL dell'applicazione, si identificano i riferimenti a tabelle e colonne, si crea una mappa che indica quali programmi accedono a quali tabelle e si utilizza tale mappa per determinare l'ambito e la sequenza della migrazione. La struttura è esplicita. Le dipendenze sono visibili nel testo SQL.
L'analisi delle dipendenze IMS è più complessa sotto ogni aspetto.
La struttura è gerarchica, non relazionale. Un database IMS è organizzato come un albero di tipi di segmento, dove ogni tipo di segmento ha una relazione padre-figlio definita. Un programma COBOL che legge i record dei pazienti da un database IMS non viene eseguito SELECT * FROM PATIENTS WHERE ID = ?Il programma effettua una chiamata Get Unique (GU) per navigare nella gerarchia fino al segmento radice, quindi chiama Get Next Within Parent (GNP) per attraversare i figli. La dipendenza del programma non è da una tabella, bensì da un percorso specifico attraverso una struttura gerarchica, e la modifica di tale struttura può causare malfunzionamenti nei programmi che la utilizzano, in modi che nessuna analisi a livello SQL sarebbe in grado di rilevare.
Le dipendenze sono distribuite su tre strutture separate. Per comprendere appieno il funzionamento di un programma COBOL con IMS è necessario analizzare:
- Il DBD (Database Descriptor): definisce la gerarchia del segmento fisico, i campi chiave, i metodi di accesso (HDAM, HIDAM, HISAM, HSAM) e gli eventuali indici secondari o relazioni logiche.
- Il PSB (Program Specification Block): definisce a quali database un programma è consentito accedere, attraverso quali PCB, con quali specifiche di sensibilità e intento
- Il codice sorgente COBOL: contiene le effettive chiamate DL/I che determinano quali segmenti vengono acceduti, con quali funzioni di chiamata, in quale sequenza, con quali SSA
Nessuna singola fonte fornisce un quadro completo. Un'analisi che legge solo il codice sorgente COBOL rileva i tipi di chiamata e i nomi dei segmenti, ma non la struttura fisica del database. Un'analisi che legge solo il DBD e il PSB rileva ciò che il programma è autorizzato a fare, ma non ciò che effettivamente fa.
La navigazione dipende dalla posizione. In un database relazionale, ogni riga è indirizzabile indipendentemente tramite chiave. In IMS, la posizione corrente di un programma nella gerarchia influisce sul valore restituito dalle chiamate successive. Una chiamata GN (Get Next) restituisce il segmento successivo nella sequenza gerarchica a partire dalla posizione corrente del programma. La dipendenza non riguarda solo il tipo di segmento, ma anche il percorso di attraversamento che ha portato alla posizione corrente. I programmi che si basano sull'ordinamento gerarchico implicito di IMS presentano una dipendenza che scompare quando i dati vengono migrati a un database relazionale, dove non è garantito un ordinamento equivalente.
L'inventario delle chiamate DL/I: cosa rivela il codice sorgente COBOL
L'analisi preliminare alla migrazione più utile consiste in un inventario completo di ogni chiamata DL/I in ogni programma COBOL che accede a IMS. Questo inventario indica al team di migrazione cosa fa ciascun programma con IMS, non cosa gli è consentito fare (come definito dal PSB), ma cosa fa effettivamente.
Le chiamate DL/I in COBOL si presentano in due forme:
cobolo
* Form 1: EXEC DLI interface (CICS-compatible, high-level syntax)
EXEC DLI
GU DB2PCB
SEGMENT(CUSTROOT)
WHERE(CUSTID = WS-CUST-ID)
END-EXEC
* Form 2: xxxTDLI call interface (batch programs, assembler-compatible)
CALL 'CBLTDLI' USING WS-FUNCTION-CODE
PCB-CUSTOMER
WS-CUSTOMER-SEGMENT
WS-SSA-CUSTOMEREntrambe le forme contengono le stesse informazioni analitiche: il codice funzione, il PCB utilizzato, il segmento di destinazione e, facoltativamente, l'SSA (Segment Search Argument) che qualifica la chiamata. Un inventario completo delle chiamate DL/I estrae tutte queste informazioni da ogni programma.
La tassonomia dei codici funzione e le sue implicazioni per la migrazione
Il codice funzione DL/I è l'elemento più significativo di ogni chiamata ai fini della migrazione. Ogni codice funzione implica un diverso modello di accesso ai dati che deve essere replicato nel database relazionale di destinazione:
Funzioni di sola lettura: GUOttieni informazioni univoche: naviga direttamente a un segmento utilizzando SSA qualificati. Equivalente a una SELECT con clausola WHERE in termini relazionali. Facile da migrare se la chiave del segmento corrisponde correttamente a una chiave primaria relazionale.
GN, Ottieni successivo: passa al segmento successivo nella sequenza gerarchica. Questo è il codice della funzione che non ha un equivalente relazionale diretto, si basa sullo stato posizionale di IMS e sull'ordinamento implicito. I programmi che utilizzano ampiamente GN richiedono un'attenta analisi dell'ordinamento da cui dipendono.
GNP, Ottieni successivo all'interno del genitore: recupera i figli successivi del segmento genitore corrente. Equivalente al recupero di tutte le righe in una relazione di chiave esterna. Generalmente corrisponde perfettamente a una SELECT con una clausola WHERE di chiave esterna.
Funzioni di blocco (prerequisiti per l'aggiornamento): GHU, GHN, GHNPOttieni gli equivalenti di Hold di GU, GN, GNP. Il flag "hold" indica che seguirà un'operazione di aggiornamento (REPL) o di eliminazione (DLET). I programmi che utilizzano le chiamate hold sono programmi di lettura-modifica-scrittura; la migrazione deve preservare l'integrità transazionale durante l'operazione di hold e il successivo aggiornamento.
Funzioni di aggiornamento: ISRT, Inserisci: aggiunge una nuova occorrenza di segmento. Equivalente a INSERISCI. DLET, Elimina: rimuove il segmento attualmente occupato e tutti i suoi dipendenti. Il comportamento "tutti i dipendenti" è una cascata specifica di IMS che deve essere implementata esplicitamente nel sistema di destinazione. REPL, Sostituisci: aggiorna il segmento attualmente memorizzato con nuovi dati. Equivalente a AGGIORNA.
Perché questo è importante per l'ambito della migrazione: un programma con sole chiamate GU e GNP è un consumatore di dati IMS in sola lettura, con un rischio di migrazione inferiore e una convalida più semplice. Un programma che utilizza GHU, REPL e DLET è un programma di elaborazione delle transazioni che modifica le strutture gerarchiche; la sua migrazione richiede la preservazione dell'integrità transazionale tra le operazioni, un'operazione che IMS attualmente garantisce in modo atomico.
I tre tipi di dipendenza che ostacolano ogni migrazione
Relazioni logiche
Le relazioni logiche di IMS collegano segmenti tra due database fisicamente separati. Un segmento figlio logico nel Database A ha un segmento padre logico nel Database B. Quando un programma COBOL naviga attraverso una relazione logica, percorre un percorso che attraversa fisicamente i confini dei database, un attraversamento che IMS gestisce in modo trasparente ma che scompare quando i database vengono migrati indipendentemente.
Le relazioni logiche rappresentano il tipo di dipendenza a più alto rischio nella migrazione IMS per un motivo: sono invisibili nel codice sorgente COBOL. Il programma COBOL chiama GNP per ottenere i figli di un segmento. Se tale chiamata GNP attraversi una relazione fisica padre-figlio o una relazione logica è determinato dal PSB e dal DBD, non dal codice COBOL. Un team di migrazione che analizza solo il codice sorgente COBOL non ha modo di sapere se una chiamata GNP sta attraversando un confine di relazione logica senza analizzare separatamente il PSB e il DBD.
I programmi che utilizzano relazioni logiche richiedono che la migrazione replichi la semantica della relazione logica nel sistema di destinazione, in genere un JOIN nel modello relazionale, e che verifichi che ogni programma che utilizza la relazione riceva risultati equivalenti dal JOIN a quelli ottenuti dall'attraversamento logico IMS.
Database di indici secondari
I database di indice secondari di IMS forniscono un percorso di accesso alternativo a un database primario, consentendo ai programmi di recuperare segmenti in base a un campo diverso dalla chiave radice. Un database di indice secondario è un database IMS separato con un proprio DBD, ma i suoi dati derivano dal database primario.
I team di migrazione spesso scoprono i database di indicizzazione secondari durante la fase di analisi piuttosto che durante quella di pianificazione, per i seguenti motivi:
- Sono definiti in DBD che non sono sempre raggruppati con i DBD del database primario
- I programmi che utilizzano indici secondari specificano il nome del database dell'indice nei loro PSB, ma i programmi che accedono al database primario tramite un indice secondario potrebbero non renderlo evidente nel codice sorgente COBOL.
- La documentazione può descrivere il database primario senza menzionare i suoi indici secondari.
Un programma che accede a IMS tramite un indice secondario presenta una dipendenza dal modello di accesso che deve essere replicata nel sistema di destinazione come indice non primario o con una diversa strategia di query. La mancata implementazione di questa funzionalità durante la migrazione produce un programma che viene eseguito senza errori ma non riesce a trovare i record che sta cercando.
Database GSMA
I database GSAM (Generalized Sequential Access Method) sono l'interfaccia di IMS per l'elaborazione batch sequenziale, consentendo essenzialmente ai programmi batch COBOL di utilizzare chiamate DL/I per quello che funzionalmente è un I/O di file sequenziale. I database GSAM non hanno gerarchie di segmenti; sono strutture sequenziali piatte a cui si accede tramite IMS per beneficiare delle funzionalità di ripristino e riavvio di IMS.
I programmi che utilizzano i database GSAM sono programmi batch che dipendono dal supporto di checkpoint/riavvio di IMS per il loro comportamento di ripristino. La migrazione deve preservare questo comportamento di ripristino o sostituirlo con un meccanismo equivalente nella piattaforma di destinazione.
Creazione dell'inventario delle dipendenze pre-migratorie
Un'analisi completa delle dipendenze IMS produce sei risultati che, nel loro insieme, definiscono l'ambito, il rischio e la sequenza della migrazione.
Risultato finale 1: Mappatura PCB-database
Ogni PCB in ogni PSB è mappato a uno specifico DBD (uno specifico database IMS). Elencare ogni PCB in tutti i PSB e mappare ciascuno al suo DBD produce l'elenco ufficiale dei programmi autorizzati ad accedere a quali database. Questo è il punto di partenza per comprendere l'ambito di applicazione, ma sovrastima le dipendenze effettive perché i programmi possono avere PSB che includono più database di quelli che effettivamente utilizzano.
Risultato 2: Inventario effettivo delle chiamate per programma
L'analisi delle chiamate DL/I di ogni programma COBOL produce l'elenco di utilizzo effettivo: quali PCB ogni programma chiama effettivamente, quali codici funzione utilizza, a quali tipi di segmento accede e se utilizza SSA qualificati (accesso tramite chiave di segmento) o navigazione non qualificata (attraversamento posizionale). Questo restringe l'ambito dalle autorizzazioni definite dal PSB al comportamento effettivo del programma.
Risultato 3: Mappa di utilizzo delle relazioni logiche
Il confronto incrociato dell'inventario delle chiamate con i DBD (Database Diagrams) permette di identificare quali chiamate GNP o GN dei programmi attraversano relazioni logiche. Ciò richiede l'analisi non solo del codice sorgente COBOL e del PSB (Program Service Block), ma anche delle strutture DBD che definiscono quali relazioni padre-figlio sono fisiche e quali logiche.
Risultato atteso n. 4: Mappa di utilizzo dell'indice secondario
I programmi che specificano database di indici secondari nei loro PSB o che effettuano chiamate con SSA che fanno riferimento a campi chiave non radice vengono identificati come utenti di indici secondari. La mappa documenta quali indici secondari esistono, quali database primari supportano e quali programmi dipendono da essi.
Risultato 5: Distribuzione dei tipi di chiamata per database
Per ciascun database IMS interessato, la distribuzione dei tipi di chiamata tra tutti i programmi che vi accedono indica la complessità della sua migrazione:
- I database accessibili solo tramite funzioni di lettura (GU, GN, GNP) sono più semplici da migrare
- I database a cui si accede tramite funzioni di blocco e aggiornamenti (GHU + REPL, GHN + DLET) richiedono la replica dell'integrità transazionale
- I database con un elevato utilizzo di GN indicano dipendenze di navigazione posizionale che richiedono un'analisi dell'ordinamento
- I database con relazioni logiche richiedono una semantica JOIN tra database nel target
Risultato atteso n. 6: Classificazione del rischio del programma
Utilizzando la distribuzione dei tipi di chiamata e l'inventario dei tipi di dipendenza, ogni programma viene classificato in base al rischio di migrazione:
I programmi che utilizzano solo GU e GNP con SSA qualificati, accedono a un singolo database senza relazioni logiche e non prevedono chiamate di blocco/aggiornamento sono i candidati a minor rischio per le prime fasi di migrazione. I programmi che utilizzano ampiamente GN, accedono a più database tramite relazioni logiche o eseguono sequenze complesse di blocco/aggiornamento sono i programmi a maggior rischio che richiedono un'analisi e una convalida più approfondite prima della migrazione.
Cosa cambia l'analisi in merito alla pianificazione migratoria
L'analisi delle dipendenze non si limita a documentare ciò che esiste, ma modifica le decisioni che ne conseguono.
Decisioni di sequenza. I programmi che condividono database IMS tramite relazioni logiche non possono essere migrati in modo indipendente. Se il programma A legge un segmento figlio logico che ha un genitore logico nello stesso database del segmento radice del programma B, la migrazione di A senza migrare B (o senza creare un bridge) interrompe il funzionamento di A. Il grafico delle dipendenze determina quali programmi devono essere migrati insieme.
Decisioni di progettazione del target. La distribuzione dei tipi di chiamata determina come deve essere strutturato lo schema relazionale di destinazione. Una relazione gerarchica padre-figlio accessibile esclusivamente tramite chiamate GU e GNP qualificate da chiave si traduce in modo pulito in una relazione di chiave esterna nel target. La stessa relazione accessibile tramite chiamate GN con dipendenze posizionali richiede che lo schema di destinazione preservi un ordinamento equivalente, tramite un ORDER BY esplicito, un campo di sequenza o un diverso modello di accesso che raggiunga lo stesso risultato.
Decisioni relative all'ambito di convalida. L'analisi identifica quali programmi sono consumatori di sola lettura dei dati IMS e quali sono processori di transazioni. I programmi di sola lettura possono essere convalidati confrontando i risultati di output tra il sistema IMS originale e il sistema migrato. I processori di transazioni richiedono test di equivalenza transazionale, che garantiscono che la stessa sequenza di operazioni sul sistema di destinazione produca modifiche equivalenti allo stato dei dati rispetto all'originale.
Classificazione del rischio. La relazione logica e i risultati dell'indice secondario sono gli input principali per la classificazione del rischio. Ogni programma di migrazione ha un registro dei rischi. L'analisi delle dipendenze dell'IMS indica al team quali voci inserire.
Come SMART TS XL Esegue l'analisi delle dipendenze IMS
SMART TS XL'S analisi statica del codice Analizza le chiamate DL/I di ogni programma COBOL, sia nelle interfacce di chiamata EXEC DLI che xxxTDLI, estraendo il codice funzione, il riferimento PCB, il nome del segmento e la struttura SSA da ciascuna chiamata. Questo produce l'inventario effettivo delle chiamate a livello di programma, per l'intero portfolio COBOL, senza richiedere un sistema IMS in esecuzione o una revisione manuale del codice.
La mappatura delle dipendenze delle applicazioni estende questo inventario in un grafico delle dipendenze tra programmi: quali programmi condividono l'accesso a quali database IMS, quali programmi utilizzano gli stessi PCB, quali modelli di accesso dei programmi si sovrappongono in modi che richiedono una migrazione coordinata. Quando una relazione logica collega segmenti tra database, la mappa delle dipendenze rappresenta questa connessione tra database come una relazione esplicita che deve essere preservata nel sistema di destinazione.
La funzionalità di analisi dell'impatto risponde alla domanda che ogni team di migrazione deve porsi prima di convertire un database: se questo database IMS viene migrato, quali programmi saranno interessati, quali modelli di accesso dovranno essere replicati e quali casi di test dovranno essere convalidati per confermare l'equivalenza? La risposta non è una stima, bensì un elenco dettagliato derivato dall'inventario effettivo delle chiamate DL/I.
La funzionalità di espansione JCL aggiunge il contesto operativo: quali passaggi del job JCL richiamano quali programmi che accedono a IMS, in quale sequenza e con quali specifiche PSB. La catena di dipendenza operativa, ovvero la sequenza di job batch che elabora i dati IMS attraverso più programmi, è importante per la pianificazione della migrazione tanto quanto i modelli di accesso a livello di programma. Migrare il database senza migrare l'orchestrazione dei job batch che lo circonda produce un sistema che elabora correttamente i record in isolamento ma fallisce in produzione quando viene eseguita la sequenza di job.
Per i team che conducono modernizzazione dell'eredità dei sistemi supportati da IMS, le prove strutturali prodotte da SMART TS XL è l'input per ogni successiva decisione di migrazione: quali programmi migrano in quale ondata, quali database possono essere convertiti indipendentemente e quali richiedono una conversione coordinata, quali modelli di accesso richiedono una riprogettazione piuttosto che una traduzione diretta. Come descritto nel contesto di Migrazione delle strutture IMS e VSAM insieme ai programmi COBOLL'interconnessione tra i programmi COBOL e le strutture dati legacy implica che la migrazione dei dati e l'analisi del codice debbano procedere in parallelo; l'inventario delle dipendenze è il meccanismo che rende possibile la pianificazione parallela.
L'inventario non è la migrazione
L'analisi delle dipendenze IMS produce conoscenza. La migrazione richiede comunque decisioni, progettazione e validazione. Ciò che l'analisi modifica è la qualità delle decisioni, la completezza dell'ambito di progettazione e l'affidabilità della validazione.
Le organizzazioni che migrano con successo i database IMS non sono quelle con le tempistiche più stringenti o i budget di migrazione più elevati. Sono quelle che sapevano esattamente cosa possedevano prima di iniziare la migrazione: ogni programma che accedeva a ciascun database, ogni codice funzione che rivelava il modello di accesso di ciascun programma, ogni relazione logica che creava dipendenze tra database, ogni indice secondario che forniva un percorso di accesso che non sarebbe sopravvissuto alla conversione senza una replica esplicita.
Quella conoscenza non deriva dalla documentazione. Deriva dall'analisi del codice.
