La période faste du développement d’applications sur mainframe a débuté dans les années 1970 et s’est poursuivie jusqu’à l’avènement de l’informatique distribuée au début des années 1990. C’est durant cette période que la plupart des applications mainframes, qui traitent toujours aujourd’hui plus de 70% du commerce électronique mondial, ont été créées. Rares sont les programmeurs qui ont développé ces applications et qui sont toujours en activité 50 ans plus tard. D’ailleurs, beaucoup d’entre eux ne pensaient pas que leurs programmes seraient toujours utilisés après le passage à l’an 2000.

La gestion du code source au tout début de l’informatique commerciale dépendait beaucoup de la connaissance des systèmes en place. Les capacités de gestion du code source que nous tenons pour acquises aujourd’hui n’ont vraiment fait partie des processus standards de développement d’applications qu’au moment de l’explosion du marché de l’emploi des programmeurs, qui a renforcé la rotation du personnel.

Cette relation initialement « distendue » entre le code source, la documentation et les programmes effectivement utilisés a créé un problème qui s’amplifie depuis 50 ans. Et la difficulté à identifier précisément quel code source a servi au développement d’applications utilisées depuis longtemps explique quelques-uns des enjeux liés au réhébergement.

Toutefois, la disponibilité du code source n’est pas la seule problématique en termes de réhébergement des applications historiques. Même si un mainframe n’est rien d’autre qu’un ordinateur fondé sur l’architecture standard de Von Neumann, la façon dont l’environnement d’exploitation a été implémenté, et a continué d’évoluer pendant plus d’un demi-siècle, crée des dépendances matérielles et logicielles (très) fortes que l’on ne peut ignorer. Autrement dit, même si le code source est disponible, des problèmes parfois très difficiles à surmonter demeurent.

Problème n°1 : les dépendances au code source

Sans une cartographie des dépendances applicatives, qui fait souvent défaut pour les applications mainframes historiques, les utilisateurs doivent assumer la lourde tâche d’identifier de quelles autres applications ou programmes la cible dépend pour fonctionner.

Quand on se concentre sur ce point, la liste des dépendances des programmes s’allonge de façon exponentielle. Le programme initial fait référence à deux autres, qui à leur tour font référence à deux autres, dont un qui est invoqué par plusieurs autres programmes. Les fichiers utilisés par le premier programme peuvent aussi être utilisés par un ensemble totalement différent de programmes, tous ayant leurs propres dépendances. Même dans un système modeste, ce réseau d’interconnexions vient étendre de façon exponentielle la portée et la durée du projet de réhébergement, bien au-delà de l’évaluation initiale la plus pessimiste.

Quand la stratégie de réhébergement s’appuie sur la recompilation du code source, la situation s’aggrave encore. Pour chaque programme, le code source et son dossier doivent être retrouvés, même le code de cet obscur utilitaire qui n’a pas été mis à jour depuis 1979 (et il y en a beaucoup dans de nombreuses applications mainframes). Comme l’a souligné le directeur IT d’une grande entreprise : « nous avons près de 100 millions de lignes de code COBOL dans notre référentiel de code source, mais seulement 10 millions de lignes sont actives. On ne sait juste pas lesquelles sont ces 10 millions ! » Envisager de recompiler ces applications pour qu’elles fonctionnent sur une nouvelle plateforme ne peut se faire sans identifier au préalable tout le code source actif, tâche longue et pénible, afin de le rendre disponible pour la migration.

Certains programmes mainframes, parmi les tout premiers, ne peuvent tout simplement pas être recompilés pour tourner sur des architectures modernes. De tels programmes ont été créés à une époque où personne ne se souciait de leur incompatibilité future avec d’autres plates-formes que pouvait causer la référence directe aux fonctions système sous-jacentes, comme les blocs de contrôle du système d’exploitation. Il existe ainsi de très nombreuses aiguilles de programmation à chercher (et trouver…) dans la botte de foin massive des applications de nombreuses entreprises !

Problème n°2 : les différences dans l’encodage mainframe

En supposant que toutes les dépendances logicielles soient détectées et comprises, l’encodage mainframe pose un problème additionnel.

Les systèmes mainframes stockent les données de type caractères avec un encodage appelé EBCDIC, tandis que les ordinateurs x86, cible la plus courante pour les applications mainframes réhébergées, encodent les données en ASCII ou encore dans une variante Unicode plus moderne. Pour ce qui est des valeurs numériques, les mainframes ont une représentation binaire « big-endian » tandis que les ordinateurs x86 ont une représentation « little-endian » : l’ordre de stockage des bits représentant le nombre dans la mémoire est inversé. S’il peut être relativement simple de stocker les données, l’effet de l’encodage sur la logique du programme peut causer de sérieuses complications. La conséquence de règles d’encodage différentes est que le code source associé aux programmes devant être réhébergés doit être changé pour rendre compte des différences d’ordre de tri et de représentations arithmétiques entre les formats d’encodage. Imaginez l’ampleur de l’exercice, avec les tests de régression associés, si la carte des dépendances applicatives présente plusieurs centaines (voire milliers) de programmes devant être réhébergés.

Problème n°3 : les différences entre standards de base de données et de traitement des données

Mais l’encodage n’est que la partie émergée de l’iceberg. Par exemple, les systèmes modernes exécutent les opérations à virgule flottante différemment des mainframes ; mathématiquement, le résultat est différent. Pour certaines catégories d’applications, ne pas tenir compte de ces différences peut avoir un impact négatif.

Les formats et standards des bases de données génèrent également leur lot de problèmes et d’incompatibilités. Par exemple, le dialecte mainframe du code SQL est différent des variantes plus modernes et les applications mainframes font fréquemment référence à du code SQL stocké dans le catalogue des bases de données mainframes donc non intégré directement dans le code applicatif, ce qui est rare sur d’autres plateformes.

Se pose également le problème des types de données mainframes au sein des systèmes de bases de données ouverts. Même si de nombreux types de données mainframes sont courants dans ces systèmes, deux des types les plus fréquents, les caractères et les décimales, sont différents. Associé au fait que l’arithmétique et le tri sont souvent opérés dans une base de données, le potentiel de changements induits par les données dans la logique du programme du fait de l’exercice de réhébergement est très important.

Pour résumer, maîtriser le code source, aussi difficile que cela puisse être, ne résout qu’une partie du problème. Pour recompiler de nombreuses applications mainframes et pour qu’elles fonctionnent correctement sur l’environnement cible, il faut d’abord modifier le code en profondeur, le compiler et mener plusieurs phases de tests et de validation pour obtenir des résultats identiques.

La solution à ces problèmes ?

Ce qui précède dépeint un tableau plutôt peu engageant du défi qui attend les entreprises désireuses d’héberger leurs applications historiques sur une plate-forme moderne. La recompilation peut au final s’avérer impossible, si bien que les entreprises n’ont pas trouvé jusqu’à aujourd’hui de solution efficace pour faire migrer ces anciennes applications vers des systèmes plus récents, apparemment totalement incompatibles.

C’est alors qu’intervient la technologie Software Defined Mainframe rendant possible le réhébergement d’applications sous leur forme binaire originale par la prise en charge des fonctions mainframes spécifiques rendues accessibles aux applications. Sans cette prise en charge, la migration du programme nécessiterait les étapes longues et coûteuses évoquées précédemment de reprogrammation, de recompilation et de vérification. En stockant les données dans leur format natif, et en mettant en œuvre le tri et les autres algorithmes à partir de ce format, les problèmes de stockage et de représentation des nombres identifiés plus tôt sont éliminés.

Dans certains cas, il n’est pas possible d’échapper à l’obligation de travailler avec le code source historique. De nombreuses applications mainframes sont mises à jour régulièrement pour cause de changement réglementaire ou interne à l’entreprise.  Après la fin de la migration, la technologie Software Defined Mainframe (SDM) permet ce type de recompilation dans un contexte DevOps moderne, au moyen d’outils de développement graphiques. Il n’est pas nécessaire d’apporter des changements dans le code, suite à la recompilation, pour régler les problèmes de compatibilité identifiés ci-avant ; ceux-ci sont pris en charge de manière transparente par l’environnement SDM.

Le réhébergement des applications mainframes est de plus en plus prisé mais l’approche traditionnelle impliquant la recompilation de tout le code source est cause de multiple problèmes. De plus, l’héritage de 50 années de programmation mainframe crée une panoplie imposante d’obstacles à la réussite de tout projet dépendant du code source, des obstacles rendus apparemment insurmontables par la pénurie de compétences spécialistes des mainframes. L’approche SDM est l’option a priori la plus viable pour les entreprises qui aspirent à réhéberger et moderniser leur système IT, leur apportant une solution pratique à faible niveau de risque, constituant une excellente plateforme pour permettre aux entreprises de continuer à utiliser leurs logiciels applicatifs historiques, donc à protéger leurs investissements, dans le cadre de stratégies numériques modernes.