Vos rapports métiers prennent des heures à s’exécuter et la maintenance vous pèse ?
Le report program generator d’IBM explique comment automatiser et fiabiliser la production de rapports sur IBM i. Vous verrez des stratégies de modernisation progressive et d’encapsulation via API pour réduire les risques et accélérer les intégrations. On commence par définir le langage et ses cas d’usage.
Résumé
- RPG (Report Program Generator) est un langage IBM créé en 1959 pour automatiser la génération de rapports et fournir un accès natif et performant à DB2 sur IBM i.
- RPG IV/ILE reste pertinent et supporté en 2026, surtout dans les secteurs critiques ; évaluez la valeur métier, le coût de licence et la rareté des compétences avant toute décision.
- Préférez la modernisation progressive : adoption du free-form, SQL embarqué et refactorings par étapes pour limiter les risques et les régressions.
- Encapsulez la logique critique derrière des API/servies web (REST/SOAP) et exploitez RPG Open Access pour intégrer le web/cloud et les microservices.
- Décidez selon une checklist ROI/risques (coût/durée, complexité, dépendances IBM i, tests, disponibilité des compétences) ; réécrire seulement si la valeur métier le justifie.
Qu’est-ce que le Report Program Generator (RPG) et à quoi sert-il ?
Le report program generator (RPG) est un langage de programmation créé par IBM en 1959 pour automatiser la génération de rapports à partir de fichiers métiers. Conçu à l’origine pour l’IBM 1401 et issu de FARGO, RPG a évolué en un langage orienté traitement de données, optimisé pour les applications de gestion telles que la comptabilité, la facturation et l’inventaire.
Utilisez RPG quand vous maintenez des applications sur IBM i ou quand vous avez besoin d’un accès natif et performant à DB2. Préférez la modernisation progressive pour réduire le risque, et privilégiez les outils IBM recommandés comme RDi pour le développement et le débogage.
Le RPG est-il encore pertinent aujourd’hui pour mon système d’information (SI) ?
Oui. RPG IV/ILE est toujours supporté sur IBM i en 2026 et reste répandu dans les secteurs critiques (banque, assurance, manufacturing). Sa pertinence tient à sa compatibilité native avec les fichiers IBM i et à la stabilité des applicatifs legacy qui gèrent des volumes importants en production.
Évaluez la valeur métier avant toute décision. Encapsulez les fonctions critiques via API ou modernisez progressivement la syntaxe (free-form) pour faciliter le recrutement et l’intégration avec des stacks modernes. Anticipez toutefois le coût de licence et la pénurie de profils RPG.
Comment le RPG a-t-il évolué depuis 1959 ?
Le parcours du langage se lit en étapes successives, chacune répondant à des besoins techniques et matériels. Les évolutions ont conservé une forte rétrocompatibilité tout en ajoutant des capacités modernes.
Les débuts (1959–1969) : FARGO, IBM 1401 et le paradigme du cycle
À l’origine, RPG reprenait le paradigme du cycle machine pour traiter record par record avec des indicateurs logiques. Ce modèle simplifiait les rapports header/detail et réduisait le code nécessaire par rapport à COBOL. La target initiale était le traitement par cartes puis les premiers disques.
RPG II et RPG III : adoption par les systèmes midrange et concepts opérationnels (level break, matching records)
RPG II (années 1970) standardise les notions de level break et matching records, facilitant les rapports complexes. RPG III puis RPG/400 apportent des structures plus modernes (IF/ENDIF, DO) et s’implantent sur System/38 et AS/400, consolidant RPG comme langage midrange.
Retours d’expérience : migrations partielles, modernisation progressive et solutions propriétaires
Les projets réels montrent que la modernisation progressive l’emporte souvent sur la réécriture totale. Migrer vers le free-form et introduire SQL embarqué réduit la dette technique. Utilisez des outils de transformation et testez par lots pour limiter les régressions.
Comment moderniser, intégrer ou migrer des applications RPG ?
La stratégie doit être MECE : analyser le code, prioriser les modules critiques, puis appliquer des patterns de modernisation ou d’encapsulation. Voici les points techniques clefs et une checklist ROI/risques pour choisir la bonne voie.
Caractéristiques techniques clés : cycle, formats, indicateurs et free-form
Comprenez le cycle historique et les spécifications en colonnes (F, D, C). Free-form (depuis V5R1 et amplifié en V7+) permet d’écrire du code lisible proche des langages modernes. Traitez les indicateurs et les spécifications d’I/O avant de refactorer pour éviter les régressions.
Interopérabilité et intégration : SQL embarqué, RPG Open Access, services web et API
Intégrez via SQL embarqué pour tirer parti du SQE, et utilisez RPG Open Access (depuis 2010) pour créer des handlers I/O vers le web ou le cloud. Encapsulez la logique critique derrière des services REST/SOAP pour rendre les fonctions accessibles aux microservices modernes.
Checklist ROI et risques : choisir entre modernisation, encapsulation ou réécriture
Évaluez selon ces critères :
- Coût et durée du projet vs valeur métier
- Complexité du code et dépendances IBM i
- Risque opérationnel et tests disponibles
- Disponibilité compétences RPG et support IBM
Préférez la modernisation progressive ou l’encapsulation pour systèmes critiques. Réécrivez seulement si l’application n’apporte plus de valeur et que le coût total justifie l’effort.
