La majeure partie de ces applications ont un point commun : elles sont gérées via un outillage datant des années 80/90 assurant en priorité le build et le déploiement et de manière beaucoup plus primaire le versionning.

En effet, la gestion de version, quand elle existe, est techniquement réalisée au niveau des composants et non au niveau applicatif. Les sites ne mettent pas en oeuvre la gestion de branches même si, en théorie, cette fonctionnalité est disponible. On ne gère donc pas de version d’application.

Par opposition, les applications du monde « moderne » (Java, .Net, etc…) sont gérées dans des outils assurant un versionning complet de type Git/SVN avec gestion de branches, build automatique, etc… Le point faible actuellement de ce coté est plutot l’aspect déploiement qui est une clé du monde DevOps.

Ce qui est très différent entre les 2 mondes :
– sur mainframe, on ne build et déploie que des composants individuels en mode petit train (une modif avant l’autre, un peu tout le temps – pas de développement en parallèle, pas de version de logiciel).
– sur mainframe, les sources sont stockés en vrac dans des bibliothèques pouvant contenir jusqu’à 40 000 sources. Il est impensable de mettre tout dans un dépot Git et de le cloner sur chaque poste de développeur !

Ceci étant, qu’est-ce qu’il faudrait faire pour mettre mes sources COBOL mainframe sous Git ?

1) Découper la poubelle qui me sert de repository (je plaisante, bien sur) en applications de taille raisonnable, identifier les modules communs et les traiter comme des applications aussi.

2) Etre capable de lancer les procédures de compilation et de transfert mainframe (build and deploy) depuis des postes externes (eclipse et serveur jenkins)

3) Former les développeurs à l’utilisation de Git (c’est pas gagné!)

4) Oublier ISPF pour travailler sous eclipse !

Commençons par le début : le langage COBOL. Ses principales caractéristiques sont qu’il est basique, simple, procédural, facile à appréhender. Les personnes ayant appris l’informatique en faisant du COBOL ont un très bon modèle de ce qu’est un ordinateur car le langage est bâti sur des phrases impératives qui donnent des ordres à la machine (ADD 1 TO …, MOVE A TO B, etc…) qui se transposent facilement en langage machine. Donc, sans le savoir, les programmeurs COBOL connaissent intimement le fonctionnement général des processeurs.

Au dela du COBOL proprement dit, il y a l’environnement de travail. De nos jours, faire du COBOL sous eclipse n’est quasiment plus un sujet (il y a des IDE eclipse fournis par IBM, Metrixware et d’autres…). Il faut cependant aussi savoir utiliser l’interface texte 3270 natif et l’éditeur ISPF. On peut dire que le couple 3270/ISPF est au mainframe ce que Telnet/vi est à Unix : le moyen d’accès de base au système.

Il y a ensuite l’environnement technique : Base de données, sous systèmes transactionnels, le scripting Rexx, le JCL (Job Control language), etc… C’est assez riche et pointu. Ce qu’il faut comprendre, c’est qu’un programme COBOL est comparable à une machine outil dans une usine : une moulinette à données qui doit être capable de traiter des millions d’informations sans mettre le mainframe à genou. Il y a donc derrière tout ça une culture et un savoir faire qui ne s’apprennent pas dans les livres.

Le challenge du développeur : on ne vous a pas attendu pour écrire des programmes COBOL. Il va donc falloir avoir le jus et le talent pour plonger dans des programmes volumineux écrits et maintenus par d’autres… Cette problématique se retrouve maintenant dans tous les langages, on pourrait même dire que lire du COBOL est plutot plus facile que d’essayer de comprendre des applis entièrement objets.

OK, et tout ça mène ou ? Il y a plusieurs voies d’évolution :

• Si vous aimez le fonctionnel, c’est à dire ce à quoi sert l’application, vous pouvez devenir le spécialiste capable d’aller lire les « saintes écritures » pour savoir comment ça marche ce truc. En général, on vous nomme chef de projet pour ça.
• Si vous préférez l’aspect technique, vous pouvez devenir support/expert technique, voire évoluer vers des métiers d’ingéniérie de production qui sont de plus en plus demandés et pour lesquels avoir une expérience du dev est une très bonne idée.

Dans tous les cas, on ne peut que recommander de comprendre quelque chose aux technos Web, voire d’être capable d’exhiber une double-compétence si vous êtes un passionné d’informatique limite obsessionnel…

Après, vous gérez votre vie : vous pouvez rester dans l’expertise ou, pour les courageux, aller vers le management sachant que le risque de mise au rencart anticipée n’est pas une vue de l’esprit.

Les développements Mainframe constituent encore aujourd’hui le socle technologique des Systèmes d’Information des entreprises. Ces applications développées en COBOL, vieilles de plusieurs dizaines d’années, demeurent stratégiques (et même vitales) pour l’activité quotidienne de bon nombre de banques, d’assurances ou encore de grandes industries à travers le monde.

En 2005, Forrester Research estimait le nombre d’applications COBOL à 75% du patrimoine mondial, alors que chaque année, 5 milliards de lignes de code était écrites dans ce langage. Si les chiffres sont toujours discutables et mériteraient une mise à jour, il est certain que le Mainframe n’est pas encore mort, loin de là !

Les raisons de cette survie sont en gros faciles à comprendre :
• Une réécriture complète des applications serait bien trop coûteuse.
• Les migrations (Cobol vers Java, par exemple) ou le changement d’infrastructure cible (ex : rehosting ou downsizing Mainframe vers Unix) sont des projets longs et complexes, même si certaines entreprises ont su se désengager progressivement du Mainframe.
• Le remplacement par des progiciels est tout aussi délicat : difficile d’extraire 30 ans de règles métiers, d’évolution des dispositifs réglementaires, sans prendre le risque d’une corruption des données gérées par le système.
• La fiabilité et la robustesse du Mainframe n’ont finalement jamais été remises en question.

Et pourtant ! un logiciel est un constitué d’un ensemble de programmes informatiques écrits par des être humains, donc bugués (les programmes, pas les êtres humains, quoique). Le Mainframe n’échappe pas à cet règle. Alors, d’où viennent cette fameuse fiabilité et robustesse ? Mythe ou réalité ?

La réponse est multiforme et parfois surprenante. Elle mérite une analyse approfondie sortant du « c’était mieux avant » et du « c’est tout pourri ce truc ». Cette analyse permet de mettre en perspective ce qui se passe aujourd’hui et de mieux situer les problématiques d’architecture logicielle, infrastructures de développement, évolution des métiers, etc…

C’est ce que je me propose de faire dans les prochains billets. A suivre…