Un développeur PACBASE maintient des applications COBOL dont le source n'est pas retouché à la main : il décrit les données et les traitements dans le dictionnaire, puis lance la génération. Les offres associent PACBASE au COBOL, au JCL, à DB2 et au mainframe, souvent avec la mention RPP (Rational Programming Patterns), l'outil proposé par IBM pour prolonger le modèle dans Rational Developer for z. Une partie des missions relève de la TMA, une autre de la réécriture du code généré en COBOL natif.
COBOL et PACBASE se mélangent souvent sur les CV. Un développeur COBOL qui a seulement lu du code généré ne sait pas où se trouve la vraie source d'un traitement, ni ce que casse la modification d'une rubrique partagée. Demandez dans quelle bibliothèque la personne travaillait, comment elle retrouvait les programmes touchés par un changement et quelles macro-structures maison elle a modifiées.
Sur un projet de sortie de PACBASE, le profil attendu change. Il faut lire le COBOL généré, ses paragraphes numérotés et ses indicateurs de rupture, décider ce qu'on garde et prouver la non-régression. Le PDF contient 30 questions sur six axes, un cas de 20 minutes et une grille de 1 à 4.
Dictionnaire, générateur et outils autour de PACBASE
Dictionnaire PACBASE
La base centrale qui contient toutes les entités d'une application : rubriques, segments, structures de données, programmes, écrans, états et textes. Chaque entité est décrite une fois puis réutilisée partout où elle est appelée. Toute modification se fait dans le dictionnaire, puis on régénère les programmes concernés.
Bibliothèques et sessions
Les bibliothèques forment une hiérarchie : une bibliothèque inférieure hérite des entités des niveaux supérieurs et peut les surcharger. Les sessions historisées gardent l'état du dictionnaire à une date donnée, ce qui permet de reconstituer la version en production. Un développeur doit savoir dans quelle bibliothèque il se trouve avant de toucher une entité commune.
Programmes batch et code structuré
Un programme batch se décrit par ses appels de structures de données (-CD), ses zones de travail (-W) et son code procédural (-P), découpé en fonctions et sous-fonctions avec niveaux et conditions. Le générateur produit la lecture des fichiers, leur synchronisation et les ruptures. Le développeur n'écrit que ce qui sort de ce standard.
Macro-structures paramétrées
Des blocs de code réutilisables qu'un programme appelle avec ses propres paramètres (-CP). Les équipes y rangent leurs standards : contrôle de date, gestion d'erreur, accès à une table commune. Modifier une macro-structure touche tous les programmes qui l'appellent, d'où l'importance de l'analyse d'impact.
Dialogue
Le module qui décrit les écrans transactionnels, leur enchaînement et leurs contrôles, et qui génère le programme pour le moniteur cible, CICS le plus souvent sur z/OS. Les postes de maintenance y passent moins de temps que sur le batch, mais l'ajout d'un champ à l'écran reste une demande courante.
Procédures batch et références croisées
Des procédures batch servent à la mise à jour en masse (UPDT), aux extractions (EXTR, PACX), à la sauvegarde et à la restauration (SAVE, REST) ou à la réorganisation (REOR). Les références croisées (-XP pour les programmes, -XO pour les écrans) listent qui utilise une entité. Un développeur confirmé s'en sert pour l'analyse d'impact au lieu de fouiller les sources.
COBOL généré, JCL et DB2
Le source produit est du COBOL classique, compilé et lancé par du JCL comme le reste du mainframe. Les accès DB2 passent par des blocs base de données décrits dans le dictionnaire ou par du SQL embarqué. Savoir lire ce code généré reste indispensable pour diagnostiquer un abend en production.
RPP (Rational Programming Patterns)
L'outil d'IBM qui reprend les entités et la génération PACBASE dans Rational Developer for z, un environnement Eclipse. Les offres écrivent souvent « PACBASE / RPP » ensemble. Vérifiez sur lequel des deux la personne a réellement travaillé, car l'environnement de développement et la gestion des sources diffèrent.
Le travail dépend de la phase de vie de l'application. En maintenance, le développeur corrige et fait évoluer les programmes dans le dictionnaire, en respectant les standards de la bibliothèque et en régénérant tout ce qui est touché. Sur une migration, il lit le COBOL généré, écarte les traitements morts et prépare la version native qui sera maintenue dans Endevor, ChangeMan ou Git. Les deux missions demandent un bon niveau en COBOL, en JCL et en DB2, et une méthode de non-régression. La version 3.5 de VisualAge Pacbase est la dernière, IBM oriente ses clients vers RPP, et beaucoup d'équipes maintiennent encore l'environnement en attendant d'en sortir.
Les points techniques à valider chez un développeur PACBASE
- Dictionnaire et entités PACBASE
- Bibliothèques, sessions et analyse d'impact
- Programmes batch et code structuré
- Macro-structures paramétrées
- COBOL généré, JCL et DB2
- Migration vers COBOL natif ou RPP
Les questions qu'un développeur PACBASE doit traiter sans ouvrir le manuel
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é
Une rubrique montant passe de 9 à 11 chiffres. Que faites-vous dans PACBASE avant de modifier quoi que ce soit ?
Une bonne réponseElle part des références croisées de la rubrique pour lister les segments, structures de données, écrans et programmes qui l'utilisent. Elle repère les fichiers et les tables DB2 dont le format change et prévoit la conversion des données existantes. Ensuite seulement, elle modifie la rubrique dans la bonne bibliothèque, régénère et recompile tous les programmes concernés, et teste les plus exposés.
Signal d'alerteModifier directement la PICTURE dans le COBOL généré, ou changer la rubrique et ne régénérer que le programme du ticket.
Question 2 · senior
La macro-structure maison de contrôle de date, appelée par 400 programmes, contient un bug. Comment la corrigez-vous ?
Une bonne réponseElle liste les programmes appelants par les références croisées (-XP) et lit les paramètres de chaque appel (-CP) pour connaître les cas d'usage. Elle écrit une correction compatible avec les appels existants, la teste sur un échantillon qui couvre ces cas, puis planifie la régénération et la recompilation de tous les appelants. Elle prévient les équipes qui partagent la bibliothèque commune.
Signal d'alerteCorriger la macro-structure et régénérer seulement le programme du ticket, sans voir que les autres prendront la modification à leur prochaine génération, testée ou non.
Question 3 · senior
Un programme batch lit deux fichiers triés sur le numéro de client. Comment le décrivez-vous dans PACBASE sans coder l'appariement à la main ?
Une bonne réponseElle déclare les deux structures de données dans les appels (-CD) avec leur organisation et leurs indicatifs de synchronisation sur le numéro de client. Le générateur produit la lecture, la comparaison et les indicateurs de rupture et de synchronisation. Elle écrit son traitement dans des fonctions conditionnées par ces indicateurs : premier ou dernier enregistrement d'un client, client présent dans un seul des deux fichiers.
Signal d'alerteRecoder l'appariement en COBOL dans le code procédural, en doublon de ce que le générateur fait déjà.
Question 4 · confirmé
Un batch de nuit s'arrête en S0C7 dans un programme généré. Comment remontez-vous de l'abend au dictionnaire ?
Une bonne réponseLe message d'abend et l'offset désignent l'instruction en cause. Elle la retrouve dans le listing de compilation, puis remonte à la fonction PACBASE qui l'a produite grâce au nommage des paragraphes générés. Un S0C7 signale une donnée numérique invalide : elle isole l'enregistrement fautif dans le fichier d'entrée, corrige la cause (contrôle absent, format de rubrique) dans le dictionnaire, puis relance la chaîne au bon pas.
Signal d'alertePatcher le source généré en production, ou relancer tout le job sans avoir isolé l'enregistrement.
Question 5 · senior
Le client veut sortir de PACBASE et maintenir son code en COBOL natif. Que devient le source généré, et quels risques voyez-vous ?
Une bonne réponseLe COBOL généré devient le source de référence. Il faut figer le dictionnaire, générer une dernière fois tous les programmes depuis la bonne session et vérifier que ce source compile et produit les mêmes résultats. Les risques sont connus : un code verbeux aux paragraphes numérotés, des macro-structures dupliquées dans chaque programme, la perte des références croisées et de la documentation du dictionnaire. Elle propose un nettoyage, une factorisation en copybooks ou en sous-programmes, et un autre outil d'analyse d'impact.
Signal d'alerte« On récupère les sources et c'est terminé », sans parler de dernière génération, de tests ni de ce qu'on perd avec le dictionnaire.
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
Recruter sur PACBASE : vos questions
Un développeur COBOL sans expérience PACBASE peut-il tenir le poste ?
Sur une migration, souvent oui, parce que le travail porte sur le COBOL généré, le JCL et les tests. En maintenance dans le dictionnaire, comptez une période d'adaptation : il faut apprendre les entités, les bibliothèques, le code structuré et le réflexe de ne jamais corriger le source généré. Vérifiez en entretien la lecture d'un programme généré et la logique des ruptures, que beaucoup de développeurs COBOL connaissent déjà sous une autre forme.
PACBASE et RPP, est-ce le même poste ?
Les compétences se recoupent largement. RPP reprend les entités et la génération de PACBASE dans Rational Developer for z, un environnement Eclipse, à la place des écrans en mode terminal ou de la station de travail PACBASE. Un développeur PACBASE s'y adapte vite. Si votre application est déjà passée sous RPP, demandez tout de même une expérience de l'outil, car l'environnement de travail et la gestion des sources changent.
Quel test technique proposer à un développeur PACBASE ?
Un exercice sur écran partagé suffit. Montrez un extrait de COBOL généré avec ses paragraphes numérotés et le compte rendu d'un abend, et demandez un commentaire à voix haute. La personne explique d'où vient chaque bloc, où elle corrigerait dans le dictionnaire et ce qu'elle testerait. Sans dictionnaire de test disponible, faites décrire les écrans -CD, -W et -P qu'elle remplirait pour un petit programme avec rupture.
Combien de temps prévoir pour un entretien technique PACBASE ?
Une heure à une heure et demie convient en général : vingt minutes sur les missions passées et l'environnement réel (versions, bibliothèques, outil de livraison), une demi-heure de questions par axe, puis le cas pratique de 20 minutes. Pour un poste de migration, gardez plus de temps pour le cas et la non-régression. Le PDF de Delectus suit ce découpage, avec une grille commune pour comparer les candidatures.
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.
