Analyse de la structure des fichiers VSAM pour les projets de modernisation des données

La migration des données ne peut se faire isolément ; elle doit évoluer en parallèle avec les applications COBOL qui lisent et écrivent ces ensembles de données. Cette contrainte définit tout le défi de la modernisation VSAM. VSAM (Virtual Storage Access Method) n'est pas un simple format de fichier. Il s'agit du contrat de données entre les programmes, la spécification implicite, définie uniquement dans les entrées FD et les clauses SELECT, qui régit la manière dont chaque programme d'un système d'entreprise produit et utilise ses données métier les plus critiques. Une simple modification de la structure d'un enregistrement, non répercutée dans tous les programmes qui lisent cet enregistrement, entraîne une corruption des données qui peut ne se manifester que lors de l'exécution d'un rapport réglementaire sur des données dont la signification n'est plus celle attendue par le programme consommateur.

Les organisations qui réussissent la modernisation de leurs données VSAM ne sont pas celles qui partent du schéma cible. Ce sont celles qui acquièrent une compréhension complète et étayée des fichiers VSAM : leur contenu, leur structure, les programmes qui y accèdent, les modalités d’accès et les contrats implicites entre producteurs et consommateurs. Cette compréhension, l’analyse de la structure des fichiers VSAM, est indispensable à toute décision ultérieure : quels ensembles de données VSAM correspondent à des tables relationnelles, lesquels requièrent des architectures cibles différentes, quels formats d’enregistrement nécessitent des conversions de types de données préservant la précision, et quels ensembles de données partagés doivent migrer de manière coordonnée plutôt qu’indépendamment.

Les quatre organisations VSAM et leurs exigences

Les jeux de données VSAM se répartissent en quatre organisations distinctes. Chacune présente des caractéristiques structurelles, un mode d'accès typique et une correspondance naturelle avec les architectures cibles modernes qui lui sont propres. Traiter tous les jeux de données VSAM de manière identique, en les convertissant en masse en tables relationnelles, produit des cibles fonctionnelles pour certains jeux de données, mais peu performantes, voire dysfonctionnelles, pour d'autres.

KSDS (Key-Sequenced Data Set) est l'organisation VSAM la plus courante. Les enregistrements sont ordonnés physiquement selon une clé primaire, permettant un accès direct par clé et un accès séquentiel par ordre de clé. Les fichiers KSDS peuvent contenir des index alternatifs, ou chemins de clés secondaires, permettant la récupération par des champs autres que la clé primaire. Un fichier KSDS est naturellement destiné à être stocké dans une table relationnelle, où la clé primaire devient la clé principale et les index alternatifs deviennent des index SQL.

Un ESDS (Entry-Sequenced Data Set) stocke les enregistrements dans l'ordre de leur écriture. Sans clé, les enregistrements sont adressés par leur position en octets (RBA : Relative Byte Address). Les fichiers ESDS sont généralement utilisés pour les données de type journal : journaux d'audit, journaux de transactions, flux d'événements. Selon le mode d'accès aux données par les programmes consommateurs, un ESDS peut être une table relationnelle en mode ajout uniquement, un flux d'événements (sujet Kafka) ou une base de données de séries temporelles.

Le format RRDS (Relative Record Data Set) stocke des enregistrements de longueur fixe, identifiés par leur numéro relatif. Chaque emplacement du fichier correspond à un numéro d'enregistrement ; les emplacements peuvent être vides (supprimés). Les fichiers RRDS sont utilisés pour les applications à accès direct où le numéro d'enregistrement est pertinent, souvent comme tables de consultation simples ou comme système de stockage basé sur le hachage. L'objectif naturel est une table relationnelle avec un identifiant numérique séquentiel, ou une structure de consultation en mémoire si l'ensemble de données est petit et fréquemment consulté.

LDS (Linear Data Set) est un format de stockage adressable par octet dont la structure d'enregistrement n'est pas visible par VSAM. Il est utilisé par les applications (généralement DB2, des charges de travail Java ou des programmes personnalisés) qui gèrent leur propre format interne dans la plage d'octets VSAM. Les fichiers LDS ne peuvent pas être analysés via les entrées FD COBOL standard ; leur structure n'existe que dans la couche application qui les écrit.

Les résultats d'analyse de chaque ensemble de données doivent identifier l'organisation utilisée, car celle-ci détermine tout en aval : l'architecture cible, le modèle d'accès et l'analyse spécifique requise pour comprendre sa structure.

Le problème d'analyse de la mise en page des enregistrements

L'organisation des enregistrements est la dimension la plus complexe de l'analyse de la structure VSAM. Contrairement à un schéma relationnel où chaque colonne possède un type, un nom et une contrainte définis par le moteur de base de données, les enregistrements VSAM n'ont pas de structure auto-descriptive. L'organisation est entièrement définie dans l'entrée FD COBOL, et ces entrées sont rarement simples.

Entrées FD et membres COPY

La structure d'enregistrement d'un fichier VSAM est définie dans l'entrée FILE DESCRIPTION (FD) de la COBOL DATA DIVISION. Dans les bases de code bien maintenues, l'entrée FD fait référence à un membre COPY, un copybook partagé qui définit la disposition des enregistrements et qui est inclus par chaque programme accédant au fichier.

Cobol

       FILE SECTION.
       FD  CUSTOMER-FILE
           LABEL RECORDS ARE STANDARD
           RECORD CONTAINS 250 CHARACTERS.
       01  CUSTOMER-RECORD.
           COPY CUSTMSTR.

Le membre COPY CUSTMSTR définit la configuration réelle du champ. Si 47 programmes sont inclus CUSTMSTR, alors 47 programmes partagent une dépendance à la structure d'enregistrement qu'il définit. Un renommage de champ dans CUSTMSTR Cela affecte les 47. Il s'agit du problème de couplage du copybook appliqué aux données : la disposition des enregistrements VSAM est une dépendance partagée qui ne peut pas changer sans coordonner chaque programme qui l'utilise.

Pour l'analyse des migrations, chaque entrée de dépendance fonctionnelle (FD) doit être associée à son copybook, et chaque copybook doit être mappé à chaque programme qui l'inclut. Le graphe de dépendances de la disposition partagée est essentiel pour comprendre la portée des migrations.

REDÉFINITIONS : Plusieurs mises en page, un seul enregistrement

Le REDEFINES C’est dans cette clause que l’analyse des enregistrements VSAM devient véritablement complexe. REDEFINES permet à différentes interprétations de champs de se superposer au même stockage physique. Un enregistrement VSAM contenant un code de type de transaction peut utiliser REDEFINES pour interpréter différemment les octets restants en fonction de ce code.

Cobol

       01  TRANSACTION-RECORD.
           05  TXN-TYPE        PIC X(2).
           05  TXN-COMMON-DATA PIC X(48).
           05  TXN-DETAIL      REDEFINES TXN-COMMON-DATA.
               10  TXN-PAYMENT.
                   15  PAY-AMOUNT     PIC S9(11)V99 COMP-3.
                   15  PAY-CURRENCY   PIC X(3).
                   15  PAY-METHOD     PIC X(2).
                   15  FILLER         PIC X(28).
           05  TXN-WITHDRAWAL  REDEFINES TXN-COMMON-DATA.
               10  WDR-AMOUNT     PIC S9(11)V99 COMP-3.
               10  WDR-ACCOUNT    PIC 9(12).
               10  WDR-BRANCH     PIC 9(5).
               10  FILLER         PIC X(18).

Ce disque possède non pas une seule mise en page, mais trois, selon le TXN-TYPEDans le schéma relationnel cible, cela nécessite généralement soit une conception de table polymorphe (table unique avec des colonnes pouvant contenir des valeurs nulles pour chaque variante), soit une conception normalisée (ligne parente et lignes enfants spécifiques au type), soit une colonne JSON contenant les données de variante. Aucune de ces décisions ne peut être prise sans analyser ce qui TXN-TYPE des valeurs existent dans les données et quelles variantes REDEFINES sont réellement utilisées.

Une analyse complète de la structure des enregistrements doit :

• Identifiez chaque hiérarchie REDEFINES dans chaque entrée FD
• Déterminer quelle variante REDEFINES est active et dans quelles conditions (nécessite une analyse de la logique du programme, et pas seulement une analyse des diagrammes de dépendances).
• Documentez les types de champs, leurs longueurs et la précision décimale compressée pour chaque variante.
• Recommander la stratégie de normalisation appropriée pour le schéma cible

COMP-3 et précision numérique

COBOL PIC S9(11)V99 COMP-3 (décimal compacté) possède des caractéristiques de précision et d'échelle spécifiques qui n'ont pas d'équivalent direct dans les types de données standard SQL. V indique une virgule décimale implicite, la valeur est stockée sous forme d'entier avec une échelle implicite de 2 décimales. COMP-3 Il contient deux chiffres décimaux par octet, le dernier demi-octet contenant le signe.

Lorsque ce champ est migré vers une base de données relationnelle, la cible SQL correcte est DECIMAL(13, 2), Pas FLOAT, ce qui introduirait des erreurs d'arrondi, et non INTEGER, ce qui entraînerait la perte des décimales. Pour les systèmes financiers où les champs COMP-3 contiennent des montants monétaires, l'exigence de précision est non négociable. Une migration qui convertit PIC S9(11)V99 COMP-3 La conversion en un type à virgule flottante dans le schéma cible introduit des erreurs d'arrondi qui s'accumulent au fil des exécutions par lots et peuvent affecter les rapports réglementaires.

Chaque champ COMP-3 de chaque entrée FD doit être documenté avec sa précision exacte, son échelle et sa convention de signe avant que la conception du schéma cible ne commence.

Analyse des modèles d'accès VSAM dans le code source COBOL

L'entrée FD décrit le contenu de l'enregistrement. La division de procédure COBOL décrit comment le programme l'utilise. Ces deux éléments sont nécessaires pour une analyse structurelle complète. L'analyse des modèles d'accès examine chaque verbe d'accès aux fichiers dans chaque programme qui accède à l'ensemble de données.

Clause SELECT : Premier signal

La clause SELECT dans la DIVISION ENVIRONMENT établit comment le programme COBOL accédera au fichier VSAM :

Cobol

       ENVIRONMENT DIVISION.
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT CUSTOMER-FILE
               ASSIGN TO CUSTFILE
               ORGANIZATION IS INDEXED
               ACCESS MODE IS DYNAMIC
               RECORD KEY IS CUST-PRIME-KEY
               ALTERNATE RECORD KEY IS CUST-ALT-KEY
                   WITH DUPLICATES
               FILE STATUS IS WS-CUST-STATUS.

Cette clause SELECT révèle :

• ORGANIZATION IS INDEXED → KSDS
• ACCESS MODE IS DYNAMIC → Le programme utilise à la fois l'accès séquentiel et aléatoire
• ALTERNATE RECORD KEY IS CUST-ALT-KEY WITH DUPLICATES → Un index alternatif existe et ce programme l'utilise.

Le mode d'accès dynamique est particulièrement important : un programme qui accède à un KSDS en mode DYNAMIQUE peut utiliser READ avec une clé pour un accès direct et READ NEXT Pour une analyse séquentielle à partir d'un point positionné, les deux modes d'accès doivent être reproduits dans la cible, ce qui peut nécessiter la prise en charge à la fois de la recherche directe (requête par clé primaire) et de l'analyse par plage (parcours ordonné) dans le schéma relationnel.

Les verbes d'accès et leurs implications en matière de migration

Chaque verbe d'accès aux fichiers révèle une dimension différente de la façon dont le programme interagit avec l'ensemble de données VSAM :

LIRE (directement) : READ CUSTOMER-FILE KEY IS WS-CUST-KEY, recherche directe par clé. Correspond à SELECT ... WHERE primary_key = ?La plupart des programmes KSDS utilisent ce modèle ; il se traduit directement par une recherche indexée relationnelle.

LIRE (séquentiel) : READ CUSTOMER-FILE NEXT RECORD, balayage séquentiel à partir de la position actuelle. Correspond à SELECT ... ORDER BY primary_key avec positionnement du curseur. La dépendance d'ordre implicite, les programmes qui s'appuient sur l'ordre naturel des clés VSAM pour le traitement séquentiel, doivent être explicitement préservés dans la cible.

DEMARREUR: START CUSTOMER-FILE KEY >= WS-SEARCH-KEY suivie par READ NEXT, analyse de plage à partir d'une position de clé partielle. Correspond à une requête de plage : SELECT ... WHERE primary_key >= ? ORDER BY primary_keyLes programmes utilisant START établissent une limite inférieure pour l'analyse séquentielle ; il s'agit d'un modèle d'accès critique pour les fichiers KSDS qui n'a pas d'équivalent simple à moins que la table cible n'ait le même ordre de clés.

ÉCRIRE: Insère un nouvel enregistrement par clé. Correspond à INSERT INTOSi le fichier VSAM comporte des index alternatifs, l'écriture doit maintenir la cohérence avec ces index ; dans VSAM, cela est automatique ; dans une base de données relationnelle, cela nécessite soit un déclencheur de base de données, soit du code au niveau de l'application pour maintenir des tables d'index secondaires équivalentes.

RÉCRIRE: Met à jour un enregistrement sur place. L'enregistrement doit être actuellement conservé (après une lecture avec intention de conservation). Correspond à UPDATE ... WHERE primary_key = ?.REWRITE est un modèle de lecture-modification-écriture ; la migration doit préserver l’intégrité transactionnelle entre la lecture et l’écriture.

SUPPRESSION : Supprime un enregistrement par sa clé. Dans les fichiers KSDS, la suppression est physique. Les programmes qui s'attendent à ce que l'emplacement supprimé soit indisponible pour les analyses séquentielles ultérieures dépendent de ce comportement. Une suppression logique (indicateur de suppression logique) dans la cible ne produit pas le même résultat, sauf si chaque programme utilisateur est mis à jour pour filtrer les enregistrements supprimés logiquement.

Utilisation alternative de l'index : La dépendance cachée

Les index alternatifs des fichiers KSDS constituent l'une des dépendances les plus souvent négligées lors de la migration VSAM. Un index alternatif permet à un programme d'accéder à un fichier KSDS par un champ autre que la clé principale. Cet index alternatif est lui-même un jeu de données VSAM distinct (un chemin d'accès) qui doit être maintenu synchronisé avec le cluster de base.

Un programme qui accède à CUSTOMER-FILE par sa clé alternative CUST-ALT-KEY présente une dépendance invisible si seule l'entrée FD du cluster de base est analysée. La migration doit :

1. Identifiez les programmes qui utilisent quelles clés alternatives (visibles dans la clause SELECT). ALTERNATE RECORD KEY déclarations)
2. Associez chaque clé alternative à l'index SQL équivalent sur la table cible.
3. Assurez-vous que les opérations INSERT et DELETE sur la table cible conservent automatiquement l'équivalent de l'index alternatif, généralement via des index SQL uniques ou non uniques que le moteur de base de données gère de manière transparente.

L'analyse doit recenser chaque index alternatif pour chaque ensemble de données KSDS et associer chacun à ses programmes consommateurs.

Le problème des ensembles de données partagés : contrats de données implicites

Les fichiers VSAM sont fréquemment partagés entre plusieurs programmes et étapes de travaux JCL. Ce partage crée des contrats de données implicites, des accords entre programmes concernant la structure des enregistrements, les plages de clés et les modèles d'accès, qui n'existent nulle part ailleurs que dans le code lui-même.

La dépendance entre les jeux de données partagés comporte deux dimensions :

Relations producteur-consommateur. Le programme A écrit des enregistrements que le programme B lit. La structure, les valeurs clés et l'ordre des enregistrements produits par le programme A doivent correspondre exactement à ce que le programme B s'attend à lire. Si A et B sont migrés indépendamment vers des schémas cibles différents sans coordination du contrat de données partagé, il en résulte une corruption silencieuse des données : les lectures effectuées par B sur la base de données cible réussissent, mais les données renvoyées sont dans un format que la logique de B ne peut pas gérer correctement.

Accès concurrent entre les étapes d'un travail. Un flux de travaux JCL peut comporter plusieurs étapes, chacune exécutant un programme différent sur le même jeu de données VSAM, de manière séquentielle. L'étape 1 écrit les données, l'étape 2 les lit et les transforme, et l'étape 3 écrit les résultats. La migration doit préserver cette dépendance séquentielle ; l'ordre dans lequel les programmes accèdent au jeu de données partagé et le modifient fait partie des spécifications comportementales du système.

Une analyse complète d'un ensemble de données partagées doit :

• Énumérer tous les jeux de données VSAM et tous les programmes qui y accèdent.
• Classer l'accès de chaque programme comme producteur (ÉCRITURE/RÉÉCRITURE/SUPPRESSION), consommateur (LECTURE) ou les deux.
• Documentez le contexte de tâche JCL dans lequel chaque programme s'exécute : étape, tâche et chaîne de dépendances du planificateur.
• Identifier les paires producteur-consommateur pour lesquelles le format de sortie du producteur doit correspondre exactement au format d'entrée attendu par le consommateur.

Cette analyse ne peut être réalisée en examinant un seul programme isolément. Elle nécessite une analyse structurelle transversale, à l'échelle des programmes et du JCL.

Livrables préalables à la migration : résultats attendus de l’analyse

Une analyse structurelle VSAM suffisante pour la planification de la modernisation des données produit six livrables :

Livrable 1 : Inventaire des ensembles de données VSAM

Chaque ensemble de données VSAM de l'environnement, avec : organisation de l'ensemble de données (KSDS/ESDS/RRDS/LDS), longueur moyenne et maximale des enregistrements, nombre d'enregistrements estimé (à partir des paramètres JCL SPACE ou des entrées du catalogue), structure de clé (décalage de la clé primaire, longueur ; structures de clé alternatives) et si l'ensemble de données possède des index alternatifs.

Livrable 2 : Catalogue de mise en page des enregistrements

Pour chaque ensemble de données, chaque entrée FD et les copybooks auxquels elle fait référence, avec : toutes les définitions de champ, y compris les hiérarchies REDEFINES, chaque champ COMP-3 avec sa précision et son échelle exactes, chaque champ binaire (COMP/COMP-5) avec sa longueur en octets, chaque élément de longueur variable (OCCURS DEPENDING ON avec son champ de contrôle), et chaque variante conditionnelle ou de mise en page impliquée par REDEFINES.

Livrable 3 : Classification des modèles d’accès par programme

Pour chaque programme qui accède à chaque ensemble de données : les caractéristiques de la clause SELECT (organisation, mode d’accès, utilisation de clés alternatives), l’ensemble complet des verbes d’accès utilisés (READ/START/WRITE/REWRITE/DELETE), si le programme utilise un accès séquentiel et dépend de l’ordre des clés, quels index alternatifs le programme utilise et si le programme a des modèles de lecture-modification-écriture (exigences de transaction implicites).

Livrable 4 : Carte des données partagées

Un graphe orienté dont les nœuds représentent les ensembles de données et les programmes VSAM, et les arêtes les relations d'accès avec leur type (lecture/écriture). Le graphe affiche chaque producteur, chaque consommateur, les paires producteur-consommateur et le contexte de séquence de tâches JCL pour chaque accès.

Livrable 5 : Recommandations relatives au schéma cible

Pour chaque ensemble de données VSAM, l'architecture cible recommandée est basée sur son organisation et ses modèles d'accès :

Type VSAM	Modèle d'accès principal	Cible recommandée
KSDS, accès direct par clé uniquement	Recherche de points par clé primaire	Table relationnelle, indexée
KSDS, avec DÉMARRER/LIRE LA SUITE	Analyses de portée dans l'ordre clé	Table relationnelle avec index clusterisé
KSDS avec index alternatifs	Accès par clé multi-chemin	Table relationnelle avec plusieurs index
ESDS, ajout uniquement	Ajout séquentiel, sans clé	Tableau en mode ajout uniquement, flux d'événements ou journal
ESDS, avec accès RBA	Positionnement par décalage d'octet	Stockage d'objets avec index de métadonnées
RRDS	Accès au numéro d'enregistrement	Table relationnelle avec colonne de séquence
KSDS grand format (en vrac, analytique)	Numérisations séquentielles complètes	Stockage en colonnes ou lac de données
LDS	Format interne géré par l'application	Nécessite une analyse de la couche application

Livrable 6 : Registre de terrain sensible à la précision

Chaque champ COMP-3, COMP, COMP-5 et à virgule flottante de chaque ensemble de données, avec sa définition COBOL, le mappage de type de données SQL correct et un indicateur pour tout champ dont le mappage nécessite une validation de précision avant et après la migration.

Qu'est-ce qui différencie l'analyse VSAM de l'analyse de schéma relationnel ?

Les équipes ayant l'habitude de migrer entre bases de données relationnelles sous-estiment parfois l'analyse VSAM car elles appliquent le modèle mental de la migration de schéma : extraire le DDL, repenser le schéma, migrer les données. VSAM ne possède pas de DDL au sens des bases de données. Le schéma est distribué dans le code source, dans les entrées FD, dans les copybooks, dans les clauses SELECT et dans la logique de la PROCEDURE DIVISION qui détermine quelle variante REDEFINES est active pour chaque enregistrement.

Trois propriétés confèrent à l'analyse VSAM une structure différente :

Le schéma est intégré au code. La structure des enregistrements d'un fichier VSAM est définie dans le code source COBOL, et non dans un catalogue de base de données. Pour la trouver, il faut analyser le code source. La modifier exige la coordination de tous les programmes qui partagent le même copybook. Comprendre toutes ses variantes nécessite d'analyser la logique du programme, et pas seulement l'entrée du descripteur de fichier.

Les schémas d'accès sont implicites dans le comportement des programmes. Une base de données relationnelle expose les schémas de requêtes via les plans EXPLAIN et les journaux de requêtes. Les schémas d'accès VSAM ne sont visibles que dans la PROCEDURE DIVISION des programmes qui accèdent au fichier. Déterminer si un programme dépend de l'ordre des clés, de l'accès à un index alternatif ou de l'analyse par plage nécessite une analyse du code.

Les ensembles de données partagés créent des contrats implicites. Dans une base de données relationnelle, le schéma est un artefact de niveau base de données partagé et visible par tous les utilisateurs. Dans VSAM, la structure des enregistrements est intégrée au copybook de chaque programme. Deux programmes peuvent avoir des copies différentes d'une structure d'enregistrement pourtant identique ; détecter cette divergence nécessite de comparer les définitions des copybooks entre les programmes, et non d'examiner une seule définition de schéma.

Comment SMART TS XL Effectue une analyse structurelle VSAM

SMART TS XL's analyse de code statique L'analyse examine chaque élément de la structure VSAM présent dans le code source COBOL : entrées FD, expansions de membres COPY, déclarations de clauses SELECT (organisation, mode d'accès, spécifications des clés primaire et alternative) et chaque verbe d'accès aux fichiers dans la PROCEDURE DIVISION. Pour chaque ensemble de données VSAM, elle produit la classification des modèles d'accès, la structure des enregistrements avec une résolution REDEFINES complète et le registre des champs COMP-3 avec des métadonnées précises.

Le mappage des dépendances applicatives construit la carte des jeux de données partagés : chaque programme accédant à chaque jeu de données VSAM est classé par type d’accès, les relations producteur-consommateur sont identifiées et le graphe de partage des copybooks est résolu. Lorsque 47 programmes partagent un copybook définissant la structure d’un enregistrement VSAM, la carte des dépendances les rend tous visibles avant toute décision de migration, et non après qu’une modification de la structure ait perturbé leur fonctionnement de manière inattendue.

La fonctionnalité d'expansion JCL fournit le contexte opérationnel : quelles étapes de tâche JCL référencent quels fichiers VSAM dans leurs instructions DD, dans quel ordre et dans quels flux de tâches. Les relations producteur-consommateur existant au niveau de la tâche JCL (l'étape 1 écrit dans un fichier VSAM que l'étape 3 lit) sont visibles dans l'analyse des dépendances JCL, permettant ainsi un séquencement de migration qui préserve les dépendances d'ordre opérationnel imposées par la planification des traitements par lots.

La fonctionnalité d'analyse d'impact répond à la question qui précède toute décision de migration VSAM : si la structure de cet ensemble de données change, quels programmes sont affectés ? Le périmètre d'impact, c'est-à-dire chaque programme partageant le copybook concerné et chaque étape JCL référençant l'ensemble de données, est recensé avant toute migration. Ceci permet une planification coordonnée de la migration, évitant ainsi la découverte progressive des programmes affectés.

La capacité de recherche d'entreprise permet d'interroger l'intégralité de l'inventaire VSAM tout au long du programme de modernisation : trouvez en quelques secondes, sur des millions de lignes de COBOL, chaque programme qui accède à un ensemble de données VSAM spécifique, chaque copybook qui définit une mise en page d'enregistrement spécifique, chaque programme qui utilise des modèles START/READ NEXT (indiquant des dépendances d'ordre), chaque champ défini comme COMP-3 (nécessitant un mappage cible précis).

Comme décrit dans le contexte de migration des structures de données IMS et VSAM parallèlement aux programmes COBOLLa migration des données et l'analyse du code doivent être menées en parallèle. SMART TS XLL'analyse structurelle VSAM de [Nom de l'entreprise] fournit l'inventaire qui rend ce parallélisme gérable, les structures d'enregistrement partagées, les modèles d'accès et les relations producteur-consommateur qui déterminent si la migration des données peut se dérouler indépendamment ou doit être coordonnée avec les modifications du programme.

La structure que vous comprenez est celle que vous pouvez faire migrer.

L'analyse de la structure des fichiers VSAM n'est pas une tâche superflue dans un programme de modernisation. Elle constitue le fondement de la prise de décision. Le schéma cible ne peut être conçu sans connaître les variantes de mise en page des enregistrements. La migration ne peut être séquencée sans connaître les relations producteur-consommateur. La précision des champs COMP-3 ne peut être préservée sans savoir quels champs requièrent des types cibles compatibles avec les nombres décimaux.

Tout programme de modernisation qui néglige cette analyse découvre ses erreurs lors de l'exécution de la migration : par exemple, une variante REDEFINES non analysée génère des enregistrements malformés dans la cible ; la migration d'un jeu de données partagé sans coordination de tous ses utilisateurs ; ou encore, une analyse par plage basée sur l'ordre des clés de VSAM renvoie un ordre indéfini dans une table cible non conçue avec un index cluster. Ces découvertes en cours d'exécution coûtent bien plus cher que l'analyse effectuée lors de la planification.

Il est essentiel de comprendre d'abord la structure, puis de migrer les données. Cette séquence n'est pas une simple formalité : elle fait toute la différence entre une migration réussie et une migration dont les données semblent correctes jusqu'au premier audit réglementaire.