Modernizzazione Cobol
La parola modernizzazione si presta ad interpretazioni ambigue, nel caso che il costrutto mentale applicato
inizi dalla fine del processo ovvero dal risultato di una qualche trasformazione.
In questo modo l'analisi delle caratteristiche pre-esistenti e le rispettive proprietà di aggiornamento si perdono nella generale conclusione di vetustà.
Così, la modernizzazione dei programmi Cobol porta inevitabilmente al concetto di sostituzione integrale del linguaggio, in questo supportata da un qualche convertitore automatico.
E questo, in buona sostanza, porta alla variazione della piattaforma hardware e software, e quindi impatta tutte le componenti dei costi di produzione, inclusi quello più importante, ovvero l’acculturamento degli addetti.
In tutta generalità, quindi, la riduzione significativa dei costi non è un effetto né immediato né scontato.
Sui primi 20 link ottenuti dalla ricerca Cobol Modernization via Google otteniamo almeno 15 siti che propongono il passaggio a Java, ma anche a C/C++/C#, quasi tutti includendo espliciti richiami a linguaggi e tecnologie Web, e mettendo a disposizione il corredo per disegnare nuove architetture.
Tali siti, in verità non sempre aggiornati alla data, evidenziano casi di studio e referenze molto complesse, ovviamente con pochi dettagli.
Al tecnico, sebbene colga un generale ottimismo di presentazione di tali proposte, non sfugge la percezione che questi casi siano stati non facili perché abbiano richieste analisi e scelte discrezionali da integrare con l’output del convertitore.
Altri siti, invece, partono proprio dal cambio di architettura, più che di tecnologia, e in ciò consiste il contenuto prevalente della modernizzazione offerta.
Se però restringiamo le nostre osservazioni al caso pragmatico in cui al responsabile di servizi Z/OS in produzione basati su soluzioni Cobol, siano poste le seguenti problematiche di manutenzione:
1. comprendere le funzionalità del codice (algoritmi + dati) in produzione, scarsamente documentato, e ricostruirne la logica nel caso in cui si debbano spiegare risultati imprevisti o errori;
2. rispondere sulla possibilità di apportare modifiche a fronte di richieste di business e/o miglioramenti gestionali in un contesto di mantenimento dei costi;
3. correggere vere e proprie evidenti limitazioni funzionali e di disegno,
concludiamo che non solo la migrazione del programma ad una nuova copia basata su Java, non è la soluzione, ma anche che una tale modernizzazione, ammesso che sia da considerare, è sistematicamente rinviata in là nel tempo dalle esigenze di manutenzione.
Sembra dunque che manutenzione e modernizzazione si escludano, e poiché l’erogazione dei servizi di produzione è sempre prioritaria, nessuna modernizzazione sia realisticamente perseguibile.
Lo scopo di questo approfondimento è quello di ipotizzare un percorso di interventi sui programmi Cobol che introduca graduali elementi di modernizzazione senza lasciare la presa della manutenzione ed utilizzando il knowhow Cobol dei manutentori per far evolvere i programmi.
Non volendo costruire un sistema ma solo una serie di osservazioni ed interventi il più possibile verificabili, occorre precisare che ci restringiamo esclusivamente ad impianti Cobol su Z/OS, e che il nostro percorso, quindi, segue le linee di innovazione affermate da IBM per tale linguaggio ed il contesto dei sottosistemi che lo includono, CICS prima di tutto.
In questo modo l'analisi delle caratteristiche pre-esistenti e le rispettive proprietà di aggiornamento si perdono nella generale conclusione di vetustà.
Così, la modernizzazione dei programmi Cobol porta inevitabilmente al concetto di sostituzione integrale del linguaggio, in questo supportata da un qualche convertitore automatico.
E questo, in buona sostanza, porta alla variazione della piattaforma hardware e software, e quindi impatta tutte le componenti dei costi di produzione, inclusi quello più importante, ovvero l’acculturamento degli addetti.
In tutta generalità, quindi, la riduzione significativa dei costi non è un effetto né immediato né scontato.
Sui primi 20 link ottenuti dalla ricerca Cobol Modernization via Google otteniamo almeno 15 siti che propongono il passaggio a Java, ma anche a C/C++/C#, quasi tutti includendo espliciti richiami a linguaggi e tecnologie Web, e mettendo a disposizione il corredo per disegnare nuove architetture.
Tali siti, in verità non sempre aggiornati alla data, evidenziano casi di studio e referenze molto complesse, ovviamente con pochi dettagli.
Al tecnico, sebbene colga un generale ottimismo di presentazione di tali proposte, non sfugge la percezione che questi casi siano stati non facili perché abbiano richieste analisi e scelte discrezionali da integrare con l’output del convertitore.
Altri siti, invece, partono proprio dal cambio di architettura, più che di tecnologia, e in ciò consiste il contenuto prevalente della modernizzazione offerta.
Se però restringiamo le nostre osservazioni al caso pragmatico in cui al responsabile di servizi Z/OS in produzione basati su soluzioni Cobol, siano poste le seguenti problematiche di manutenzione:
1. comprendere le funzionalità del codice (algoritmi + dati) in produzione, scarsamente documentato, e ricostruirne la logica nel caso in cui si debbano spiegare risultati imprevisti o errori;
2. rispondere sulla possibilità di apportare modifiche a fronte di richieste di business e/o miglioramenti gestionali in un contesto di mantenimento dei costi;
3. correggere vere e proprie evidenti limitazioni funzionali e di disegno,
concludiamo che non solo la migrazione del programma ad una nuova copia basata su Java, non è la soluzione, ma anche che una tale modernizzazione, ammesso che sia da considerare, è sistematicamente rinviata in là nel tempo dalle esigenze di manutenzione.
Sembra dunque che manutenzione e modernizzazione si escludano, e poiché l’erogazione dei servizi di produzione è sempre prioritaria, nessuna modernizzazione sia realisticamente perseguibile.
Lo scopo di questo approfondimento è quello di ipotizzare un percorso di interventi sui programmi Cobol che introduca graduali elementi di modernizzazione senza lasciare la presa della manutenzione ed utilizzando il knowhow Cobol dei manutentori per far evolvere i programmi.
Non volendo costruire un sistema ma solo una serie di osservazioni ed interventi il più possibile verificabili, occorre precisare che ci restringiamo esclusivamente ad impianti Cobol su Z/OS, e che il nostro percorso, quindi, segue le linee di innovazione affermate da IBM per tale linguaggio ed il contesto dei sottosistemi che lo includono, CICS prima di tutto.