Les offres AS400 couvrent plusieurs réalités. Certaines demandent du RPG IV en format libre avec SQL embarqué et ILE. D'autres maintiennent du RPG III, du COBOL sur AS400 ou du code produit par un générateur comme Synon ou Adelia, qu'il faut connaître en plus du langage. Une partie des postes ajoute l'administration courante de la machine : droits, purges, travaux planifiés. Lisez l'offre ligne par ligne avant de trier les CV.
La plateforme ne ressemble pas au mainframe z/OS, même si les deux viennent d'IBM. Bibliothèques, liste de bibliothèques, objets typés, files d'attente de travaux et messages CL forment un environnement à part. Un développeur COBOL z/OS met plusieurs mois à s'y retrouver. Posez des questions sur cet environnement, en plus de la syntaxe RPG.
L'écart entre profils se voit sur ILE et SQL. Un développeur à jour découpe son code en procédures et programmes de service, sait ce qu'est un groupe d'activation, remplace les CHAIN en boucle par une requête SQL et travaille sous RDi ou VS Code avec Git. Un profil resté au RPG à colonnes tient bien la maintenance, beaucoup moins un projet de modernisation. Le PDF couvre six axes et un cas de 20 minutes.
Langages, base et outils d'un développeur IBM i
RPG IV (ILE RPG) en format libre
Le langage principal. Depuis 2016, une source peut être entièrement libre, avec **FREE en première ligne et aucune colonne imposée : déclarations dcl-s, dcl-ds, dcl-proc, opérations et SQL embarqué. Beaucoup d'applications mélangent encore RPG III, RPG IV à colonnes et format libre. Le candidat doit savoir lire les trois.
ILE (Integrated Language Environment)
Le modèle de programmes d'IBM i : modules compilés, liés en programmes ou en programmes de service, exécutés dans des groupes d'activation. C'est lui qui permet de partager des procédures entre programmes sans dupliquer le code. Un CV qui annonce de l'ILE doit savoir expliquer une signature de programme de service.
CL (CLLE)
Le langage de commande d'IBM i. Il enchaîne les traitements, soumet des travaux (SBMJOB), substitue des fichiers (OVRDBF) et intercepte les erreurs avec MONMSG. Il tient sur IBM i une partie du rôle du JCL sur mainframe, en plus proche d'un langage de script.
DB2 for i et SQLRPGLE
La base intégrée au système. Les fichiers physiques et logiques décrits en DDS cohabitent avec des tables, index et vues créés en SQL. SQLRPGLE embarque du SQL dans le RPG, avec SQLSTATE à tester après chaque instruction. Les nouvelles tables se créent surtout en SQL.
Écrans 5250, DDS et sous-fichiers
Les écrans en mode caractère, décrits en DDS et dessinés avec SDA. Le sous-fichier affiche une liste que l'on parcourt page par page. C'est encore l'interface de nombreuses applications et une bonne part de la maintenance quotidienne.
Journalisation et contrôle de validation
Le journal enregistre chaque modification d'un fichier. Il sert à la reprise, à l'audit, à la réplication et au contrôle de validation, avec COMMIT et ROLBK. Sans journal, un programme qui plante au milieu d'un traitement laisse des données à moitié mises à jour.
RDi et Code for IBM i
Les postes de travail actuels du développeur. RDi (Rational Developer for i), basé sur Eclipse, est l'outil d'IBM. Code for IBM i, extension open source de VS Code, compile RPG, COBOL et CL, ouvre des sessions 5250 et travaille avec Git. SEU, l'ancien éditeur en 5250, n'est plus mis à jour et ne reconnaît pas la syntaxe récente.
Services web et échanges
Le serveur IWS (Integrated Web Services) expose des procédures RPG en services REST ou SOAP. Les fonctions HTTP de QSYS2 appellent des API externes depuis SQL. DATA-INTO et DATA-GEN lisent et produisent du JSON. Les files de données et IBM MQ servent aux échanges asynchrones, et Node.js, Python ou PHP tournent aussi sur la machine.
ARCAD, Aldon et Git
Les outils de gestion des changements qui suivent les objets IBM i, leurs dépendances et leur promotion de la recette vers la production. Git arrive progressivement, avec des sources déplacées dans l'IFS. Demandez quel outil le candidat a utilisé et comment se passait une livraison.
IBM i fait tourner beaucoup d'ERP et d'applications de gestion développées en interne et maintenues depuis des décennies. La dernière version du système est IBM i 7.6, sortie en 2025. Le poste combine souvent maintenance, évolutions, support aux utilisateurs et rédaction de spécifications, parfois l'administration courante de la machine. Les intitulés varient : développeur RPG, analyste développeur AS400, développeur IBM i, concepteur réalisateur. Les profils seniors connaissent parfois mieux le RPG III que le format libre. Un développeur COBOL qui a travaillé sur AS400 connaît déjà l'environnement, ce qui raccourcit beaucoup son passage au RPG.
Ce qu'un développeur RPG AS400 doit montrer en entretien
- RPG IV en format libre et gestion des erreurs
- ILE, programmes de service et groupes d'activation
- CL, travaux et liste de bibliothèques
- DB2 for i, SQL embarqué et verrous
- Écrans 5250 et sous-fichiers
- Services web, outillage et livraison
Signature ILE, verrous, sous-fichiers : les questions qui comptent
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Après l'ajout d'une procédure dans un programme de service, des programmes qui l'utilisent plantent avec une erreur de signature. Que s'est-il passé ?
Une bonne réponseLa signature du programme de service est calculée à partir de sa liste d'exports. En la modifiant, on l'a changée, et les programmes liés à l'ancienne signature échouent à l'appel (MCH4431). La bonne pratique : un binder source (STRPGMEXP, EXPORT, ENDPGMEXP) où les nouvelles procédures s'ajoutent à la fin, avec l'ancienne signature conservée (*PRVSIGNATURE) ou une signature fixe. Sans cela, il faut relier tous les programmes appelants, par UPDPGM par exemple.
Signal d'alerteRecréer le programme de service en EXPORT(*ALL) et relancer, sans comprendre la signature.
Question 2 · confirmé
Un programme lit un fichier par CHAIN dans une boucle, une fois par ligne de commande, et met dix minutes. Que proposez-vous ?
Une bonne réponseUne requête SQL ensembliste avec jointure, lue par blocs dans un tableau de DS, ou au moins un SETLL et des READE sur un chemin d'accès adapté. Il vérifie l'index avec Visual Explain et le conseiller d'index d'IBM i, et mesure avant et après. Il supprime aussi les ouvertures et fermetures de fichiers répétées à chaque appel.
Signal d'alerte« On le passe la nuit », ou un fichier logique ajouté sans mesure.
Question 3 · junior à confirmé
Un programme fonctionne quand vous le lancez depuis votre session et échoue en batch avec « fichier introuvable ». Que vérifiez-vous ?
Une bonne réponseLa liste de bibliothèques du travail soumis, qui vient de la description de travail (INLLIBL) ou du paramètre INLLIBL du SBMJOB, et le profil utilisateur sous lequel il tourne, avec ses droits. QTEMP est propre à chaque travail : un fichier créé en interactif dans QTEMP n'existe pas dans le travail batch. Il vérifie aussi les substitutions de fichiers, puis lit l'historique du travail (DSPJOBLOG).
Signal d'alerteQualifier en dur la bibliothèque de production dans le programme pour que ça marche.
Question 4 · confirmé
On vous confie un programme en RPG III à colonnes fixes, avec des indicateurs *IN partout. Que changez-vous quand vous devez le faire évoluer ?
Une bonne réponseRien de massif sans jeu de test. Il convertit d'abord la source en RPG IV (CVTRPGSRC), puis passe progressivement au format libre avec l'outil de RDi ou de Code for IBM i. Les indicateurs numériques cèdent la place à des noms : %FOUND et %EOF après les opérations sur fichier, INDARA et une structure d'indicateurs nommés pour l'écran. La nouvelle logique va dans des sous-procédures. Il repère avant tout si le programme utilise le cycle RPG avec un fichier primaire, car la conversion ne doit pas en changer le comportement.
Signal d'alerteTout réécrire d'un coup, ou ajouter cinquante lignes de plus avec de nouveaux indicateurs numérotés.
Question 5 · confirmé
Un sous-fichier doit permettre de parcourir 300 000 clients. Quel mode de chargement choisissez-vous ?
Une bonne réponseIl connaît les trois modes. Chargement complet (tout en une fois, limité à 9 999 lignes), sous-fichier extensible (SFLSIZ supérieur à SFLPAG, une page ajoutée à chaque défilement, le retour arrière géré par le système), page par page (SFLSIZ égal à SFLPAG, le programme gère les deux sens). Pour 300 000 lignes, page par page ou extensible, avec une zone de positionnement qui fait un SETLL. SFLEND indique s'il reste des lignes.
Signal d'alerteUn chargement complet de tous les clients à l'ouverture de l'écran.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
RPG, AS400 et IBM i : réponses aux questions des recruteurs
Un développeur COBOL z/OS peut-il passer sur IBM i ?
Le langage COBOL existe sur les deux plateformes, mais l'environnement change tout. Sur IBM i, il faut apprendre les bibliothèques, la liste de bibliothèques, le CL, les écrans 5250 et DB2 for i, puis le RPG si le parc en contient. Comptez plusieurs mois avant l'autonomie. Un développeur COBOL qui a déjà travaillé sur AS400 est un bien meilleur candidat qu'un développeur mainframe qui découvre la plateforme.
Faut-il exiger Synon ou Adelia dans l'offre ?
Oui si une partie de votre code est générée par l'un de ces outils, car un développeur RPG qui ne les connaît pas ne pourra pas modifier ce code proprement : la modification se fait dans le générateur, pas dans le RPG produit. Ces profils sont rares. Si le générateur ne concerne qu'une petite partie du parc, notez-le comme un plus et prévoyez une formation interne.
RPG III, RPG IV, format libre : quel niveau attendre d'un candidat ?
Pour un poste de maintenance, la lecture du RPG III et du RPG IV à colonnes est indispensable, puisque c'est ce que contient le code existant. Pour un poste d'évolution ou de modernisation, exigez en plus le format libre, les sous-procédures, ILE et le SQL embarqué. Demandez un extrait de code récent écrit par le candidat, ou faites-lui commenter un programme en format libre.
Quel exercice donner à un développeur RPG en entretien ?
Un test technique court et lié au poste fonctionne mieux qu'un questionnaire de syntaxe. Donnez un programme RPG avec un CHAIN en boucle à réécrire en SQL, ou une erreur de signature de programme de service à expliquer. Trente à quarante-cinq minutes suffisent, avec commentaire à voix haute. Vous voyez le niveau ILE, le réflexe SQL et la façon de lire du code existant.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
