Solution de suppression de l’AGL PACBASE – Migration PACBASE vers COBOL natif.

PACBASE est un atelier de génie logiciel (AGL) mainframe largement répandu dans les grands comptes de la banque et de l’assurance. Il intègre un générateur de COBOL, des macros instructions, un dictionnaire de données et un gestionnaire de version.

PACBASE est extrêmement compact 100 lignes de PACBASE génèrent 500 lignes de COBOL

PACBASE gère des cinématiques de programmation complexes, appareillage de fichiers, gestion d’entités, listes, report… avec peu de programmation.

Ainsi PACBASE apporte une efficacité importante aux équipes de développement et de maintenance et son remplacement doit tenir compte des critères de productivité du poste de travail.

Notre approche se décline en :

  • Audit de l’existant
  • Amélioration du Code
  • Stratégie de déploiement et simplification des Tests de Non Régression
  • Poste de travail

Problématique de la suppression de l’AGL PACBASE

PACBASE génère du code COBOL difficilement maintenable mais totalement natif et fonctionnant en « stand alone », sans Runtime spécifique.

Ainsi, la principale problématique de la sortie de PACBASE est la maintenance des applications. En effet, une application totalement stable ne nécessite aucun travail particulier pour continuer à fonctionner sur la base du COBOL généré.

Pour continuer à faire évoluer une application développée sous PACBASE, il est nécessaire de rendre le code généré maintenable et de se doter d’un environnement de travail performant si l’on souhaite conserver puis améliorer la productivité des équipes de maintenance.

L’objectif est de constituer un référentiel de configuration logicielle contenant les sources de programmes COBOL rendus maintenables, les COPY des structures de données et éventuellement des MACROS et de mettre en place d’un environnement de travail permettant de gérer l’ensemble de manière productive.

Analyse du référentiel PACBASE

La première étape de la migration consiste à s’assurer que le référentiel PACBASE est bien cohérent avec les programmes en production. En effet, les éléments du référentiel tel que les SEGMENTS et les MACROS ont pu évoluer au fil du temps sans regénération des programmes utilisateurs et une nouvelle génération des programmes ne produirait pas les mêmes COBOL générés.

Pacbase 1

Il est donc nécessaire de mener une phase d’analyse pour identifier les programmes en écart et si cet écart peut entrainer un dysfonctionnement.

En effet, par exemple, un segment ayant évolué par ajout de zones prises sur un filler de fin, n’entraînera pas de dysfonctionnement sur les programmes générés avec l’ancienne version.

Cet écart est dit compatible.

L’étude de compatibilité est totalement automatique pour les SEGMENTS, et partiellement pour les MACROS qui nécessitent une analyse manuelle.

A la fin de la phase d’analyse, les programmes sont répartis en 2 groupes :

1 – Programmes sans écarts et Programmes avec écarts compatibles

2 – Programmes avec écarts non-compatibles

Les programmes du groupe 1 seront migrés à partir de la version courante des SEGMENTS et MACROS qui seront transformés en COPY.

Les programmes du groupe 2 seront migrés à partir de la version des SEGMENTS et MACROS ayant servi à les générer. Une étude complémentaire permettra d’évaluer s’il est préférable de migrer vers un COBOL étendu ou un COBOL utilisant des COPY spécifiques pour les SEGMENTS et MACROS en écart.

Migration des composants PACBASE

La seconde étape de la migration consiste à migrer les objets PACBASE dans le nouveau référentiel en produisant un code COBOL natif maintenable.

Nous réalisons cette opération par une approche de réconciliation entre le code généré par PACBASE dont il convient de conserver le comportement car il est en production et le source PACBASE qui contient la vision développeur.

La stratégie consiste à conserver la logique d’un programme PACBASE afin de limiter au maximum l’apprentissage des équipes de maintenance.

Les commentaires sont réintégrés dans le code COBOL.

Le code COBOL restructuré en remplaçant les GOTO par des blocs IF/THEN/ELSE. Les codes blocs sont conservés sous forme de commentaires dans la marge.

Le code est indenté de manière standard et étendu en mode pleine page (programmation au-delà de la colonne 72) pour mieux visualiser l’imbrication des IF. Le poste de travail intégrera des fonctions d’assistance telles que la visualisation des IF ELSE END de même niveau d’imbrication.

Les groupes d’instructions correspondant à des fonctions techniques générées par PACBASE, sont remplacées par un équivalent structuré et plus lisible. L’optimum est atteint pour les programmes en phase avec le référentiel PACBASE pour lesquels il est possible d’identifier un maximum de pattern d’amélioration.

La Working Storage Section est remaniée pour remplacer les SEGMENTS étendus par un COPY REPLACING et supprimer toutes les rubriques inutilisées.

Pour les programmes du groupe 2 migrés avec des COPY spécifiques pour les SEGMENTS et MACROS en écart, nous insérons des commentaires destinés à la maintenance pour proposer un réalignement avec le référentiel standard lors de la prochaine modification.

Stratégie de déploiement et de tests

Dans le cas d’un projet de sortie de PACBASE sans changement de plateforme, il n’est pas nécessaire de migrer et certifier tous les programmes d’un coup.

Il est fréquent que de nombreux objets d’un patrimoine soient très stables. Il n’est pas indispensable de les migrer et de les certifier avant la première maintenance. Cela permet de lisser dans le temps la charge de certification. La charge de migration étant très faible du fait de l’automatisation.

Pour certifier un programme, nous comparons les exécutions des programmes généré PACBASE original et COBOL structuré cible et vérifions que chaque bloc d’instruction a été exécuté le même nombre de fois. L’iso-fonctionnalité des blocs d’instruction générés PACBASE originaux et leurs équivalents COBOL structurés ayant été certifiés préalablement.

On associera à chaque objet du gestionnaire de configuration un statut :

  • Source (généré original)
  • Amélioré
  • Amélioré certifié
  • Migré

On peut dans un premier temps ne certifier que les programmes du plan de maintenance et lisser dans temps la certification des autres programmes. Les mécanismes de certification seront intégrés dans le poste de travail sous Eclipse.

Le poste de travail

Afin d’optimiser la productivité des équipes de maintenance, nous proposons un atelier de développement sous Eclipse et un ensemble de plugins.

L’atelier ne crée pas d’adhérence avec le code migré qui peut être maintenu sans lui mais offre un ensemble de fonctions facilitant le travail du développeur.

Pacbase 2

Les fonctions générales de l’AGL PACBASE sont reproduites sous la forme de plugins intégrés les uns avec les autres.

L’atelier dispose d’un connecteur 3270 permettant de compiler en arrière-plan les programmes ou permettant d’enrichir les ateliers de développement COBOL du marché avec lesquels il s’intègre.