Depuis le tout début du projet, nous avons décidé de donner la possibilité à nos utilisateurs de faire les montées de version client et les montées de version serveur indépendamment. ils ont ainsi tout leur temps pour faire évoluer les postes client, valider une nouvelle version serveur, la mettre en ligne pour quelques utilisateurs bien choisis, bref, tout que ce qui rend la vie Devops meilleure…

Comment avons-nous fait, me direz-vous ?

Eh bien, nous nous sommes appuyés sur ce que l’on appelle la compatibilité ascendante (concept bien connu de nos amis d’IBM car ils se sont engagés la dessus dans les années 60 quand ils ont conçus l’architecture mainframe)

compatibilité ascendante ? il s’agit en fait de compatibilité ascendante ET descendante (cf. https://fr.wikipedia.org/wiki/Compatibilit%C3%A9_ascendante_et_descendante)

Définissons la compatibilité descendante :
Le nouveau serveur est compatible avec la version cliente précédente
Le nouveau client est compatible avec la version serveur précédente

Compatibilité ascendante :
l’ancien client est compatible avec la nouvelle version serveur
l’ancienne version serveur est compatible avec la nouvelle version client

En fait, c’est quand on développe une nouvelle version qu’il faut se poser la question. (Je connais des développeurs qui se sont fait des noeuds au cerveau avec ça, lol)

Pourtant, ce n’est pas si compliqué que ça finalement, il faut juste faire un peu attention.

1er point / connaitre la version de l’autre composant :
Le serveur annonce au client son niveau de version lors de la connection.
Le client annonce son niveau de version lorsqu’il envoie une requête au serveur (toutes les requêtes sont donc marquées avec la version du client).

2eme point / s’adapter à la version du partenaire :
La, c’est un peu plus compliqué car on ne peut pas faire n’importe quoi.
D’après ce que l’on a dit précédemment , il y’aurait 4 cas. Voyons voir ça de plus près :
– coté client :
Si j’ai en face de moi un serveur plus ancien, je dois adapter certaines de mes requêtes pour être conforme au format attendu et masquer dans l’interface les fonctionnalités non disponibles coté serveur.
Si le serveur est à la dernière version, nous avons la même version , tout va bien.
Si le serveur est à une version supérieure, c’est son problème, pas le mien.
– coté serveur :
Si j’ai en face de moi un client plus ancien, il faut que je continue à traiter ses requêtes « à l’ancienne » pour respecter la version précédente du protocole applicatif.
Si le client est à la même version, tout va bien.
Si le client est à une version supérieure, c’est à lui de faire attention, ce n’est pas mon problème.

Ben, il n’y a que 2 cas finalement – ou il y en 6 – ? Ce que l’on remarque, c’est que la compatibilité ascendante est assurée par la compatibilité descendante du partenaire – je vous laisse y réfléchir – Il n’y a donc effectivement que 2 cas à prendre en compte.

Pour Cobos, nous avons fait un choix basé sur des principes simples (mais contraignants):
– nous supportons 2 versions majeures (version courante et version précédente)
– nous garantissons que la version courante sera supportée par la version suivante (je redis exactement la phrase précédente mais c’est mieux si c’est écrit)
– il n’y a donc pas de changement de protocole applicatif entre 2 versions majeures, nos API doivent de ce fait être bien conçues pour être les plus stables possibles – ne pas hésiter à prévoir un peu trop large au départ, c’est tout un art… -.

et voila !

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.

Cobos est un IDE eclipse dédié au développement COBOL. Il s’intègre naturellement avec toute GCL accessible depuis des plug-ins eclipse OpenSource tels que CVS, SVN, Git ou propriétaires comme Dimension, Endevor ou ClearCase.

Ceci étant, les sites mainframe n’ont pas attendu eclipse pour mettre en place une GCL et disposent d’un outillage accessible sous ISPF bien rodé qu’ils ne souhaitent par remettre en cause (et pourtant, il y aurait long à dire sur ce sujet…).

Cet outillage date généralement des années 80 et recouvre les fonctionnalités de gestion des versions, génération d’exécutables, gestion d’environnements (au minimum test, recette et production), etc… – on parle maintenant d’ALM (Versioning, Build, Deploiement) –

Bien évidement, dès que l’on installe Cobos, la question de l’intégration avec la GCL existante est posée.
– Si le client souhaite acquérir les plugins correspondants à son outil, la cause est entendue (enfin presque…).
– Si ce n’est pas le cas (et c’est le plus fréquent), il va falloir intégrer Cobos avec les procédures existantes. Chance ! Cobos a été conçu pour s’adapter aux différents us et coutumes des sites mainframe.

L’interface de Commandes de Cobos permet de configurer des scripts et/ou des JOBs mainframe à lancer depuis eclipse. Cobos peut uploader un source avant de lancer une commande, générer et soumettre un JCL, etc…
Le lancement se fait depuis un formulaire dont les champs peuvent être automatiquement remplis selon le contexte de travail (à partir des propriétés du source en cours d’édition par exemple).
En fin de traitement sur le mainframe, Cobos récupère et traite les résultats (affichage de messages, ouverture d’un source dans l’éditeur, affichage d’une SYSOUT)

Il est dès lors très simple d’implémenter le Check-out et le Check-in de votre GCL favorite, que celle-ci soit un développement spécifique ou basée sur des outils du marché tels que ENDEVOR, SCLM, LCM, etc… Il est bien sur conseillé à chaque fois que possible de réutiliser les procédures existantes en les adaptants pour qu’elles fonctionnent avec Cobos.

Cette facilité démontre la capacité de personnalisation de Cobos et son adaptabilité à tous les types d’organisation.

Pour aller plus loin:
– Une solution d’intégration plus poussée est possible avec le plug-in Z/Navigator via une exit routine.
– Pour réaliser une intégration complète, un plug-in spécifique a été developpé pour un client utilisant LCM.

Contrairement aux idées reçues, les développements Mainframe constituent encore aujourd’hui le socle technologique de la majorité des entreprises. Au cœur des SI, ces usines logicielles sont un axe stratégique pour l’activité de bon nombre de banques, assurances et grandes industries mondiales.

Paradoxalement, le langage COBOL, à l’origine des développements Mainframe, manque cruellement d’attractivité.

Bien que de nombreuses entreprises aient programmées sur 2012 un projet d’évolution de leur patrimoine COBOL, elles peinent cependant à trouver des cobolistes. Le renouvellement des compétences Mainframe est en effet très limité, ce qui amplifie un phénomène de fond : la raréfaction des développeurs COBOL. Cette carence s’accentue par une vague massive de départ à la retraite programmée sur les 10 prochaines années associée à une forte volonté des grands éditeurs et intégrateurs de gérer à leurs profits cette raréfaction. Au final, il s’agit bel et bien d’un risque énorme pour les entreprises de perdre leur capital et savoir-faire métier, sans pouvoir assurer la relève.

Le langage n’est pas le principal problème

Dans un contexte de crise économique, on pourrait penser qu’il est facile de trouver des candidats disponibles pour les postes de développeur mainframe. Malheureusement, il n’en est rien. En effet, le langage COBOL n’est pas attractif comparé aux langages modernes. Les applications cibles ne sont pas « sexy » notamment parce que la couche de présentation graphique n’est pas développée en COBOL.
Autre phénomène : il n’est pas évident de se mettre en avant lors d’une soirée devant les copains quand on programme en COBOL ! Il est même difficile d’expliquer que la majeure partie du business des entreprises est programmée dans ce langage.
Ceci étant, le langage COBOL est procédural, facile à appréhender et ne constitue pas à lui tout seul le point de blocage quant à l’embauche de jeunes développeurs.

L’environnement de développement : la double peine

L’accès à l’environnement de développement mainframe natif (ISPF) se fait via des émulateurs 3270 en mode caractère. L’outil de travail numéro 1 du développeur étant l’éditeur de texte, les développeurs mainframe passent le plus clair de leur temps dans l’éditeur ISPF datant des années 70 !
Lors de leur formation, les stagiaires considèrent l’accès au mainframe en 3270 comme une sorte de minitel antédiluvien. Certains d’entre eux abandonnent purement et simplement lorsqu’ils comprennent qu’ils vont passer leurs journées dans un tel environnement.
Cet outillage est clairement un frein pour le recrutement de jeunes talents et constitue un filtre de sélection naturelle retenant certes les plus motivés mais pas forcément les plus talentueux…
La comparaison entre l’interface 3270 et les interfaces graphiques modernes est tellement désavantageuse pour le 3270 qu’il ne faut pas espérer que les jeunes recrues deviennent des experts dans l’utilisation d’ISPF…même en Inde !. Leur efficacité dans un tel environnement restera donc très limitée pour la plupart d’entre eux.

La solution : Eclipse

Par quels outils remplacer l’outillage traditionnel sous ISPF ? Il n’y a désormais plus beaucoup de questions à se poser : Eclipse est devenu un standard de fait dans l’environnement mainframe.
Eclipse fournit en effet un cadre permettant de développer des outils de développement intégrés largement utilisés dans le monde Java (Eclipse, lui-même, est développé en Java). Faire profiter les développeurs COBOL de cette infrastructure présente plusieurs avantages :
– environnement moderne, intégré, attractif pour les jeunes développeurs
– fonctionnalités ouvertes sous forme de plug-ins
– rapprochement des développeurs Java et COBOL
– bénéficie d’une forte communauté, dynamique, active et internationale
Etant largement utilisé dans le monde Java, Eclipse dispose d’une multitude de plug-ins de gestion de sources, bug tracker, gestion de projet, tests unitaires, etc… Tous ces plug-ins sont mis en œuvre aujourd’hui dans le cadre de méthodes projet agiles et constituent une opportunité d’évolution pour les méthodes de développement mainframe.
 

Outils: Opter pour l’Open Source

Les plug-ins Eclipse sont généralement développés en EPL (Eclipse Public Licence), modèle de licence qui permet à tout un chacun de modifier, compiler et éventuellement commercialiser des plug-ins. Ceci favorise l’émergence de solutions professionnelles basées sur des plug-ins Open Source.
Il devient alors possible de bâtir un atelier de développement COBOL mainframe sur mesure en assemblant les plug-ins qui conviennent aux modes de fonctionnement et aux outils de son entreprise. Il suffit seulement que les plug-ins accèdent de manière native aux ressources Eclipse et n’enferment pas l’utilisateur dans un cadre propriétaire.
Cet atelier devient un logiciel résultant de l’assemblage de plug-in dans lequel on configure les fichiers de paramétrage communs à l’ensemble des développeurs et que l’on distribue sur les postes de travail. Une bonne pratique communément partagée est de faire une mise à jour annuelle.

Cobos a été conçu à partir de composants Open Source, assemblés, améliorés et complétés pour en faire une solution professionnelle orientée développement COBOL mainframe sous Eclipse à un cout raisonnable. Réalisé en collaboration étroite avec des utilisateurs, l’idée est de combiner le meilleur des 2 mondes en capitalisant sur l’innovation de la communauté Open Source et sur les meilleures pratiques issues de l’expérience mainframe.

Un schéma vaut mieux qu’un long discours :

Cobos est donc un ensemble de plugins Eclipse accompagnés d’exécutables assurant l’émulation 3270 et la compilation COBOL locale ainsi que de scripts Rexx permettant d’accéder à un site distant en FTP (module « FTP Access »).

L’IDE COBOL contient l’éditeur COBOL avec

• coloration syntaxique,
• navigation par la vue Outline,
• auto-complétion (variables, labels, templates de code configurables),
• marquage des erreurs de compilation ,
• historisation des modifications,
• « Open Declaration »,
• expansion des Copys,
• tabulations configurables,
• CAPS ON « à la ISPF »,
• mode révision « à la Word »
• et j’en passe…

C’est simple, quand on y a gouté, on ne supporte plus de faire PF7/PF8 pour se balader dans un source…:)

La compilation COBOL en local sert à vérifier la syntaxe et permet d’éviter des compilations inutiles sur le host. Cobos assure le lien entre l’IDE et les compilateurs (COBOL-IT en local et IBM Enterprise COBOL sur le Z).
La aussi, double-cliquer sur un message du style IGYPA3305-S TOTO and TATA did not follow the « MOVE » statement compatibility rules. The statement was discarded. et se retrouver direct dans le source sur la ligne en erreur, passer la souris sur les variables pour voir leur type, puis faire PF3 pour aller modifier la déclaration de l’une d’elles, c’est un autre monde…

Une fois le programme compilé sur le host, on peut utiliser l’éditeur JCL pour les tests batch ou l’émulateur je3270 pour les tests CICS/IMS (et accéder à d’autres outils du site, OK).

Les ressources mainframe (scripts Rexx et executable CVS) sont fournies sous forme d’un module optionnel (« Mainframe extension ») offrant un accès très confortable aux ressources mainframe soit via CVS soit directement dans les PDS via une vue Eclipse, le Z/Navigator.

Cobos assure l’interface entre les scripts (locaux ou mainframe) et Eclipse. Cet interface est hautement extensible et permet d’adapter à moindre cout les scripts existants pour qu’ils puissent être appelés depuis Cobos.
Cobos respecte les standards eclipse et est de ce fait compatible avec tout plug-in lui aussi respectueux des standards…

Plus d’info sur Cobos

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…