Supprimer PACBASE

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

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 re-génération des programmes utilisateurs. Et du coup une nouvelle génération des programmes ne produirait pas les mêmes COBOL générés.

Il est donc nécessaire de mener une phase d’analyse pour identifier les programmes en écart. Puis on étudie 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. Elle l’est 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. Cette migration est réalisée 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. Celle-ci est réalisée 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. En effet, il est nécessaire 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. Il est aussi é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. En effet pour ceux-ci, il est possible d’identifier un maximum de patterns 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. Ils sont 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. Alors nous 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.

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.

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 pour Mainframe IBM 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.

Solution de suppression de l’AGL PACBASE

Migration PACBASE vers COBOL natif.

Mainframe IBM MVS.

Mainframe BULL GCOS7.

Environnements UNIX.