Travailler avec IBM i avec IBM Bob

Si tu n'as jamais écrit une ligne de RPG, IBM i est l'une des plateformes les plus fascinantes pour la production à grande échelle. Si tu en as écrit quelques millions de lignes, tu sais déjà où se trouvent les douleurs quotidiennes. Ce post couvre les deux : un aperçu technique de ce qui rend IBM i unique, où la friction de modernisation apparaît réellement, comment IBM Bob s'intègre dans un workflow IBM i aujourd'hui, les étapes de configuration pour démarrer, et ce qui suit sur la roadmap pour la plateforme.

Ce qu'est réellement IBM i

IBM i n'est pas un système d'exploitation legacy dans le sens "nous devrions réécrire cela". C'est une plateforme intégrée — l'OS, la base de données, le modèle de sécurité et le runtime sont conçus et livrés comme une seule chose — qui génère des revenus pour les banques, les assureurs, les hôpitaux, les fabricants et les entreprises de logistique depuis des décennies. Nous devrions donc l'appeler légendaire.

Quelques détails qui ont tendance à surprendre les développeurs qui le voient pour la première fois :

Single-level storage. La RAM et le disque partagent un espace d'adressage virtuel. Les pointeurs d'objets persistent à travers les redémarrages. L'OS traite la mémoire et le stockage comme un seul niveau et pagine entre eux de manière transparente. La plupart des systèmes modernes rattrapent encore leur retard.
TIMI, le Technology Independent Machine Interface. Les binaires RPG compilés sur du matériel des années 1990 s'exécutent sans modification sur les puces POWER actuelles. L'OS retraduit contre le nouveau jeu d'instructions sous le capot. L'analogue moderne le plus proche est WebAssembly, des décennies plus tôt.
OS basé sur les objets. Les programmes, fichiers, files d'attente et autorisations sont des objets typés avec des attributs — pas des fichiers avec des métadonnées ajoutées. La sécurité est appliquée au niveau de l'objet.
Db2 for i est intégré, pas ajouté. SQL et l'I/O natif au niveau des enregistrements accèdent aux mêmes données. Un fichier physique de 40 ans peut être interrogé via une vue SQL moderne sans projet de migration.
Le source peut vivre sur le système ou dans Git — ton choix. Historiquement, le source IBM i était stocké comme members à l'intérieur de source physical files (QSYS), compilés directement sur le système. La plateforme positionnait à l'origine la LPAR comme source de vérité. Mais IBM i a évolué : les compilateurs et l'OS supportent maintenant pleinement les workflows modernes centrés sur Git, les fichiers de stream IFS et le développement local si tu le choisis. De nombreux shops utilisent encore les bibliothèques QSYS, mais la plateforme te donne des options

La plateforme supporte également les patterns de livraison modernes out of the box : moteurs d'API REST natifs dans l'OS, cloud hybride via Power Virtual Server, et inférence IA s'exécutant sur le même matériel que les charges de travail transactionnelles. RPG, COBOL, CL et SQL coexistent avec les pratiques de développement que le reste de ton organisation d'ingénierie utilise déjà.

La plateforme n'est pas le problème. La friction est autour d'elle.

Où la friction apparaît

Quatre patterns apparaissent dans presque tous les shops IBM i. Aucun d'eux ne concerne RPG lui-même — le langage va bien — mais le contexte autour du code qui n'a jamais été écrit, et la façon dont la plateforme stocke et partage ce contexte.

Contexte implicite, by design. Un programme RPG fonctionnel peut couvrir quatre générations de langage dans un source — RPG II, RPG IV, copybooks /COPY (déclarations partagées incluses au moment de la compilation) et procédures en format libre — avec une syntaxe sensible aux colonnes et des indicateurs numérotés (*IN01–*IN99) faisant le travail que le flux de contrôle structuré et les booléens nommés font dans la plupart des autres langages. La syntaxe est appréhendable en une semaine ; les conventions et règles métier autour vivent dans les têtes des ingénieurs seniors.
Le changement n'est jamais local. Le type d'un champ n'est pas déclaré dans le programme qui l'utilise — il est déclaré dans la table de base de données elle-même, dans un fichier source séparé (un member DDS). Chaque programme qui lit ou écrit cette table hérite de ces définitions simplement en référençant le fichier en haut. Donc allonger une colonne de 10 à 12 chiffres n'est jamais une modification d'un seul programme : cela se propage à travers chaque programme qui touche le fichier, et la liste de ces programmes est rarement écrite quelque part. Chaque changement à une charge de travail critique comporte donc un risque de continuité, et la modernisation stagne.
Le source vit rarement là où les outils modernes l'attendent. La copie canonique d'un programme est sur le système, pas dans un repo Git sur un laptop. Lire du code que quelqu'un d'autre a écrit il y a quinze ans commence par le trouver sur la LPAR, l'exporter, puis décider si l'export est la copie canonique — un workflow auquel tout outil supposant un arbre de travail local doit être adapté avant de mériter sa place.
Le RPG à format fixe ne ressemble en rien au code moderne. La plupart du RPG de production a été écrit en format fixe : syntaxe sensible aux colonnes où les codes d'opération vivent dans les colonnes 26–35, Factor 1 dans 12–25, et les commentaires ne rentrent qu'après la colonne 80. Cela se lit comme du langage assembleur pour quiconque formé sur Python ou JavaScript. IBM a réinventé le langage avec du RPG entièrement en format libre (RPG IV, plus tard simplement "RPG"), qui ressemble et se comporte comme un langage procédural moderne — blocs structurés, variables nommées, expressions standard. L'écart de syntaxe est réel, mais le langage lui-même a évolué. La friction est que des décennies de code fonctionnel sont toujours en format fixe, et le réécrire comporte un risque que la plupart des shops ne peuvent justifier.

Ce que Bob fait sur une application RPG pour IBM i

Pointe Bob vers un programme RPG et commence en mode Ask :

"Guide-moi à travers ce que fait ce programme et quels fichiers il touche."
"Où CUSTNO est-il défini, et quels programmes le lisent après ça ?"
"Qu'est-ce qui casserait si je changeais la longueur de ce champ ?"

Passe en mode Plan quand tu as un changement en tête : une conversion en format libre, une migration SQL hors de l'I/O au niveau des enregistrements, ou casser un monolithe en modules. Bob produit un plan, les dépendances qu'il a touchées, et les étapes qu'il compte prendre, avant qu'un fichier ne soit modifié.

Passe en mode Code pour appliquer le changement. Bob :

Convertit le RPG à format fixe en format libre en utilisant des patterns répétables, fichier par fichier.
Migre l'I/O au niveau des enregistrements vers du SQL embarqué où approprié.
Génère des suites de tests RPGUnit contre les procédures existantes pour que la conversion soit vérifiable, pas seulement compilée.
Produit de la documentation en langage clair et des diagrammes Mermaid à partir du source — des artefacts consultables et partageables qui survivent à n'importe quel ingénieur.

Le même workflow gère RPG II/III/ILE, CL, DDS, SQL et COBOL, donc une nouvelle recrue lisant un programme écrit avant sa naissance n'est plus bloquée par la syntaxe.

Rends ton source IBM i Bob-ready

Bob aujourd'hui travaille contre du source sur ton ordinateur local. La configuration est courte :

Récupère ton source. Exporte tes members RPG, RPGLE, CL, DDS et SQL vers un dossier local. L'explorateur de projet Code for i documente l'export depuis les physical file members : migrate source
Ouvre le dossier dans Bob. File → Open Folder sur la racine du source. Bob indexe la codebase à la première ouverture.
Installe la toolchain IBM i. Depuis le panneau Extensions, ajoute le IBM i Development Pack (le bundle Code for i) et un renderer Mermaid pour les diagrammes que Bob produit.
Démarre une session en mode Ask. Choisis un seul programme — idéalement un que personne dans l'équipe ne comprend complètement — et demande à Bob de l'expliquer. C'est le moyen le plus rapide de voir si Bob mérite sa place dans ton workflow.

Si ton équipe vient de SEU ou RDi, la migration est principalement l'étape d'export ci-dessus plus l'installation de l'extension. La surface d'édition est un environnement moderne de la famille VS Code avec coloration syntaxique, complétion de code et le workflow IA décrit précédemment ; les numéros de ligne sont toujours disponibles pour les ingénieurs qui les veulent.

Ce qui suit pour Bob sur IBM i

Le Premium Package for i récemment annoncé fournit une expérience native et optimisée pour les équipes de développement IBM i. Premium Package for i sera généralement disponible le 24 juin.

Premium Package for i. Avec le GA du 24 juin, Bob se connectera directement à ton IBM i. Depuis une seule session tu lis les source members directement depuis QSYS, les édites avec le même workflow ci-dessus, et exécutes des cycles de compilation et de test contre le système directement. Parallèlement à la connectivité, Bob acquiert des skills et workflows intégrés ajustés au développement IBM i — conversion fixe-vers-libre, refactoring, génération de documentation — pour qu'un prompt de départ sur une codebase RPG atterrisse plus directement sur les conventions IBM i out of the box. Concrètement, cela signifie :

Une session Bob connectée à une LPAR de développement ; pas de boucle séparée export-édition-import.
Les erreurs de compilation et résultats de tests de l'IBM i remontent dans la conversation dans laquelle Bob est déjà.
Skills et workflows intégrés pour les patterns de refactoring, conversions et génération de tests que les shops IBM i exécutent de manière répétée.

Plus loin — SDLC de bout en bout. Trois fils sont en conception active pour les futures versions :

Intégration DevOps. Bob participant au build, deploy, monitor et CI/CD pour les charges de travail IBM i — exécutant une passe de régression contre une LPAR de test, promouvant un changement à travers les environnements, et remontant un problème runtime dans une session.
Performance SQL. Analyse de données et optimisation d'index comme capacité de première classe, en plus des patterns de migration SQL embarqué que Bob produit déjà aujourd'hui.
Assistant de connaissance IBM i. Réponses basées sur la récupération à travers la codebase, la documentation de conception et les tickets — pour que le contexte qui vit en dehors du source soit accessible depuis la même conversation.

Pour une équipe adoptant Bob aujourd'hui, le workflow de fichier local ci-dessus est le bon point de départ ; les éléments de cette section décrivent comment ce workflow se raccourcit et s'étend à mesure que l'offre IBM i mûrit.

Références clients

Des équipes dans la santé, l'agriculture, l'IT d'entreprise et la logistique utilisent Bob contre des codebases IBM i de production aujourd'hui :

MEDHOST. Applications de santé couvrant plusieurs générations RPG à travers des déploiements hospitaliers américains. L'équipe utilise Bob pour l'analyse d'impact et la conversion fixe-vers-libre, et pour l'onboarding de développeurs plus récents sur des programmes dont les auteurs originaux sont partis depuis longtemps.
NI+C. Intégrateur d'entreprise japonais avec des programmes RPG qui tournaient inchangés depuis plus d'une décennie sans documentation de conception survivante. Bob a produit des docs de conception et des diagrammes Mermaid suffisamment précis pour que les ingénieurs qui avaient précédemment rebondi sur les assistants IA continuent à l'utiliser pour du vrai travail.
Heartland Co-op. Coopérative agricole basée dans l'Iowa diffusant des données de capteurs IoT en temps réel dans son environnement IBM i pour le monitoring de la qualité des grains et des équipements. Bob aide les développeurs à raisonner à travers les interdépendances entre le pipeline IoT, la comptabilité des grains et les systèmes opérationnels de base, et raccourcit la montée en compétence des nouvelles recrues.
Carreras Grupo Logístico. L'un des premiers adopteurs d'entreprise de Bob en Espagne, l'utilisant pour expliquer la logique de programmes legacy, générer de la documentation et refactoriser à travers les modules d'une plateforme logistique.

Le fil commun à travers les quatre est le même : la codebase IBM i existante reste en place, et le travail d'explication, de conversion et de documentation s'exécute aux côtés du système de production plutôt qu'avant un projet de remplacement.

Démarrer

Commence un essai gratuit
Récupère un programme RPG dans un dossier local et ouvre-le dans Bob.
En mode Ask, demande un walkthrough et un diagramme Mermaid de son flux de données.

Cette session — un programme, une conversation — est le chemin le plus court vers une vraie réponse sur si Bob correspond à la façon dont ton équipe travaille.