Bob rencontre le mainframe

Quand nous avons lancé Bob, nous avons dit que le vrai problème n'était pas d'écrire du nouveau code mais de travailler dans un système qui existe déjà — trouver le bon endroit pour effectuer un changement, respecter des conventions établies des années auparavant, maintenir la cohérence du comportement à travers des fichiers qui grossissent depuis longtemps.

La version la plus ancienne d'un « système qui existe déjà » tourne sur un mainframe. Des décennies de COBOL et de PL/I, des millions de lignes, des dizaines de milliers de programmes interconnectés via Db2, CICS, IMS et des planificateurs batch — du code qui fait tourner l'entreprise sans interruption qu'elle ne peut pas se permettre.

Aujourd'hui, nous rendons IBM Bob Premium Package for Z (Bob PP4Z) généralement disponible. Il remplace IBM watsonx Code Assistant for Z et apporte l'expertise IBM Z — langages de la plateforme, connaissance du middleware et analyse déterministe à l'échelle de l'entreprise — directement dans l'expérience Bob.

Ceci est l'histoire d'ingénierie, pas une présentation de fonctionnalités. Plutôt que de lister tout ce que PP4Z fait, nous voulons accomplir trois choses :

Expliquer pourquoi un modèle généraliste se trompe sur tes applications mainframe plus souvent qu'il ne l'admet.
Montrer comment nous ancrons Bob dans des faits déterministes sur ton environnement plutôt que dans des probabilités.
Parcourir les modes, skills et workflows spécifiques à Z — et ce que tu peux construire avec eux.

1. Pourquoi le mainframe est le cas difficile

Un modèle généraliste pointé vers un environnement mainframe rencontre trois problèmes qu'aucun prompting intelligent ne résout vraiment. Le design de PP4Z apporte des solutions à chacun.

1.1. L'échelle et ce qu'elle fait à une fenêtre de contexte

Une seule application métier peut représenter des millions de lignes de COBOL, des dizaines de milliers de modules interconnectés en COBOL, PL/I et assembleur, et des milliers de traitements batch chaînés par un planificateur d'entreprise. Même un « petit » ensemble de 200 programmes représente facilement des centaines de milliers de lignes.

Ça ne rentre pas dans une fenêtre de contexte, et le problème ne se limite pas à la fenêtre. Plus le contexte grandit, plus les performances du modèle se dégradent (Chroma Research Context Rot Study, 2025) — les réponses deviennent incomplètes, incohérentes ou faussement assurées. Inclure « les fichiers pertinents » suppose que tu sais déjà lesquels le sont — ce que tu cherchais précisément à découvrir.

1.2. La signification qui n'est pas dans le code

Le code mainframe est sémantiquement dense. Le sens métier vit dans les noms de champs et des décennies de conventions, pas dans quelque chose qu'un analyseur peut lire. Quelques éléments se devinent — SERIALN est probablement un numéro de série, TOT-STTM probablement un règlement total. La plupart non : qu'est-ce que C-M ? M-CAP ? Pourquoi le préfixe CCZD ? Qu'est-ce qui distingue NO-SIN, NO-EVN et NO-CNT ?

La signification est réelle et structurelle, mais elle ne peut pas être devinée à partir du code seul. La réponse traditionnelle est un dictionnaire de données — mais l'échelle (des millions, voire des milliards de variables) rend difficile la construction à la main ou par force brute avec un modèle de langage.

1.3. La réponse la plus probable n'est pas la bonne réponse

Un modèle de langage renvoie ce qui est statistiquement probable. Les modèles sont non déterministes ; la même question peut obtenir des réponses différentes selon les jours. Sur un système où une mauvaise réponse sur le flux de contrôle peut fausser la logique métier, c'est un risque significatif.

C'est un scénario que tu as probablement rencontré toi-même, en supposant que tu l'aies reconnu. Prends une vraie application batch COBOL : 233 programmes, 742 copybooks, plus de 20 Mo de code, avec un utilitaire de date très sollicité, N991DATE. Les métadonnées indiquent que 30 programmes l'appellent. Interroge maintenant directement un modèle frontier :

Jour 1. Il ne peut pas tout charger, donc il cherche les instructions CALL statiques et signale 13. Interrogé sur les appels dynamiques, il élargit la regex et signale 29. Celui qu'il rate, CHKOUTB, se trouve dans un fichier nommé ROCHKOUT.cbl — car par convention un nom de fichier correspond généralement à son PROGRAM-ID, mais ce n'est jamais obligatoire.
Jour 2. Même question, heuristiques différentes, et il signale maintenant 31 — sur-comptage. Un faux positif, N285RODR, se contente de déclarer le littéral 'N991DATE' dans le working storage et ne l'utilise jamais. Le modèle n'arrive à cette conclusion qu'après plusieurs relances.

Aucune de ces heuristiques n'est déraisonnable. Elles sont simplement insuffisantes, et « qui appelle X » est l'une des questions centrales lors de l'analyse d'impact et de la compréhension des programmes. Les questions plus avancées — quelles tables sont mises à jour dans plus d'un programme, quels fichiers sont lus mais jamais écrits, quelles variables alimentent le calcul de WS-UIT02 dans PREMPZ72 — nécessitent une analyse complète et précise que la correspondance de motifs ne peut pas fournir.

La conclusion n'est pas « les modèles ne sont pas utiles pour comprendre les programmes mainframe ». C'est que la qualité des réponses s'améliore considérablement quand il y a quelque chose de vrai sur quoi raisonner. Les modèles de langage excellent dans le traitement des données.

2. Ancrer Bob dans les faits, pas les probabilités

La réponse de PP4Z est d'arrêter de demander au modèle de reconstruire le système depuis le code source, et de lui donner à la place une représentation déterministe et interrogeable de l'environnement pour raisonner dessus. Trois mécanismes assurent l'ancrage : le modèle reçoit pour instruction de signaler les constructions z/OS ambiguës dans la requête elle-même ; les prompts sont enrichis d'insights IBM Z faisant autorité, de documentation IBM, de matériel de référence, d'exemples vérifiés et plus encore, avec les biais de programmation généraliste activement supprimés ; et le modèle reçoit pour instruction de répondre en priorité depuis les métadonnées d'analyse. L'objectif est de rendre les réponses traçables au système IBM Z, pas à une distribution d'entraînement.

2.1. Z Understand : un modèle interrogeable de ton environnement

Z Understand est la plateforme d'analyse statique sous PP4Z. Elle tourne sur un serveur avec accès à toute ta source, embarque des scanners pour COBOL, PL/I et assembleur ainsi que JCL et des planificateurs comme Control-M et TWS, et traite des milliers de programmes en parallèle dans un dépôt interrogeable. Elle maintient une structure déterministe et cohérente sur des environnements de 10 000+ programmes.

Il est utile de la concevoir comme une pipeline de compilation avec une sortie différente : pas un exécutable, mais de la connaissance structurée et interrogeable — définitions de données, flux de contrôle entre programmes et traitements, flux de données précis (y compris REDEFINES et offsets mémoire) et interactions de sous-systèmes.

2.2. Laisser le modèle écrire ses propres requêtes

La façon dont les métadonnées sont exposées est aussi importante que les métadonnées elles-mêmes. Les APIs fixes et les patterns de requêtes MCP prédéfinis sont très efficaces pour les questions connues et attendues, mais échouent lors d'une analyse ouverte. Au cours d'une analyse ouverte, une vraie question se ramifie en de nombreuses sous-requêtes qui évoluent à mesure que le raisonnement progresse.

Nous avons donc appris à Bob à aller au-delà des requêtes prédéfinies et à générer et exécuter ses propres requêtes contre les métadonnées. Cela s'appuie sur ce que les modèles font vraiment bien — le raisonnement et la génération de requêtes — et cela s'adapte comme les données structurées s'adaptent : que tu aies 10 ou 10 000 programmes, la requête est la même ; seul l'ensemble de résultats grandit.

2.3. Extensibilité, scanners personnalisés et données d'exécution

L'analyse purement syntaxique manque les relations qui comptent quand des appels dynamiques, des abstractions d'API et des préprocesseurs cachent le vrai flux. Le framework Z Understand Extensibility comble cette lacune :

Résolution d'appels API / macros mappe les appels indirects et paramétriques vers leurs vraies cibles, remplaçant des arêtes d'appel génériques par des relations concrètes appelant–appelé, via une config JSON ou des user exits.
Extensibilité des préprocesseurs interprète les instructions non standard en préservant la vue source originale, mappant proprement entre code pré- et post-traité.
Scanners personnalisés intègrent des langages propriétaires, des 4GLs et même des sources non-code dans un modèle unique via une interface JSON pilotée par schéma.

L'analyse statique te dit ce qui peut arriver ; les données d'exécution te disent ce qui s'est passé. PP4Z transforme le débogueur en instrument de collecte de données et remet ces traces précises à Bob.

2.4. Le dictionnaire de données : la pertinence plutôt que l'exhaustivité

Documenter des milliards de variables n'est ni faisable ni maintenable, donc PP4Z n'essaie pas. L'analyse déterministe classe les variables selon leur impact réel sur le comportement — fréquence d'utilisation, répartition dans les régions de code, participation au flux de contrôle, interaction avec les bases de données et les E/S — et sélectionne le petit ensemble qui révèle le but d'un programme.

Le résultat utile ici : une couverture limitée suffit. Définir environ les 10 à 20 premières variables par programme améliore matériellement la compréhension sans documentation exhaustive. Z Understand Services automatise cela sur des portefeuilles entiers depuis la CLI, un score de confiance ne conserve que les définitions au-dessus d'un seuil, et une étape human-in-the-loop dans l'IDE permet aux développeurs de réviser, corriger et aligner la sortie avec les glossaires existants.

3. Spécialiser Bob pour Z

L'ancrage donne à Bob de bons faits. La spécialisation est ce qui le rend prévisible dans un environnement où les outputs doivent être explicables et les processus doivent satisfaire la gouvernance. PP4Z repose sur quatre éléments : modes, outils, skills et workflows.

Les modes définissent le rôle et les limites d'un flux d'interaction. Un mode architecte priorise l'analyse, la documentation et la découverte des dépendances, la modification de code étant explicitement interdite. Un mode développeur est optimisé pour la génération et le refactoring avec l'application des standards de codage intégrée.
Les outils donnent au modèle un accès direct à la connaissance structurée du système — scan de programmes, interrogation de métadonnées, recherche dans le dictionnaire de données, services d'analyse à l'échelle de l'entreprise.
Les skills codifient l'expertise récurrente en étapes répétables et auditables. Le skill de planification d'implémentation, par exemple, impose une séquence fixe : acquérir et valider le contexte, formuler les exigences, cartographier l'impact depuis les métadonnées, puis produire un plan persisté et révisable.
Les workflows ajoutent une orchestration avec état — imposant l'ordre, validant les résultats intermédiaires, s'arrêtant sur une mauvaise entrée. Le workflow du dictionnaire de données s'arrête s'il ne trouve pas de variables plutôt que d'en inventer.

Les standards et la gouvernance sont appliqués par défaut via les règles agents.md au niveau du dépôt. Tu peux aussi créer tes propres skills, sans écrire de code.

Quand tout cela se combine, un seul prompt peut piloter une tâche de bout en bout :

« Ajoute une colonne à la Motor Policy Table qui capture si le véhicule est électrique. Applique mes standards de codage et mets à jour tous les programmes impactés. »

Bob lit l'intention, construit un plan, sélectionne les bons modes, skills et règles de dépôt, et exécute en toute sécurité les outils nécessaires — gouvernance, exécution et raisonnement en une seule passe, avec ton approbation des changements.

4. Ce que tu peux construire aujourd'hui

Documentation qui ne se désynchronise pas. Traite les docs comme un artefact généré ancré dans des métadonnées déterministes plus le contexte source et d'exécution — régénérable à la demande, aligné sur le système actuel.
Transition COBOL vers Java déterministe sur z/OS. PP4Z utilise les métadonnées comme colonne vertébrale de la transformation, construisant des modèles parallèles de la source et de la cible pour que l'architecture soit reproductible et la logique métier mappée avec précision.
Refactoring ciblé et extraction de fonctions. Bob produit une liste priorisée de candidats au refactoring annotés avec leur fonction métier, puis extrait des modules autonomes avec des entrées et sorties claires.
Outillage natif z/OS. Capacités Z Open Editor plus nouveaux outils MCP : Dependency Based Build (DBB), Z Code Scan et IBM Debug for z/OS pour transformer les sessions de débogage en direct en analyse de cause racine assistée par IA.

Une note d'honnêteté, puisque c'est un post d'ingénierie : rien de tout cela ne retire le développeur de la boucle, et ce n'est pas l'intention. Les modes, les portes d'approbation et le dictionnaire de données human-in-the-loop existent tous parce que sur ces systèmes « à peu près juste » est le mode d'échec, pas l'objectif.

5. Comment obtenir l'accès

Bob Premium Package for Z (PP4Z) est un module complémentaire d'IBM Bob, pas un produit séparé à télécharger. PP4Z fonctionne contre un environnement mainframe actif dans un contexte d'entreprise — l'habilitation est conduite par les ventes.

Commence par ton représentant IBM, ou utilise Contacter les ventes sur bob.ibm.com. Ils configurent le plan IBM Bob de base et le module Z pour ton organisation.
Une fois que ton administrateur Bob t'assigne un siège avec le module Z, l'habilitation est détectée quand tu utilises IBM Bob. Installe la Bob IDE, connecte-toi, et les modes, skills et outils spécifiques à Z apparaissent.

6. Pour commencer

Si tu utilises déjà Bob, PP4Z ajoute les modes, skills et outils spécifiques à Z en plus de ce que tu as.
Utilise la capacité de compréhension intégrée pour obtenir des insights plus profonds sur le code dans ton workspace.
Pointe Z Understand vers une vraie application où tu connais déjà les bonnes réponses — et vérifie l'analyse de Bob par rapport à ta vérité terrain.
Commence par une question à laquelle tu n'as jamais obtenu de réponse directe : qui appelle vraiment cet utilitaire ? Quelles tables ce job touche-t-il ? Que signifie cette variable ?
Pose des questions plus complexes qui mélangent données et raisonnement : « Donne-moi un graphe d'appels avec des diagrammes organisés par sujets »

Liens