Cos'è il COBOL e perché le banche lo usano ancora

Ogni tanto leggi che "le banche girano su un linguaggio degli anni Cinquanta" e la reazione istintiva è pensare a pigrizia o a dirigenti che non vogliono spendere. La realtà è più interessante, e dice molto su come funziona il software che conta davvero. In questo articolo trovi cos'è il COBOL, perché è così difficile da sostituire e se ha senso impararlo oggi.

Cos'è il COBOL

Il COBOL (COmmon Business-Oriented Language) è un linguaggio nato nel 1959 per scrivere applicazioni gestionali — contabilità, paghe, anagrafiche, movimenti bancari — con una sintassi che imita l'inglese perché doveva poter essere letto anche da chi non programmava.

Fu definito da un comitato di aziende e enti governativi statunitensi, con una forte influenza del lavoro di Grace Hopper sui primi linguaggi "in parole" invece che in simboli matematici. L'obiettivo era esplicito: un programma di contabilità doveva essere leggibile da un revisore o da un responsabile amministrativo, non solo da chi l'aveva scritto.

Si vede subito. Dove in quasi tutti i linguaggi scriveresti totale = prezzo * quantita, in COBOL scrivi:

MULTIPLY PREZZO BY QUANTITA GIVING TOTALE.

Verboso, certo. Ma chiunque, anche senza sapere niente di programmazione, capisce cosa fa quella riga. Negli anni Sessanta era una scelta rivoluzionaria.

Com'è fatto un programma COBOL

Un programma COBOL è diviso in quattro DIVISION, sempre nello stesso ordine, ognuna con un compito preciso. Ecco un calcolo di interessi completo:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. CALCOLA-INTERESSI.

       ENVIRONMENT DIVISION.

       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 WS-SALDO        PIC 9(9)V99  VALUE 1500.00.
       01 WS-TASSO        PIC V9999    VALUE .0125.
       01 WS-INTERESSI    PIC 9(9)V99  VALUE ZERO.
       01 WS-STAMPA       PIC Z(8)9.99.

       PROCEDURE DIVISION.
           MULTIPLY WS-SALDO BY WS-TASSO
               GIVING WS-INTERESSI ROUNDED
           MOVE WS-INTERESSI TO WS-STAMPA
           DISPLAY "INTERESSI: " WS-STAMPA
           STOP RUN.

• IDENTIFICATION DIVISION: il nome del programma e, storicamente, autore e data.
• ENVIRONMENT DIVISION: il collegamento con il mondo esterno — quali file, quali dispositivi. Qui è vuota.
• DATA DIVISION: tutti i dati vanno dichiarati qui, prima di essere usati, con il loro formato esatto.
• PROCEDURE DIVISION: la logica vera e propria.

Il rientro a sinistra non è estetica: il COBOL tradizionale nasce per le schede perforate e ha colonne con significati precisi. I compilatori moderni accettano un formato libero, ma il codice che troverai in banca è quasi sempre in quello fisso.

La riga da guardare con attenzione è PIC 9(9)V99. Significa: nove cifre intere, una virgola implicita (V), due cifre decimali. È il cuore del motivo per cui il COBOL è ancora lì.

L'aritmetica decimale: perché per i soldi conta

Quasi tutti i linguaggi moderni rappresentano i numeri con la virgola in virgola mobile binaria (lo standard IEEE 754). È veloce ed è perfetta per la fisica o la grafica, ma ha un difetto: molti numeri decimali semplici non si possono rappresentare esattamente in binario.

Prova in JavaScript o in Python:

>>> 0.1 + 0.2
0.30000000000000004

Su un'operazione l'errore è invisibile. Su milioni di movimenti al giorno, con interessi, arrotondamenti e ripartizioni, diventa un problema contabile — e in banca un centesimo che non torna è un'anomalia da spiegare.

Il COBOL lavora nativamente in decimale a virgola fissa. Quando dichiari PIC 9(9)V99 il numero è memorizzato come cifre decimali, spesso nel formato "packed decimal" (COMP-3) che i mainframe IBM elaborano direttamente in hardware. 0.1 + 0.2 fa 0.3, sempre, e le regole di arrotondamento sono esplicite (ROUNDED).

Attenzione: non è che gli altri linguaggi non sappiano farlo. Java ha BigDecimal, Python ha decimal, i database hanno NUMERIC. Ma lì è una libreria che devi ricordarti di usare ovunque; in COBOL è il comportamento predefinito. Quando migri, ogni singola operazione deve replicare esattamente arrotondamenti e troncamenti dell'originale — ed è uno dei motivi per cui le migrazioni sono così delicate.

Perché le banche non lo riscrivono

La spiegazione pigra è "costa troppo". Quella vera è che riscrivere è rischiosissimo, e il rischio non è tecnico ma di conoscenza.

Un sistema bancario centrale scritto negli anni Settanta e Ottanta ha accumulato decenni di modifiche: una norma fiscale del 1987, un'eccezione per una categoria di conti, una correzione dopo un contenzioso, una regola introdotta per una fusione. Quelle regole di business vivono dentro il codice, e spesso solo lì. La documentazione, se esisteva, è ferma a vent'anni fa. Chi le ha scritte è andato in pensione.

Riscrivere significa quindi fare archeologia: estrarre ogni regola da milioni di righe, capire se è ancora valida, reimplementarla identica, e dimostrare che il nuovo sistema dà gli stessi risultati al centesimo su ogni caso possibile. Il tutto senza fermare un servizio che non può fermarsi.

I tentativi di migrazione falliti o finiti ben oltre budget e tempi sono il vero motivo per cui il COBOL resiste. Ogni settore ha i suoi casi noti. Nel mondo bancario viene spesso citata la migrazione di TSB nel Regno Unito del 2018: non riguardava specificamente il COBOL, ma il passaggio dell'intero sistema centrale della banca a una nuova piattaforma, e molti clienti per giorni non riuscirono ad accedere ai propri conti (i dettagli sono nei report pubblici: verifica alla fonte). È l'esempio che mostra il rischio vero, che vale per qualsiasi linguaggio: sostituire il cuore di una banca è un'operazione in cui un errore si vede subito, e davanti a tutti. Un dirigente che li conosce fa un calcolo razionale: il sistema attuale funziona, costa mantenerlo, ma sostituirlo può costare la reputazione.

È lo stesso principio che si applica a qualsiasi codice: il refactoring incrementale è quasi sempre più sicuro della grande riscrittura. Le banche lo applicano su scala enorme: invece di buttare il COBOL, lo avvolgono — ci mettono davanti API moderne, spostano pezzi periferici verso nuovi servizi, e lasciano il nucleo dove sta.

Mainframe e batch notturni

Il COBOL vive quasi sempre su un mainframe: macchine progettate per un'affidabilità estrema, capaci di elaborare enormi volumi di transazioni e di restare accese per anni. Il sistema operativo tipico è z/OS di IBM, e l'ambiente ha un vocabolario tutto suo:

Termine	Cos'è
JCL	Il linguaggio con cui si descrivono i "job": quale programma lanciare, con quali file
CICS	Il gestore delle transazioni online, quelle che rispondono subito (es. un prelievo)
DB2	Il database relazionale IBM, interrogato in SQL dal COBOL
VSAM	Un sistema di file indicizzati, più vecchio dei database relazionali

Molto del lavoro avviene nei batch notturni: di notte, a sportelli chiusi, girano le elaborazioni massive — calcolo degli interessi, estratti conto, riconciliazioni, flussi verso altri istituti. Se ti sei chiesto perché un bonifico ordinato alle 22 risulta il giorno dopo, una parte della risposta è qui.

Ha senso impararlo per lavoro?

Qui serve onestà, perché su questo tema circolano parecchi titoli sensazionali.

Il ragionamento di base è corretto: chi conosce bene il COBOL e l'ambiente mainframe sta andando in pensione, pochi giovani lo studiano, e i sistemi non spariranno a breve. Durante la pandemia, alcuni enti pubblici statunitensi fecero appelli pubblici per trovare programmatori COBOL che aggiornassero i sistemi dei sussidi. La domanda esiste.

Ma va detto cosa comporta:

• È una nicchia. Le posizioni sono concentrate in banche, assicurazioni, pubblica amministrazione e nelle società di consulenza che lavorano per loro. Non troverai offerte COBOL in una startup.
• Il lavoro è manutenzione. Correggere, adattare a nuove norme, integrare con sistemi nuovi, analizzare codice scritto da altri decenni fa. Raramente si progetta qualcosa da zero.
• L'ambiente è diverso da tutto il resto. Terminali a schermo verde, editor come ISPF, processi di rilascio lenti e formali, controlli rigidi. Chi arriva da Git e dal deploy continuo si trova in un altro pianeta — anche se strumenti moderni (estensioni per VS Code, pipeline automatizzate) stanno entrando anche lì.
• Sulle retribuzioni, diffida dei numeri sparati. Si legge spesso che "i programmatori COBOL guadagnano tantissimo": vale per profili senior con esperienza specifica, non per chi ha fatto un corso. Per un quadro generale del mercato vedi stipendio sviluppatore in Italia e confronta con annunci reali.

Il percorso più sensato, in Italia, passa spesso dalle società di consulenza che formano internamente neolaureati sul mainframe. Se ti interessa il settore finanziario e cerchi stabilità più che novità tecnologica, è un'opzione concreta. Se vuoi lavorare con strumenti moderni e cambiare progetto spesso, probabilmente no.

Errori comuni su COBOL

Pensare che sia un linguaggio morto. Non se ne scrive molto di nuovo, ma quello esistente viene eseguito ogni giorno e modificato di continuo. Morto non è la parola giusta: è maturo e confinato.

Pensare che basti tradurlo automaticamente. Esistono strumenti che convertono COBOL in Java o C#, e a volte funzionano. Ma spesso producono codice che è COBOL travestito, difficile da mantenere quanto l'originale, e non risolvono il problema delle regole non documentate.

Sottovalutare l'ambiente. Il COBOL in sé si impara in qualche settimana: è semplice e ripetitivo. La parte difficile è tutto il resto — JCL, CICS, DB2, il modo in cui i dati fluiscono tra decine di programmi batch. È quello che rende un profilo davvero spendibile.

Studiarlo come primo linguaggio sperando nel posto sicuro. Ti lascia con basi molto strette. Meglio partire da un linguaggio generalista — anche Java, che nelle stesse banche convive col COBOL — e affiancare il mainframe dopo.

In sintesi

Il COBOL è un linguaggio del 1959 nato per il gestionale, con una sintassi in stile inglese pensata per essere leggibile e un'aritmetica decimale a virgola fissa nativa che per i calcoli sul denaro resta un vantaggio concreto.

Resiste perché riscriverlo è pericoloso, non per pura inerzia. Le regole di business di decenni vivono dentro il codice, spesso senza altra documentazione, e le migrazioni fallite hanno insegnato alle banche a preferire l'integrazione graduale alla sostituzione totale.

Il suo mondo è il mainframe: transazioni online, batch notturni, JCL e DB2, con processi e strumenti molto diversi da quelli dello sviluppo moderno.

Come carriera è una nicchia reale ma stretta: c'è domanda perché mancano persone, il lavoro è soprattutto manutenzione di sistemi legacy, e ha senso se cerchi stabilità nel settore finanziario più che varietà tecnologica.

Per vedere dove si colloca rispetto agli altri linguaggi c'è tutti i linguaggi di programmazione: lì trovi anche le alternative più moderne da affiancare al mainframe.