Software Defined Mainframe

[image error]

Appena laureato, ebbi a che fare con il mainframe di Poste Italiane: fu un’esperienza bella e formativa. Debbo dire che, dal punto di vista tecnico e umano, quella strana comunità di tecnici e sistemisti, dal grande cuore e competenza e dal turpiloquio facile, mi insegnò tantissimo.

Proprio quell’esperienza ha dato origine al mio rapporto di amore e odio con il “computerone” IBM… Da una parte lo considero una gran macchina, un monumento all’intelligenza informatica, dall’altra lo vedo come una zavorra, che limita diverse evoluzioni tecnologiche.

Ogni tanto si presentava il consulentone di turno: in quell’occasione ci radunavano tutti in una lussuosa sala riunione, con poltrone in pelle umana e tavolo presidenziale in mogano, dove il suddetto consulentone, con decine e decine di slides, dotte disquisizioni sulla curva dei MIPS e complessi business plan, ci evangelizzava sulla necessità di eseguire il rehosting del mainframe su tecnologie più o meno esotiche.

Discussione che però terminava sempre allo stesso modo: il sistemista anziano alzava il ditino e faceva la solita, tragicomica domanda:

“Dottò, che ce famo cor COBOL?”

I mainframe,purtroppo, stando in giro dagli anni Sessanta, si portano dietro quantità industriali di vecchie applicazioni, scritte male, prive di documentazione, il cui programmatore spesso si è dato alla macchia o alla sua veneranda età o si è scordato tutto o non vuole essere disturbato da estranei.

A peggiorare il tutto, i tradizionali strumenti di migrazione software-based presentano la necessità di ricompilare il codice COBOL in modo da poter operare su altri sistemi, come Linux, il che, in queste condizioni, traduce il tutto in un bagno di sangue.

Per cui, dinanzi a tale quesito, il consulentone fuggiva a gambe levate. Però dopo circa una ventina d’anni, questa domanda ha una risposta sensata: LzLabs. Questa società svizzera, ha di fatto tirato fuori il coniglio dal cilindro, con il cosiddetto Software Defined Mainframe.

La società tigurina ha sviluppato un container Linux che fornisce alle imprese un modo efficace per migrare le applicazioni dai mainframe verso un private cloud oppure su public cloud MS Azure… In futuro, probabilmente, la soluzione potrà essere implementata anche su AWS o su Google Cloud Platform.

Rispetto alle soluzioni del passato, questa consente ai programmi mainframe eseguibili di funzionare senza cambiamenti e di scrivere e leggere i dati nei loro formati nativi, per cui, il nuovo ambiente funziona senza necessitare ricompilazioni dei programmi applicativi COBOL o PL/1, cosa che riduce notevolmente il tasso di esaurimento nervoso di sistemisti, architect e programmatori. Il tutto ha due simpatici effetti collaterali: il primo è che tutte le competenze e i processi aziendali consolidati nel tempo non sono per nulla intaccati. ll secondo è quando i programmi legacy sono inseriti nel container

vengono potenziati per funzionare su computer moderni e le vecchie API sono sostituite, incrementandone le prestazioni.

Quindi, abbiamo la trovato la pietra filosofale del rehosting ? Da domani IBM può buttare i mainframe e dedicarsi anima e corpo a Watson ? Ni, perché sui mainframe moderni non gira solo roba COBOL, ma tanti altri programmi e applicazioni: nel passaggio da z/OS a Linux, questi dovranno essere sostituiti dalle versioni che girano nel nuovo sistema operativo, oppure con qualcosa d’altro che faccia lo stesso mestiere: ad esempio il buon vecchio DB2 sarà sostituito da PostgreSQL. Per fare questo, in modo che tutto funzioni, serve un periodo di studio, analisi e migrazione lungo e complesso, che potrebbe durare anche un paio d’anni.

Ultima curiosità: nel passaggio tra Mainframe e Ambiente Linux, come deve essere dimensionato l’hardware di destinazione ? Considerando come riferimento gli Intel Xeon Gold Processor Skylake-SP, la relazione è pari a 8 core per 300 Mips…