Ogni migrazione mainframe comincia con qualcuno che cerca strumenti di migrazione mainframe, e la demo del fornitore che segue appare straordinariamente convincente. Entrano qualche migliaio di righe di COBOL, esce Java leggibile, la suite di test passa e le slide promettono il settanta o l’ottanta per cento di automazione. La demo di solito è onesta. Di solito gira anche su codice che non si comporta per niente come il vostro.

Questa guida descrive le categorie di strumenti che esistono davvero, che cosa ciascuna sa fare bene e i punti precisi in cui ciascuna tende a cedere su carichi di lavoro reali. È scritta per chi deve firmare il business case, non per il sostenitore interno del fornitore.

La posizione onesta: gli strumenti di migrazione mainframe svolgono moltissimo lavoro utile, soprattutto nell’analisi, nello spostamento dei dati e nella traduzione meccanica. Quello che non sanno fare è capire le vostre regole di business. La conversione automatica produce in modo affidabile codice che funziona; non produce codice che il vostro team avrà voglia di manutenere, e colmare quella distanza è dove finisce davvero la maggior parte del budget.

Le quattro categorie di strumenti di migrazione mainframe

Il mercato sembra affollato finché non lo si ordina in base a ciò che i prodotti fanno realmente. Quasi tutto ricade in uno di quattro gruppi, e un programma reale usa strumenti di almeno tre di essi.

Gli strumenti di discovery e analisi leggono il patrimonio sorgente e dicono che cosa c’è. Analizzano COBOL, JCL, copybook e definizioni di database, poi costruiscono grafi delle chiamate, mappe di lineage dei dati e alberi di dipendenze. È la categoria meno appariscente e la più costantemente utile, perché nessuno nell’organizzazione ha un quadro completo di un sistema che si stratifica da quarant’anni.

Le piattaforme di rehosting ed emulazione permettono ai carichi mainframe compilati di girare su hardware standard o su istanze cloud. Il COBOL resta COBOL, il JCL resta JCL, e uno strato di compatibilità fornisce i servizi di runtime che prima dava il mainframe.

Gli strumenti di traduzione automatica convertono il codice sorgente da COBOL a Java, C# o un altro linguaggio moderno. È la categoria che entusiasma di più i compratori e quella che delude più spesso, per le ragioni esposte più avanti.

Gli strumenti di migrazione dati spostano i dati veri e propri: file VSAM, dataset sequenziali e tabelle DB2 verso storage relazionale o cloud nativo. Gestiscono la conversione dei set di caratteri, i campi decimali impacchettati e i tracciati record che i prodotti ETL generalisti semplicemente non riescono a interpretare.

I grandi provider cloud ne impacchettano ciascuno diversi insieme, e i fornitori specializzati si sono consolidati molto per acquisizioni negli ultimi anni. Prima di firmare un contratto di supporto pluriennale, verificate di chi è oggi il prodotto e quanto è vincolante la sua roadmap, perché in questo mercato la proprietà cambia più spesso della tecnologia.

Che cosa fanno davvero bene gli strumenti di analisi

Se comprate una sola categoria, comprate questa. Gli strumenti di discovery rispondono a domande che altrimenti richiederebbero a una squadra di consulenti diversi mesi di lavoro manuale.

Un buon prodotto di analisi vi dirà quali programmi vengono effettivamente invocati in produzione e quali sono morti da un decennio, come un dato scorre da un campo a video fino a una tabella DB2 attraversando una mezza dozzina di programmi, quali copybook sono condivisi tra sottosistemi e dove si trova il codice davvero pericoloso. È quest’ultimo risultato a cambiare i piani. Ogni patrimonio mainframe contiene una manciata di programmi da cui dipende tutto il resto, e raramente sono quelli che il business immagina.

Il limite è l’interpretazione. Un grafo di dipendenze con quarantamila nodi è un insieme di dati, non una comprensione. Qualcuno deve comunque guardare l’output, raggrupparlo in capacità di business e decidere che cosa si sposta per primo. Gli strumenti che promettono di dedurre automaticamente le regole di business producono qualcosa di più vicino a una parafrasi del codice che a una descrizione dell’intenzione, e le due divergono esattamente dove il codice contiene un difetto a cui l’azienda si è silenziosamente adattata.

Fate l’analisi prima di impegnarvi su un approccio. La nostra guida alla strategia di modernizzazione mainframe spiega come quei risultati dovrebbero orientare la scelta tra rewrite, refactor e replatform.

Piattaforme di rehosting: veloci, reali e non una modernizzazione

Il rehosting è l’opzione più prevedibile disponibile, e proprio per questo viene cronicamente sottovalutato.

La proposta è semplice. Il vostro COBOL viene ricompilato o interpretato su una piattaforma che emula i servizi di runtime del mainframe, così che elaborazione transazionale, schedulazione batch, gestione dei file e controllo dei job continuino a comportarsi come prima. Poiché il sorgente cambia appena, il carico di test è molto più basso di qualunque altra strada, e i progetti si chiudono in mesi anziché in anni.

Il risparmio è reale e nasce dal modello hardware e di licenza, non dal software. Le organizzazioni riferiscono spesso riduzioni sostanziali dei costi annuali di esercizio dopo l’uscita dal mainframe fisico, e questo basta spesso a finanziare la fase successiva del lavoro.

Quello che il rehosting non risolve è esattamente il motivo per cui la maggior parte dei consigli approva questi programmi. Dopo un rehost riuscito avete ancora una base di codice COBOL, avete ancora bisogno di sviluppatori COBOL e la vostra capacità di assumerli non è migliorata. Nulla dell’applicazione è diventato più facile da modificare. Il rehosting compra tempo e liquidità, cosa che ha un valore reale, ma andrebbe descritto onestamente come un cambio di piattaforma e non come una modernizzazione.

Introduce anche una nuova dipendenza. Avete scambiato il runtime di IBM con lo strato di compatibilità di un fornitore, e la vostra produzione ora dipende dal fatto che quel fornitore continui a supportarlo. Vista la consolidazione di questo mercato, è un rischio che vale la pena scrivere nel business case.

Traduzione automatica: dove abitano i guai veri

La conversione automatica del COBOL funziona. Non è quello il problema. Il problema è come appare l’output e quanto costa conviverci.

I motori di traduzione sono in genere fedeli. Preservano il comportamento, compreso quello che nessuno voleva, perché la fedeltà è l’unico obiettivo di progetto difendibile. Uno strumento non può sapere che una certa stranezza di arrotondamento nel calcolo di un premio è un difetto che gli attuari compensano dal 1997, quindi lo riproduce esattamente. È la scelta corretta, e significa che il vostro nuovo sistema Java eredita ogni bizzarria accumulata dal vecchio.

L’output è plasmato anche dall’input. Il COBOL scritto con catene di GOTO, concatenazioni PERFORM THRU, istruzioni ALTER e paragrafi in cui si entra da più direzioni non si scompone in metodi puliti, perché non c’è nessuna scomposizione pulita da trovare. Quello che ne esce è Java o C# che segue il flusso di controllo del COBOL, ne riusa i nomi delle variabili ed è spesso più difficile da leggere dell’originale. Chi lavora sul campo lo chiama JOBOL, ed è del tutto possibile completare una migrazione con successo e ritrovarsi con una base di codice che nessuno sa manutenere in nessuna delle due lingue.

Alcuni costrutti specifici causano un dolore sproporzionato, e conviene cercarli presto perché sono quelli che determinano la stima dello sforzo manuale.

I cinque costrutti che determinano lo sforzo manuale

L’aritmetica decimale impacchettata è il primo. I campi COMP-3 del COBOL e la sua semantica decimale a virgola fissa non si mappano sul virgola mobile, e qualunque strumento lo consenta produrrà risultati finanziari che differiscono da quelli del mainframe alla quarta cifra decimale. Le conversioni corrette usano tipi decimali a precisione arbitraria, più lenti, e vanno applicate in modo coerente su ogni percorso di calcolo.

La codifica dei caratteri è il secondo. La conversione da EBCDIC ad ASCII è meccanica, ma la sequenza di collazione non è la stessa, quindi tutto ciò che dipende dall’ordinamento può cambiare. I report escono in un ordine diverso, i controlli di intervallo si comportano diversamente e i confronti tra chiavi danno risultati corretti nel nuovo sistema e sbagliati rispetto al vecchio.

REDEFINES e i record a varianti sono il terzo. Una singola area di memoria interpretata in più modi non ha un equivalente naturale in un linguaggio fortemente tipizzato. Il codice generato tende a produrre manipolazione di array di byte avvolta in accessori, cosa che funziona ed è profondamente sgradevole da manutenere.

La semantica transazionale è il quarto. La programmazione pseudo-conversazionale di CICS, in cui lo stato viaggia in un’area di comunicazione tra un’interazione a video e l’altra, non corrisponde ad alcun pattern web o a servizi moderno. Emularla produce qualcosa di strano; riprogettarla per bene equivale a riscrivere lo strato di presentazione.

Le routine Assembler sono il quinto e il più regolarmente sottostimato. Quasi ogni patrimonio di lunga vita contiene una manciata di moduli Assembler, di solito scritti da qualcuno andato in pensione anni fa, che fanno qualcosa di critico per le prestazioni o specifico della piattaforma. Nessuno strumento li converte. Si riscrivono a mano, partendo dal comportamento osservato, sotto test.

Se state valutando i linguaggi di destinazione, le nostre guide dettagliate alla migrazione da COBOL a Java e alla migrazione da COBOL a C# mostrano come questi costrutti atterrano in ciascun ecosistema.

Strumenti di migrazione dati e i dettagli che mordono

Lo spostamento dei dati riceve meno attenzione della conversione del codice e causa almeno altrettanti ritardi.

Gli strumenti specializzati si guadagnano qui il loro posto, perché i formati dati del mainframe sono davvero scomodi. Conoscono i tracciati dei copybook, i campi decimali impacchettati e zonati, le sovraperforazioni di segno, le clausole OCCURS DEPENDING ON e il fatto che un singolo file VSAM può contenere più tipi di record distinti da un byte in posizione dodici. I prodotti ETL generalisti non li conoscono, e i team che provano a piegarli allo scopo di solito ricostruiscono una versione peggiore della stessa capacità.

Il problema più difficile è semantico, non tecnico. I file mainframe codificano spesso significato in modi che uno schema relazionale non può esprimere direttamente: campi filler riutilizzati per altro, date memorizzate come interi a sei cifre con una regola di windowing, indicatori di stato i cui valori validi vivono in un programma invece che in una tabella di lookup, e chiavi duplicate che l’applicazione tollera. Decidere che cosa debba diventare ciascuno di questi nello schema di destinazione è lavoro di analisi, e non si automatizza, perché le risposte esistono solo nella testa delle persone.

Pianificate la riconciliazione fin dall’inizio. Ogni dataset migrato richiede conteggi dei record, totali di controllo e confronto campo per campo con la sorgente, eseguiti ripetutamente e non una volta sola. La maggior parte dei programmi ha bisogno anche di un periodo di esercizio parallelo, in cui i due sistemi elaborano gli stessi input e gli output vengono confrontati byte per byte finché le differenze non sono eliminate o spiegate. Quel banco di confronto è software vero con un proprio costo di sviluppo, e appartiene al piano anziché alla riserva per imprevisti.

Come scegliere strumenti di migrazione mainframe senza pentirsene

Alcuni principi tengono con i piedi per terra queste decisioni.

Pretendete una prova di concetto sul vostro codice peggiore, non sul campione del fornitore. Scegliete il modulo che tutti evitano, quello con la chiamata Assembler e il REDEFINES a sette livelli, e chiedete che venga convertito. Il risultato dice più di qualunque cliente di riferimento.

Chiedete in modo specifico come lo strumento tratta l’aritmetica decimale e l’ordinamento, e chiedete di vedere il codice prodotto invece di un riassunto. Se il fornitore non riesce a mostrarvi codice leggibile a partire da un input brutto, date per scontato che la stima della rilavorazione manuale sia più grande di quella dichiarata.

Trattate le percentuali di automazione come una misura di righe, non di sforzo. Uno strumento che converte il novanta per cento delle istruzioni può comunque lasciarvi il dieci per cento che contiene tutto il rischio, e quel dieci per cento consuma abitualmente più della metà del calendario.

Infine, mettete a budget le parti che nessuno strumento tocca: l’impianto di test, la riconciliazione, l’esercizio parallelo, i runbook operativi e la riqualificazione delle persone. La nostra guida a costi e tempi della migrazione COBOL illustra come queste voci si distribuiscono di solito su un programma.

Chiedete una lettura indipendente prima di impegnarvi

Mecanik lavora su programmi di migrazione di mainframe legacy e di migrazione COBOL come ingegneri e non come rivenditori di strumenti, il che significa che non abbiamo alcuna provvigione legata alla piattaforma che sceglierete. Facciamo la discovery, convertiamo a mano e con lo strumento un modulo davvero difficile e vi mostriamo la differenza prima che qualcuno firmi qualcosa.

Se il vostro patrimonio è più piccolo o la vostra domanda riguarda più il linguaggio di destinazione che gli strumenti, le pagine del nostro servizio di modernizzazione COBOL spiegano come definiamo il perimetro di quel lavoro. In entrambi i casi, il primo passo utile è una breve conversazione su che cosa c’è davvero nella vostra base di codice, perché la risposta alla domanda sugli strumenti dipende interamente da quello.

Post correlati: Migrazione da COBOL a Python , Migrazione da COBOL a Go: guida per le aziende UK e Migrazione da COBOL a Rust - Guida per aziende UK ., Modernizzazione COBOL: come scegliere il fornitore

Domande frequenti

Gli strumenti di migrazione mainframe possono automatizzare tutto il progetto? No. La traduzione automatica converte di solito la grande maggioranza delle istruzioni, ma il resto contiene moduli Assembler, gestione dello stato transazionale, strutture di record a varianti e regole di business non documentate che richiedono lavoro manuale. Test, riconciliazione ed esercizio parallelo non dipendono comunque dal livello di automazione raggiunto.

È meglio il rehosting o la conversione automatica del codice? Risolvono problemi diversi. Il rehosting toglie rapidamente il carico dall’hardware mainframe e riduce i costi di esercizio, ma vi lascia con il COBOL. La conversione del codice cambia linguaggio e bacino di assunzione, a costi e rischi molto più alti. Molte organizzazioni fanno prima il rehosting per finanziare poi una conversione a fasi.

Perché il codice COBOL convertito è così illeggibile? I motori di traduzione preservano fedelmente il comportamento, compresi flusso di controllo, nomenclatura e strutture dati del COBOL. Il codice costruito su catene di GOTO e aree di memoria condivise non ha un equivalente pulito in Java o C#, quindi l’output rispecchia la struttura originale. Per ottenere codice manutenibile serve un refactoring umano dopo la conversione.

Quali problemi sui dati sfuggono agli strumenti di migrazione mainframe? Gestiscono bene la conversione di formato ma non possono risolvere il significato. Campi filler riutilizzati, date a sei cifre con regole di windowing, codici di stato definiti solo dentro i programmi e chiavi duplicate tollerate richiedono tutti decisioni umane prima che uno schema di destinazione possa essere progettato correttamente.

Come verifico che un sistema migrato si comporti in modo identico? Fate girare entrambi i sistemi sugli stessi input di produzione per un periodo definito e confrontate gli output campo per campo, con il supporto di conteggi dei record e totali di controllo per ogni dataset migrato. Costruite quel banco di confronto come un deliverable a sé stante, perché le differenze emergono di continuo e non tutte insieme.