IBM Bob Premium Package for Z (Bob PP4Z) apporte une expertise IBM Z spécialisée directement dans Bob. PP4Z est une capacité premium construite sur la base agentique de Bob, conçue pour accompagner les équipes mainframe sur un périmètre de travail plus large.
PP4Z est conçu pour les réalités du développement mainframe en entreprise : grandes applications, systèmes étroitement interconnectés, variables cryptiques, logique métier de longue date et travaux de modernisation qui doivent être menés de façon sûre, cohérente et avec une profonde conscience architecturale.
Cet article explique pourquoi les grands parcs mainframe poussent les outils généralistes de programmation assistée par IA à leurs limites. Il aborde ce que les métadonnées structurées et les dictionnaires de données apportent au-delà de la simple récupération de code source, comment l'enrichissement du modèle ancre les réponses dans la documentation approuvée par IBM, et comment PP4Z combine le raisonnement piloté par modèle de Bob avec des outils d'analyse et de validation déterministes pour IBM Z.
Une expérience premium pour le développement IBM Z
Le développement IBM Z moderne couvre un large éventail d'activités au-delà de l'écriture de nouveau code : comprendre des applications existantes, tracer l'impact d'un changement à travers un grand système, documenter une logique métier vieille de plusieurs décennies, et prendre des décisions de modernisation qui doivent être à la fois sûres et justifiables.
PP4Z est conçu pour couvrir cette diversité. Il est construit sur la base agentique de Bob et exploite ses skills, sous-agents et workflows. Il les étend ensuite avec ce que le développement IBM Z requiert spécifiquement : une connaissance structurée de grands paysages applicatifs interconnectés, des outils d'analyse déterministes pour COBOL, PL/I et Assembler, et des modes Z-spécifiques ajustés au fonctionnement des équipes mainframe.
Métadonnées locales et d'entreprise pour une meilleure compréhension des applications
Une grande application mainframe peut être constituée de dizaines de milliers de programmes interconnectés couvrant COBOL, PL/I et Assembler, coordonnés par des planificateurs batch et intégrés à des sous-systèmes comme Db2, CICS et IMS. Le modèle ne peut pas raisonner sur l'ensemble de ce parc par le seul contexte. Avant de pouvoir répondre à une question, il doit déterminer quels programmes et quelles relations sont pertinents.
C'est là que la récupération brute de code source atteint ses limites. Imaginons demander à une IA généraliste de trouver tous les programmes qui appellent un utilitaire partagé de traitement des dates (le type de routine appelée par des dizaines de programmes dans un grand parc COBOL). Une recherche textuelle statique trouve les instructions d'appel explicites mais rate les appels dynamiques, où le nom du programme est stocké dans une variable et résolu à l'exécution. Exécuter la même requête deux fois peut amener le modèle à choisir une stratégie de recherche différente, produisant des résultats différents. La réponse semble plausible, mais elle n'est pas fiable.
PP4Z répond à ce problème en construisant une représentation structurée et interrogeable de l'application avant que le raisonnement IA commence. Des scanners locaux alimentent les métadonnées directement depuis le workspace. Ce sont les mêmes scanners que ceux utilisés dans le conteneur Z Understand, disponibles sans étape de téléversement. Les métadonnées capturent les relations entre programmes, les hiérarchies d'appels, le flux de contrôle, le flux de données, l'utilisation du SQL, les définitions de transactions et les dépendances de ressources dans une forme que le modèle peut interroger avec précision.
Pour une analyse à l'échelle de l'entreprise, les équipes peuvent connecter PP4Z au conteneur Z Understand. Cela donne à Bob accès à des métadonnées structurées couvrant le portfolio d'applications dans son ensemble, y compris les relations au-delà du workspace local du développeur. Les développeurs peuvent alors poser à Bob des questions comme :
- Quels programmes appellent un utilitaire donné ?
- Quels programmes lisent une table SQL donnée ?
- Qu'est-ce qui pourrait être impacté si ce champ change de taille ?
Bob interroge les métadonnées pour identifier les programmes et relations pertinents, puis examine le code source correspondant là où une analyse plus approfondie est nécessaire. La réponse est ancrée dans des données applicatives cohérentes et interrogeables plutôt que dans une recherche probabiliste sur des fichiers source bruts.
Enrichissement du modèle : combler le fossé de connaissances IBM Z
La majorité du code d'applications IBM Z se trouve dans des dépôts d'entreprise privés. Un modèle généraliste n'a accès ni au code source, ni aux conventions, ni au contexte métier de ces systèmes. Il doit aussi travailler avec moins d'exemples publics que pour les langages et frameworks courants.
PP4Z répond à cette limite par l'enrichissement du modèle : de la documentation de référence IBM Z soigneusement sélectionnée est analysée, indexée et mise à la disposition de Bob afin que les réponses concernant les langages et middlewares IBM Z s'appuient sur ce qu'IBM documente réellement. La couche d'enrichissement traite la documentation IBM Z afin de la rendre directement exploitable pour les types précis de questions que posent les développeurs : conventions d'appel, structures de champs, comportements des middlewares et cas limites documentés sur lesquels un modèle généraliste peu exposé à ces environnements peut commettre des erreurs difficiles à repérer.
La différence concrète apparaît lorsqu'un développeur écrit ou modifie du code qui interagit avec un middleware IBM Z. Un modèle généraliste peut produire du code syntaxiquement plausible qui viole des contrats précis définis par IBM. Avec l'enrichissement du modèle, la connaissance que PP4Z mobilise pour composer une réponse s'appuie sur ce qu'IBM spécifie réellement, et non sur la meilleure approximation possible à partir d'une exposition limitée pendant l'entraînement.
Une IA consciente du métier grâce aux dictionnaires de données
Des noms de variables peu clairs existent dans toutes les bases de code, mais les applications IBM Z présentent ce problème à une autre échelle et sous une autre forme. Dans de nombreuses applications COBOL de longue date, logique métier et logique applicative sont étroitement imbriquées. Le sens est encodé dans des noms de champs concis, des layouts de copybooks et des conventions de nommage qui se sont accumulées sur des décennies sans application cohérente. Considérons ce WORKING-STORAGE SECTION :
01 WK10.
10 WK10-QUDISP PICTURE 9(10)
VALUE ZERO.
10 WK10-QUPIL PICTURE 9(3)
VALUE ZERO.
10 WK10-QUDIS PICTURE 9(15)
VALUE ZERO.
10 WK10-QUMYD PICTURE 9(10)
VALUE ZERO.Quatre accumulateurs numériques se trouvent dans un groupe appelé WK10. Ni les noms ni les clauses PICTURE n'indiquent à un développeur ou à un modèle ce que chacun représente. Un modèle sans contexte supplémentaire pourrait observer que WK10-QUDISP et WK10-QUDIS sont tous deux des champs numériques, probablement liés à des distances vu les fragments QU et DIS, et supposer qu'ils servent des objectifs similaires. Cette supposition est fausse. La différence d'un seul caractère entre eux, c'est toute l'histoire.
Avec le dictionnaire de données généré par PP4Z, la distinction est explicite. WK10-QUDIS est le total cumulé de la distance parcourue par l'ensemble des pilotes. Il est incrémenté tout au long du traitement des enregistrements de vols et utilisé dans le calcul final de la moyenne. WK10-QUDISP est un accumulateur par pilote. Il se remet à zéro au début du bloc de traitement de chaque pilote et est affiché aux côtés de l'identification de ce pilote. L'un se remet à zéro par pilote ; l'autre jamais. Une explication ou une analyse d'impact qui les confond produit une réponse erronée sur ce que fait le programme.
PP4Z génère ces entrées par analyse statique de la façon dont chaque variable participe au programme. L'analyse couvre le flux de contrôle, les opérations d'E/S, les calculs et les mouvements de données. Plutôt que de tenter de documenter chaque champ, elle identifie les variables qui influencent le plus le comportement du programme : celles qui, une fois nommées, rendent le reste du programme lisible. Les entrées du dictionnaire de données peuvent être gérées localement ou via le conteneur Z Understand, avec prise en charge de la génération en masse, de la révision et de la synchronisation entre équipes.
Documentation, explication et refactoring
Les sections sur les métadonnées, le dictionnaire de données et l'enrichissement du modèle expliquent comment PP4Z construit sa représentation d'une application. Cette section explique comment les développeurs utilisent cette représentation.
La documentation et l'extraction de règles métier produisent une connaissance applicative durable à grande échelle. Les équipes peuvent générer de la documentation structurée pour des programmes COBOL, PL/I et Assembler, couvrant la logique du programme, les flux de données et les règles métier embarquées. Elles peuvent utiliser les métadonnées du scanner local pour un périmètre ciblé ou le conteneur Z Understand pour l'application complète. Les règles métier émergent dans ce processus, offrant aux équipes techniques et aux parties prenantes de la modernisation un enregistrement lisible de ce que fait l'application, sans avoir à parcourir manuellement chaque paragraphe.
Cette documentation au niveau du programme peut désormais être compilée en une vue d'application, un site structuré avec des diagrammes et des pages avec références croisées couvrant l'ensemble de l'application. La documentation individuelle d'un programme répond aux questions sur ce programme. La vue d'application donne aux équipes et aux parties prenantes de la modernisation une carte de l'ensemble de l'application.
L'explication complète génère une explication détaillée d'un programme du point de vue le plus pertinent pour la tâche en cours : Architecte, Développeur ou Métier. PP4Z s'appuie sur les métadonnées de l'application, les entrées du dictionnaire de données et sa couche d'enrichissement du modèle pour ancrer l'explication dans le comportement du programme.
Le refactoring utilise le contexte réuni pour restructurer le code existant en services modulaires et réutilisables tout en préservant la fonctionnalité. Le workflow Refactor COBOL or PL/I program identifie les candidats à l'extraction, cartographie leurs dépendances et guide la transformation. Cela donne aux équipes une voie de modernisation pratique qui améliore la maintenabilité sans nécessiter une réécriture complète.
Capacités intégrées de développement, qualité et débogage
Certaines parties du workflow d'un développeur ont des réponses déterministes : si le code est conforme à une règle, quel chemin emprunte une variable donnée dans un programme, ou où le contrôle est transféré après un PERFORM. PP4Z gère ces questions via des outils dédiés. Le modèle interprète les faits résultants dans le contexte de ce que le développeur cherche à accomplir.
Dans le mode personnalisé PP4Z Z Code, Z Code Scan fournit une analyse statique rapide basée sur des règles pour les programmes COBOL et PL/I. Son feedback de type linter détecte les problèmes sans inférence probabiliste. Le mode personnalisé Z Architecture fournit une analyse du flux de contrôle et du flux de données, notamment comment l'exécution se déroule dans un programme et comment les données se transforment en transitant entre paragraphes et copybooks. Ces outils produisent des résultats cohérents et reproductibles quelle que soit la formulation de la question.
Le modèle travaille avec les résultats de ces outils. Il peut interpréter un résultat de scan dans le contexte d'un changement proposé ou tracer un flux de données pour répondre à une question précise sur le comportement du programme. L'analyse déterministe gère ce qui est lié aux règles ; l'IA gère ce qui requiert du jugement.
PP4Z inclut également IBM Debug for z/OS et des capacités de couverture de code, permettant aux équipes de passer directement du développement assisté par IA à la validation au niveau d'exécution dans le même environnement.
Skill Builder pour la connaissance propre à l'entreprise
Les métadonnées d'application, les dictionnaires de données, l'enrichissement du modèle et l'analyse déterministe constituent le socle IBM Z fourni avec PP4Z. Skill Builder permet aux organisations d'y ajouter leurs propres connaissances.
Avec Skill Builder, les équipes peuvent créer des skills personnalisées qui capturent et appliquent des connaissances propres à l'entreprise : standards de codage, conventions de nommage, patterns techniques, terminologie métier et guidance spécifique à l'environnement. Ces skills aident Bob à comprendre comment le développement est réalisé au sein d'une organisation spécifique, réduisant les suppositions génériques et améliorant la pertinence des réponses générées par l'IA. Les skills peuvent être automatiquement ingérées et invoquées dynamiquement lorsqu'elles sont pertinentes par rapport à la demande et au contexte de code de l'utilisateur, s'intégrant directement dans les workflows PP4Z existants.
Tout mettre ensemble
L'échelle, la densité sémantique et le contexte propriétaire rendent le développement mainframe difficile pour les outils d'IA généralistes. PP4Z traite directement chacun de ces facteurs : des métadonnées structurées pour l'échelle, des dictionnaires de données pour le sens métier, l'enrichissement du modèle pour la couverture documentaire IBM Z et des outils déterministes pour l'analyse régie par des règles.
Dans cette approche, le raisonnement IA et la connaissance déterministe se renforcent mutuellement. Bob commence avec des métadonnées structurées, s'appuie sur la documentation curatée et interprète les résultats des outils basés sur des règles. Les développeurs peuvent inspecter ces preuves avant d'agir sur la réponse dans un environnement critique pour le métier.
Pour commencer, choisis un programme que ton équipe a évité jusqu'ici — peut-être parce que son objectif est flou ou que sa logique métier n'a pas été touchée depuis des années. Lance le scanner local pour construire ses métadonnées et génère un dictionnaire de données pour ses variables clés. Utilise le workflow d'explication pour comprendre ce que fait le programme, puis lance le workflow de documentation pour capturer cette connaissance dans ton workspace. À partir de là, la même fondation supporte l'analyse d'impact, le refactoring et la validation qualité. L'équipe commence avec un programme qu'elle comprend désormais.