A4IT
Services / Modernisation mainframe
05 / 08
Modernisation mainframe · COBOL, DB2, JCL, CICS et IMS

Savoir ce que fait le mainframe. Puis le déplacer, morceau par morceau.

A4IT lit les applications COBOL, DB2, JCL, CICS et IMS, met par écrit ce qu'elles font réellement et les fait passer sur Java ou .NET avec PostgreSQL ou SQL Server, une fonction à la fois. La rétro-ingénierie vient d'abord : un inventaire, les flux de données et les règles métier, dans des documents que vos propres collaborateurs peuvent vérifier. L'ancien système continue de tourner jusqu'à ce que le nouveau donne les mêmes résultats. Vous travaillez directement avec Tim De Smedt, sans intermédiaires.

Parlons de votre système → Ce que nous livrons Déroulement d'une mission

Ce que vous recevez, ce qui reste à vous, où cela s'arrête

Dit avant la première réunion
Vous recevez
  • Un inventaire des programmes, jobs, copybooks, tables et fichiers, avec qui appelle quoi
  • Les règles métier en langage clair, chacune rattachée au code dont elle provient
  • Un plan de migration par étapes, chacune avec son périmètre, son estimation et son retour arrière
  • Le nouveau code sous gestion de versions, avec des tests qui comparent les résultats de l'ancien et du nouveau
Reste à vous
  • Le code source, ancien et nouveau, et chaque document que nous rédigeons
  • Vos données et vos environnements : nous travaillons avec les accès que vous accordez
  • La décision par composant : conserver, encapsuler, réécrire ou retirer
  • La liberté de continuer avec votre propre équipe ou un autre fournisseur
Limites
  • Pas de bascule en big bang : l'ancien et le nouveau tournent en parallèle jusqu'à ce que les résultats concordent
  • Pas de code converti par une machine remis comme résultat : chaque programme est lu et testé
  • Pas d'exploitation mainframe ni de programmation système
  • Pas de promesse d'économie ni de date de fin avant que l'inventaire soit terminé

Ce que nous livrons

Sept briques · prenez-en une ou toutes
01 · Comprendre

Inventaire et évaluation

Avant de déplacer quoi que ce soit : ce qui existe, ce qui est encore utilisé et ce qui dépend de quoi.

Programmes et jobs
Les programmes COBOL, les copybooks, les jobs et procédures JCL, les transactions CICS et les composants IMS, listés avec leur taille et leur dernière modification.
Dépendances
Quel programme appelle lequel, quel job tourne après lequel, et quelles tables et quels fichiers chacun d'eux lit ou écrit.
Code mort et code dupliqué
Les programmes qu'aucun job ni aucune transaction ne lance plus, et les copies qui ont divergé. Ce qui n'est pas utilisé n'a pas à être migré.
Risque et effort
Un avis écrit par composant : conserver, encapsuler, réécrire ou retirer, avec les raisons et un ordre de grandeur.
02 · Comprendre

Rétro-ingénierie et documentation

La connaissance se trouve dans le code et dans quelques têtes. Nous la mettons sur papier tant que les deux sont encore disponibles.

Règles métier
Les calculs, les validations et les exceptions extraits du code et rédigés en langage clair, avec une référence au programme et au paragraphe.
Modèle de données
Les tables DB2, les fichiers VSAM et les structures d'enregistrement des copybooks décrits comme un seul modèle de données, y compris les champs dont la signification a changé au fil des années.
Flux batch
Les chaînes de jobs JCL dessinées sous forme de flux : ce qui démarre quand, avec quelle entrée, pour produire quelle sortie, et ce qui se passe quand une étape échoue.
Vérifié avec vos collaborateurs
Chaque document est relu par quelqu'un qui connaît le métier. Là où le code et la mémoire ne concordent pas, c'est consigné et tranché.
03 · Comprendre

Analyse assistée par l'IA

Les modèles de langage lisent le COBOL plus vite que les personnes. Ils se trompent aussi, donc chaque résultat est vérifié par rapport au code.

Expliquer les programmes
Un modèle résume ce que fait un programme ou un paragraphe, comme premier jet pour l'analyste. Voir conseil en IA.
Trouver les règles et les liens
Où un champ est renseigné, où une règle est appliquée ou une table mise à jour, recherché dans toute la base de code plutôt qu'un programme à la fois.
Vérifié par une personne
Rien de ce qu'un modèle produit n'entre dans la documentation ou dans le nouveau code sans une revue et un test.
Votre code reste là où vous le décidez
Un modèle local ou un service que vous avez approuvé, choisi avec vous. L'analyse peut aussi se faire sans modèles de langage.
04 · Connecter

Interfaces autour du mainframe

Souvent, la première étape n'est pas de remplacer quoi que ce soit, mais de permettre aux nouveaux logiciels d'accéder à ce qui existe.

Des API devant les transactions
Une API REST devant les transactions CICS ou IMS existantes, pour qu'une application web ou un partenaire puisse les utiliser sans écran de terminal.
Échange de fichiers
Les fichiers séquentiels et les extractions VSAM convertis de manière fiable : l'EBCDIC, les décimaux condensés et les enregistrements de longueur fixe vers des formats que d'autres systèmes lisent.
Accès à DB2
Un accès en lecture à DB2 pour le reporting et les nouvelles applications, ou une copie maintenue en phase là où le mainframe ne doit pas supporter de charge supplémentaire. Voir automatisation & données.
Décrit et versionné
Chaque interface a un contrat OpenAPI ou une spécification de fichier sous gestion de versions, pour que personne n'ait à lire un copybook pour l'utiliser.
05 · Moderniser

Réécriture vers Java ou .NET

Une fonction à la fois passe sur une plateforme pour laquelle on trouve facilement des développeurs. Voir développement logiciel.

Réécrit, pas translittéré
Le nouveau code est conçu à partir des règles documentées, en Java ou en C# ordinaire. Pas du COBOL ligne par ligne dans une autre syntaxe.
Batch
Les chaînes de jobs JCL deviennent des traitements par lots planifiés sur Spring Boot ou .NET, qui peuvent être relancés et produisent les mêmes totaux de contrôle.
Transactionnel
Les écrans CICS et IMS deviennent des écrans web ou des API sur Spring Boot ou ASP.NET Core. L'utilisation au clavier est conservée pour les utilisateurs qui sont rapides avec elle.
Ordre des travaux
Nous commençons par une partie aux limites claires et à faible risque. Chaque étape passe en production avant que la suivante ne commence.
06 · Migrer

DB2 et migration des données

De DB2 vers PostgreSQL ou SQL Server, avec la preuve que rien n'a été perdu ni modifié en silence.

Schéma
Les tables, les clés, les index et les contraintes transposés vers la base de données cible dans des migrations versionnées. La précision décimale, les dates et les jeux de caractères sont décidés explicitement.
SQL embarqué
Le SQL contenu dans les programmes COBOL et les procédures stockées est inventorié et réécrit pour la base de données cible, constructions propres à DB2 comprises.
VSAM et fichiers
Les fichiers qui servent de base de données deviennent de véritables tables. Les structures d'enregistrement avec REDEFINES et OCCURS sont décomposées en une structure claire.
Essais à blanc et rapprochement
Des migrations complètes répétées sur une copie, avec comparaison des nombres de lignes et des totaux, jusqu'à ce que la vraie soit une routine.
07 · Prouver

Fonctionnement en parallèle et bascule

Une migration est terminée quand le nouveau système donne les mêmes réponses, pas quand le code compile.

Résultats comparés
La même entrée passe par l'ancien et par le nouveau. Les fichiers de sortie et le contenu des tables sont comparés automatiquement ; chaque différence est expliquée ou corrigée.
Fonctionnement en parallèle
L'ancien et le nouveau tournent en parallèle pendant une période convenue, y compris une clôture de période lorsque l'application en a une.
Bascule avec retour arrière
Un plan de bascule écrit, avec une répétition, un moment de décision et un chemin de retour vers l'ancien système.
Mise hors service
Un composant n'est retiré que lorsque plus rien ne l'appelle. Ses programmes, ses jobs et ses données sont archivés comme convenu.

Déroulement d'une mission

Petites étapes · une décision après chacune
  1. Premier entretien
    Un appel de trente minutes : votre système, votre raison de changer, vos contraintes.
    30 minutes
  2. Inventaire
    Programmes, jobs et données listés, avec les dépendances, les risques et un plan par étapes.
    Inventaire + plan
  3. Rétro-ingénierie
    Règles, modèle de données et flux documentés et vérifiés avec vos collaborateurs.
    Documentation écrite
  4. Migration par étapes
    Une fonction à la fois, chacune comparée aux résultats de l'ancien système.
    Fonctionnement en parallèle
  5. Bascule et mise hors service
    Bascule avec retour arrière, puis mise hors service de l'ancienne partie.
    En production

Technologie

Choisie au cas par cas · rien n'est imposé
MainframeCOBOL, JCL, CICS, IMS
DonnéesDB2, VSAM, fichiers séquentiels, copybooks
CibleJava, Spring Boot, .NET Core, C#, PostgreSQL, SQL Server
InterfacesAPI REST, OpenAPI, XML & XSLT, échange de fichiers
AnalyseModèles de langage (locaux ou service approuvé), BPMN, Confluence
LivraisonGit, Jenkins, JIRA, tests de comparaison automatisés

Quand cela convient, et quand cela ne convient pas

Une réunion d'économisée pour vous comme pour nous
Cela convient si
  • Une application COBOL fait encore tourner l'entreprise et les personnes qui la connaissent s'en vont
  • Personne ne peut dire avec certitude ce que fait le système dans chaque cas
  • Vous voulez quitter le mainframe par étapes, ou d'abord l'ouvrir
  • Quelqu'un qui connaît le métier peut relire les documents et répondre aux questions
Cela ne convient pas si
  • Tout doit être remplacé en un seul week-end
  • Le code source a disparu et il ne reste que des programmes compilés
  • Vous cherchez un outil qui convertit tout automatiquement
  • Il vous faut de l'exploitation mainframe, ou une grande équipe sur site la semaine prochaine

Questions sur la modernisation mainframe

Toutes les questions →
01Devons-nous quitter le mainframe ?

Non. Parfois, documenter le système et l'entourer d'interfaces est le bon résultat. L'inventaire montre ce qui vaut la peine d'être déplacé ; la décision vous appartient, par composant.

02Combien de temps dure une migration ?

Cela dépend de la taille, de la façon dont les parties dépendent les unes des autres et du temps dont vos collaborateurs disposent pour relire. Après l'inventaire, vous recevez un plan par étapes avec une estimation par étape. Nous n'annonçons aucune durée avant cela.

03Utilisez-vous des convertisseurs de code automatiques ?

Les outils aident pour l'inventaire et l'analyse. Le nouveau code est écrit par des développeurs à partir des règles documentées, parce que le code converti est le plus souvent du COBOL dans une autre syntaxe que personne ne veut maintenir.

04Notre code source est-il envoyé à un service d'IA ?

Seulement si vous l'approuvez. L'analyse peut tourner sur un modèle local, sur un service que vous avez approuvé, ou sans aucun modèle de langage. Voir conseil en IA.

05Nos spécialistes COBOL partent bientôt à la retraite. Par quoi commencer ?

Par la rétro-ingénierie, tant qu'ils peuvent encore vérifier le résultat. Une documentation qu'ils ont relue vaut plus que n'importe quelle reconstitution après coup.

06Qui fait le travail, et comment le suivons-nous ?

Tim De Smedt et l'équipe de développement principale, directement. Vous le suivez par les documents, des démos régulières et une liste de tickets que vous pouvez ouvrir à tout moment. Voir notre méthode et gestion de projet & analyse.

Dites-nous ce qui tourne sur votre mainframe. Nous vous dirons par où nous commencerions.

Réponse dans les trois jours ouvrables.Parlons de votre système →Notre méthode