Analyse des dépendances de la base de données IMS : ce que les équipes de modernisation doivent savoir avant toute migration

IMS n'est pas un système obsolète au sens traditionnel du terme. Il s'agit du moteur de base de données qui gère les comptes clients des grandes banques, l'administration des polices d'assurance et le traitement des demandes de remboursement des organismes de santé. IBM continue de le développer. Le problème n'est pas qu'IMS ait cessé de fonctionner, mais plutôt que tous les développeurs capables de naviguer dans son arborescence hiérarchique prennent leur retraite, que toute modification apportée à un système basé sur IMS nécessite la compréhension d'un modèle de données dépourvu de SQL, et que tout plan de migration qui traite IMS comme une base de données relationnelle se heurte à des difficultés.

La difficulté majeure réside dans la découverte, en cours de migration, qu'un programme COBOL accède à IMS non pas par une simple recherche par clé, mais par un parcours hiérarchique qu'il faut reproduire dans le système cible avec une logique de navigation équivalente. Ou encore, la découverte qu'une relation logique entre deux bases de données IMS physiques crée une dépendance que le schéma de base de données (DBD) d'aucune des deux bases n'est entièrement documenté, et que la migration a converti les deux bases indépendamment, rendant inopérants, sans le moindre bruit, tous les programmes utilisant cette relation logique. Ou enfin, la découverte qu'une base de données d'index secondaire, une structure que la plupart des plans de migration omettent d'inventorier, était le seul chemin d'accès aux données pour un programme de reporting critique.

Aucune de ces surprises ne résiste à une analyse rigoureuse des dépendances préalables à la migration. Elles résistent en revanche à la confrontation avec des hypothèses.

Qu'est-ce qui différencie l'analyse de dépendances IMS ?

L'analyse des dépendances dans un environnement de base de données relationnelle (DB2, Oracle, SQL Server) suit un processus bien défini. Elle consiste à analyser le code SQL de l'application, à identifier les références aux tables et aux colonnes, à établir une cartographie des accès aux tables par les différents programmes, puis à utiliser cette cartographie pour déterminer la portée et la séquence des migrations. La structure est explicite : les dépendances sont clairement visibles dans le code SQL.

L'analyse des dépendances IMS est plus complexe dans tous les domaines.

La structure est hiérarchique, et non relationnelle. Une base de données IMS est organisée sous forme d'arbre de types de segments, chaque type de segment ayant une relation parent-enfant définie. Un programme COBOL qui lit les dossiers patients d'une base de données IMS n'exécute pas SELECT * FROM PATIENTS WHERE ID = ?Le programme effectue un appel Get Unique (GU) pour naviguer dans la hiérarchie jusqu'au segment racine, puis des appels Get Next Within Parent (GNP) pour parcourir les enfants. Sa dépendance ne porte pas sur une table, mais sur un chemin spécifique au sein d'une structure hiérarchique. Modifier cette structure peut perturber le fonctionnement des programmes qui la parcourent, et ce, de manière imperceptible par une analyse SQL.

Les dépendances sont réparties sur trois structures distinctes. Pour comprendre pleinement le fonctionnement d'un programme COBOL avec IMS, il est nécessaire d'analyser :

• Le DBD (Descripteur de base de données) : définit la hiérarchie des segments physiques, les champs clés, les méthodes d'accès (HDAM, HIDAM, HISAM, HSAM) et les index secondaires ou relations logiques.
• Le PSB (Bloc de spécifications de programme) : définit les bases de données auxquelles un programme est autorisé à accéder, par l'intermédiaire de quels PCB, et avec quelles spécifications de sensibilité et d'intention
• Le code source COBOL : contient les appels DL/I proprement dits qui déterminent quels segments sont accédés, avec quelles fonctions d'appel, dans quelle séquence et avec quels SSA.

Aucune source unique ne fournit une image complète. Une analyse se limitant au code source COBOL révèle les types d'appels et les noms de segments, mais pas la structure physique de la base de données. Une analyse se limitant au DBD et au PSB indique les actions autorisées du programme, mais pas son fonctionnement réel.

La navigation dépend de la position. Dans une base de données relationnelle, chaque ligne est accessible indépendamment par sa clé. Dans IMS, la position actuelle d'un programme dans la hiérarchie influence les résultats des appels suivants. Un appel GN (Get Next) renvoie le segment suivant dans la séquence hiérarchique, quelle que soit la position actuelle du programme. Cette dépendance ne se limite pas au type de segment ; elle s'étend au chemin de parcours ayant mené à la position actuelle. Les programmes qui s'appuient sur l'ordre hiérarchique implicite d'IMS présentent une dépendance qui disparaît lors de la migration des données vers une base de données relationnelle où aucun ordre équivalent n'est garanti.

Inventaire des appels DL/I : ce que révèle le code source COBOL

L'analyse préalable à la migration la plus utile consiste à dresser un inventaire complet de tous les appels DL/I de chaque programme COBOL accédant à IMS. Cet inventaire indique à l'équipe de migration ce que chaque programme fait avec IMS, non pas ce qu'il est autorisé à faire (défini par le PSB), mais ce qu'il fait réellement.

Les appels DL/I en COBOL apparaissent sous deux formes :

Cobol

* Form 1: EXEC DLI interface (CICS-compatible, high-level syntax)
       EXEC DLI
           GU DB2PCB
           SEGMENT(CUSTROOT)
           WHERE(CUSTID = WS-CUST-ID)
       END-EXEC

* Form 2: xxxTDLI call interface (batch programs, assembler-compatible)
       CALL 'CBLTDLI' USING WS-FUNCTION-CODE
                            PCB-CUSTOMER
                            WS-CUSTOMER-SEGMENT
                            WS-SSA-CUSTOMER

Les deux formulaires contiennent les mêmes informations analytiques : le code de fonction, le circuit imprimé utilisé, le segment ciblé et, éventuellement, l’argument de recherche de segment (SSA) qui qualifie l’appel. Un inventaire complet des appels DL/I extrait toutes ces informations de chaque programme.

La taxonomie des codes de fonction et ses implications en matière de migration

Le code de fonction DL/I est l'élément le plus important de chaque appel pour la migration. Chaque code de fonction implique un modèle d'accès aux données différent qui doit être reproduit dans la base de données relationnelle cible :

Fonctions en lecture seule : GU, Get Unique : naviguez directement vers un segment à l’aide d’identifiants de segment uniques qualifiés. Équivalent à une requête SELECT avec clause WHERE dans le contexte relationnel. La migration est simple si la clé du segment correspond directement à une clé primaire relationnelle.

GN, Get Next : passe au segment suivant dans la séquence hiérarchique. Ce code de fonction n’a pas d’équivalent relationnel direct ; il repose sur l’état positionnel et l’ordre implicite d’IMS. Les programmes qui utilisent intensivement GN nécessitent une analyse approfondie de l’ordre dont ils dépendent.

GNP, Get Next Within Parent : récupère les enfants suivants du segment parent actuel. Équivalent à récupérer toutes les lignes d'une relation de clé étrangère. Correspond généralement à une requête SELECT avec une clause WHERE utilisant une clé étrangère.

Fonctions de maintien (prérequis pour la mise à jour) : GHU, GHN, GHNPLes fonctions Get Hold sont équivalentes à GU, GN et GNP. L'indicateur « hold » signale qu'une opération de mise à jour (REPL) ou de suppression (DLET) suivra. Les programmes utilisant des appels hold sont des programmes de lecture-modification-écriture ; la migration doit préserver l'intégrité transactionnelle entre la mise en attente et la mise à jour ultérieure.

Fonctions de mise à jour : ISRT, Insertion : ajoute une nouvelle occurrence de segment. Équivalent à INSERT. DLETSupprimer : supprime le segment actuellement détenu et tous ses dépendants. Ce comportement « tous les dépendants » est une cascade spécifique à IMS qui doit être explicitement implémentée dans le système cible. REPL, Replace : met à jour le segment actuel avec de nouvelles données. Équivalent à UPDATE.

Pourquoi cela importe pour la portée de la migration : Un programme utilisant uniquement les appels GU et GNP est un consommateur en lecture seule des données IMS ; sa migration présente donc moins de risques et sa validation est simplifiée. Un programme utilisant GHU, REPL et DLET est un programme de traitement transactionnel qui modifie les structures hiérarchiques ; sa migration exige la préservation de l’intégrité transactionnelle des opérations, intégrité actuellement garantie atomique par IMS.

Les trois types de dépendances qui font dérailler toutes les migrations

Relations logiques

Les relations logiques IMS connectent des segments répartis sur deux bases de données physiquement distinctes. Un segment enfant logique de la base de données A possède un segment parent logique dans la base de données B. Lorsqu'un programme COBOL parcourt une relation logique, il emprunte un chemin qui traverse physiquement les limites des bases de données. Ce parcours est géré de manière transparente par IMS, mais disparaît lors de la migration indépendante des bases de données.

Les relations logiques représentent le type de dépendance le plus risqué lors de la migration IMS, car elles sont invisibles dans le code source COBOL. Le programme COBOL appelle GNP pour obtenir les enfants d'un segment. Le fait que cet appel GNP traverse une relation parent-enfant physique ou logique est déterminé par le PSB et le DBD, et non par le code COBOL. Une équipe de migration qui analyse uniquement le code source COBOL est incapable de savoir qu'un appel GNP franchit la limite d'une relation logique sans analyser séparément le PSB et le DBD.

Les programmes qui utilisent des relations logiques nécessitent une migration pour reproduire la sémantique de la relation logique dans le système cible, généralement une jointure dans le modèle relationnel, et pour valider que chaque programme utilisant la relation reçoit des résultats équivalents de la jointure qu'il a reçue du parcours logique IMS.

Bases de données d'index secondaires

Les bases de données d'index secondaires IMS offrent un chemin d'accès alternatif à une base de données principale, permettant aux programmes de récupérer des segments par un champ autre que la clé racine. Une base de données d'index secondaire est une base de données IMS distincte, dotée de son propre système de gestion des données (DBD), mais ses données proviennent de la base de données principale.

Les équipes de migration découvrent fréquemment des bases de données d'index secondaires lors de l'analyse plutôt que lors de la planification, car :

• Elles sont définies dans des DBD qui ne sont pas toujours regroupées avec les DBD de la base de données principale.
• Les programmes qui utilisent des index secondaires nomment la base de données d'index dans leurs PSB, mais les programmes qui accèdent à la base de données principale via un index secondaire peuvent ne pas l'indiquer clairement dans le code source COBOL.
• La documentation peut décrire la base de données principale sans mentionner ses index secondaires.

Un programme accédant à IMS via un index secondaire présente une dépendance de modèle d'accès qui doit être reproduite dans la cible, soit sous la forme d'un index non primaire, soit via une stratégie de requête différente. Omettre cette dépendance lors de la migration a pour conséquence l'exécution du programme sans erreur, mais dans l'incapacité de trouver les enregistrements recherchés.

Bases de données GSAM

Les bases de données GSAM (Generalized Sequential Access Method) constituent l'interface IMS pour le traitement par lots séquentiel, permettant ainsi aux programmes COBOL d'utiliser des appels DL/I pour des opérations d'entrée/sortie de fichiers fonctionnellement séquentielles. Les bases de données GSAM ne possèdent pas de hiérarchie de segments ; ce sont des structures séquentielles plates accessibles via IMS afin de bénéficier des capacités de récupération et de redémarrage d'IMS.

Les programmes utilisant des bases de données GSAM sont des programmes par lots qui dépendent de la gestion des points de contrôle et des redémarrages d'IMS pour leur reprise après sinistre. La migration doit préserver ce comportement de reprise ou le remplacer par un mécanisme équivalent sur la plateforme cible.

Constitution de l'inventaire des dépendances avant la migration

Une analyse complète des dépendances IMS produit six livrables qui, ensemble, définissent la portée, les risques et la séquence de la migration.

Livrable 1 : Correspondance entre le circuit imprimé et la base de données

Chaque PCB de chaque PSB est associé à une DBD spécifique (une base de données IMS spécifique). Lister tous les PCB de tous les PSB et les associer à leur DBD permet d'obtenir la liste de référence des programmes autorisés à accéder à quelles bases de données. C'est le point de départ pour comprendre la portée des programmes, mais cette liste surestime les dépendances réelles, car certains programmes peuvent avoir des PSB contenant plus de bases de données qu'ils n'en utilisent réellement.

Livrable 2 : Inventaire réel des appels par programme

L'analyse des appels DL/I de chaque programme COBOL permet d'obtenir la liste d'utilisation réelle : les PCB effectivement appelés par chaque programme, les codes de fonction utilisés, les types de segments auxquels il accède et s'il utilise des SSA qualifiés (accès par clé de segment) ou une navigation non qualifiée (parcours positionnel). Ceci permet de réduire le champ d'application des permissions définies par le PSB au comportement réel du programme.

Livrable 3 : Carte d’utilisation des relations logiques

La comparaison de l'inventaire des appels avec les diagrammes de distribution de base (DBD) permet d'identifier les programmes dont les appels GNP ou GN traversent des relations logiques. Cela nécessite l'analyse non seulement du code source COBOL et du PSB, mais aussi des structures DBD qui définissent quelles relations parent-enfant sont physiques et lesquelles sont logiques.

Livrable 4 : Carte d’utilisation de l’index secondaire

Les programmes qui mentionnent des bases de données d'index secondaires dans leurs PSB ou qui effectuent des appels avec des SSA référençant des champs de clé non racine sont identifiés comme des utilisateurs d'index secondaires. La carte documente les index secondaires existants, les bases de données primaires qu'ils prennent en charge et les programmes qui en dépendent.

Livrable 5 : Répartition des types d’appels par base de données

Pour chaque base de données IMS concernée, la répartition des types d'appels entre tous les programmes qui y accèdent indique la complexité de sa migration :

• Les bases de données accessibles uniquement par des fonctions de lecture (GU, GN, GNP) sont plus simples à migrer.
• Les bases de données auxquelles accèdent les fonctions de maintien et de mise à jour (GHU + REPL, GHN + DLET) nécessitent une réplication à intégrité transactionnelle.
• Les bases de données présentant une utilisation élevée de la navigation GN indiquent des dépendances de navigation positionnelle qui nécessitent une analyse de l'ordonnancement.
• Les bases de données comportant des relations logiques nécessitent une sémantique de jointure inter-bases de données dans la base cible.

Livrable 6 : Classification des risques du programme

En utilisant la distribution des types d'appels et l'inventaire des types de dépendances, chaque programme est classé selon son risque de migration :

Les programmes utilisant uniquement GU et GNP avec des SSA qualifiés, accédant à une seule base de données sans relations logiques et n'effectuant aucune opération de mise en attente ou de mise à jour, présentent le risque le plus faible pour les premières phases de migration. À l'inverse, les programmes utilisant GN de ​​manière intensive, accédant à plusieurs bases de données via des relations logiques ou effectuant des séquences complexes de mise en attente ou de mise à jour sont les programmes à risque le plus élevé et nécessitent une analyse et une validation approfondies avant la migration.

Ce que l'analyse change dans la planification migratoire

L'analyse des dépendances ne se contente pas de documenter l'existant, elle modifie les décisions qui en découlent.

Décisions de séquence. Les programmes partageant des bases de données IMS via des relations logiques ne peuvent pas être migrés indépendamment. Si le programme A lit un segment enfant logique dont le segment parent logique se trouve dans la même base de données que le segment racine du programme B, la migration de A sans migration préalable de B (ou sans création d'un pont) entraîne l'arrêt de A. Le graphe de dépendances détermine quels programmes doivent être migrés ensemble.

Décisions de conception de la cible. La distribution des types d'appels détermine la structure du schéma relationnel cible. Une relation hiérarchique parent-enfant accessible exclusivement par des appels GU et GNP qualifiés par clé se traduit directement en une relation de clé étrangère dans la cible. La même relation, accessible par des appels GN avec dépendances positionnelles, exige que le schéma cible préserve un ordre équivalent, soit par une clause ORDER BY explicite, soit par un champ de séquence, soit par un autre modèle d'accès aboutissant au même résultat.

Décisions relatives au périmètre de validation. L'analyse identifie les programmes qui consomment les données IMS en lecture seule et ceux qui traitent les transactions. La validation des programmes en lecture seule s'effectue en comparant les résultats de sortie entre le système IMS d'origine et le système migré. Les processeurs de transactions nécessitent des tests d'équivalence transactionnelle afin de garantir que la même séquence d'opérations appliquée à la cible produise des modifications d'état des données équivalentes à celles du système d'origine.

Classification des risques. Les relations logiques et les résultats des indices secondaires constituent les principaux éléments d'entrée de la classification des risques. Chaque programme de migration dispose d'un registre des risques. L'analyse des dépendances du SIG indique à l'équipe les données à y consigner.

Comment SMART TS XL Effectue une analyse de dépendance IMS

SMART TS XL's analyse de code statique Ce module analyse les appels DL/I de chaque programme COBOL, qu'il s'agisse des interfaces EXEC DLI ou xxxTDLI, et extrait le code fonction, la référence PCB, le nom du segment et la structure SSA de chaque appel. Il génère ainsi l'inventaire complet des appels au niveau du programme, pour l'ensemble du parc COBOL, sans nécessiter de système IMS en fonctionnement ni de revue de code manuelle.

La cartographie des dépendances applicatives étend cet inventaire en un graphe de dépendances inter-programmes : quels programmes partagent l’accès à quelles bases de données IMS, quels programmes utilisent les mêmes PCB, et quels programmes présentent des chevauchements nécessitant une migration coordonnée. Lorsqu’une relation logique relie des segments entre bases de données, la cartographie des dépendances représente cette connexion inter-bases de données comme une relation explicite qui doit être préservée dans le système cible.

La fonctionnalité d'analyse d'impact répond à la question que toute équipe de migration doit se poser avant la conversion d'une base de données : si cette base de données IMS est migrée, quels programmes seront affectés, quels modèles d'accès devront être reproduits et quels cas de test devront être validés pour confirmer l'équivalence ? La réponse n'est pas une estimation, mais une liste exhaustive établie à partir de l'inventaire réel des appels DL/I.

La fonctionnalité d'extension JCL ajoute le contexte opérationnel : quelles étapes de traitement JCL invoquent quels programmes qui accèdent à IMS, dans quel ordre et avec quelles spécifications PSB. La chaîne de dépendances opérationnelles, c'est-à-dire la séquence de traitements par lots qui traite les données IMS via plusieurs programmes, est aussi importante pour la planification de la migration que les modèles d'accès au niveau des programmes. Migrer la base de données sans migrer l'orchestration des traitements par lots qui l'entoure produit un système qui traite correctement les enregistrements de manière isolée, mais qui échoue en production lors de l'exécution de la séquence de traitements.

Pour les équipes menant modernisation de l'héritage des systèmes soutenus par IMS, les preuves structurelles produites par SMART TS XL Il s'agit de l'élément d'entrée de chaque décision de migration ultérieure : quels programmes migrent dans quelle vague, quelles bases de données peuvent être converties indépendamment et lesquelles nécessitent une conversion coordonnée, quels modèles d'accès nécessitent une réarchitecture plutôt qu'une simple traduction. Comme décrit dans le contexte de migration des structures IMS et VSAM parallèlement aux programmes COBOLL'interconnexion entre les programmes COBOL et les structures de données existantes implique que la migration des données et l'analyse du code doivent se dérouler en parallèle ; l'inventaire des dépendances est le mécanisme qui rend possible la planification parallèle.

L'inventaire n'est pas la migration

L'analyse des dépendances IMS génère des connaissances. La migration exige toujours des décisions, de l'ingénierie et une validation. L'analyse modifie la qualité des décisions, l'exhaustivité du périmètre d'ingénierie et la fiabilité de la validation.

Les organisations qui réussissent la migration de leurs bases de données IMS ne sont pas celles qui ont les délais les plus serrés ni les budgets de migration les plus importants. Ce sont celles qui connaissaient parfaitement leurs données avant de commencer la migration : chaque programme accédant à chaque base de données, chaque code de fonction révélant le modèle d’accès de chaque programme, chaque relation logique créant des dépendances entre bases de données, chaque index secondaire fournissant un chemin d’accès qui ne pourrait être conservé lors de la conversion sans réplication explicite.

Ce savoir ne provient pas de la documentation. Il provient de l'analyse du code.