Le poste porte plusieurs noms selon les sites : ingénieur de production, intégrateur d'exploitation, ingénieur d'intégration mainframe. La personne intègre les livraisons des équipes COBOL dans les environnements d'homologation puis de production, suit le plan de l'ordonnanceur (CA 7, IBM Z Workload Scheduler ou Control-M) et traite les incidents batch, le matin ou en astreinte. Les questions d'entretien d'un ingénieur de production mainframe portent donc sur l'exploitation des applications : lecture d'une sortie de job, reprise, dépendances, livraison et retour arrière.
Beaucoup de CV mélangent développement COBOL et production. Un développeur sait trouver l'instruction qui a provoqué un abend. L'ingénieur de production doit dire si le job peut repartir, depuis quelle étape, et ce qu'il faut remettre en état avant. Le candidat raconte une reprise précise, avec le code d'abend, ce qui avait été écrit avant l'échec et l'action passée dans l'ordonnanceur.
Une partie des postes ajoute une chaîne de livraison plus récente, avec Digital.ai Release, Git ou Zowe à côté d'Endevor ou de ChangeMan ZMF, et des outils maison propres au site. Reste à savoir ce que la personne utilisait elle-même. Le PDF reprend l'entretien sur six axes avec 30 questions, un cas de 20 minutes et une grille de 1 à 4.
Ordonnanceur, JCL, outils de livraison : l'environnement du poste
JCL et codes retour
Le langage qui décrit chaque job batch : les étapes, les programmes appelés, les fichiers lus et créés. L'ingénieur de production ne l'écrit pas toujours, mais il le lit tous les jours pour comprendre un échec ou une condition d'exécution. Il doit distinguer une erreur de JCL, un code retour posé par le programme et un abend système.
SDSF et la console z/OS
SDSF affiche les jobs en file, en cours et terminés, avec leur sortie complète. C'est le premier écran ouvert quand un job tombe. Le journal système (SYSLOG ou OPERLOG) montre en plus les attentes de fichiers, les montages de bandes et les messages des sous-systèmes.
Ordonnanceurs : CA 7, IBM Z Workload Scheduler, Control-M
Ils lancent les jobs selon un calendrier, des dépendances entre jobs et l'arrivée de fichiers. CA 7 est édité par Broadcom, Control-M par BMC. IBM Z Workload Scheduler est l'ancien TWS for z/OS, encore appelé OPC sur beaucoup de CV. Le poste consiste à suivre le plan de la nuit, à suspendre, relancer ou forcer un job, et à créer les définitions des nouveaux traitements.
Endevor et ChangeMan ZMF
Les deux outils de gestion des livraisons les plus cités dans les offres. Ils font passer sources et modules d'un environnement à l'autre par packages ou par étapes de promotion. Une livraison comprend souvent la compilation, la copie en bibliothèque de production, un BIND Db2 et une prise en compte côté CICS. Le retour arrière fait partie du travail.
CICS et IMS côté exploitation
Après une livraison, un programme CICS doit être rechargé (NEWCOPY ou PHASEIN par la transaction CEMT), un fichier fermé puis rouvert, une région IMS parfois arrêtée. L'ingénieur de production n'administre pas ces moniteurs, mais il passe ces commandes ou les demande, et il sait ce qu'elles coupent pour les utilisateurs.
Fichiers : GDG, VSAM et bandes
Les chaînes créent et lisent des générations de fichiers (GDG), des fichiers VSAM et des sauvegardes sur bandes virtuelles. Une reprise oblige souvent à savoir quelle génération est la bonne, ou à restaurer un fichier avant de relancer. IDCAMS et les utilitaires de tri font partie des outils courants.
Db2 for z/OS vu du batch
Une grande partie des jobs met à jour des tables Db2. L'ingénieur de production reconnaît les SQLCODE qui reviennent en production, sait qu'un job qui a déjà validé des mises à jour ne se relance pas comme un job de lecture, et sait quand appeler le DBA.
Outil de tickets et chaîne de livraison récente
Incidents et changements passent par un outil ITSM, ServiceNow ou un outil interne. Certains sites ajoutent Digital.ai Release (ex-XL Release), Git et Zowe pour automatiser les livraisons sur z/OS. Ces outils s'ajoutent en général à ceux déjà en place et à leurs procédures.
Le périmètre change d'un site à l'autre. Sur certains, l'ingénieur de production suit le batch et les reprises. Sur d'autres, il intègre aussi les livraisons de bout en bout, crée les jobs dans l'ordonnanceur et teste en homologation. Une astreinte de nuit ou de week-end est fréquente. Les candidats viennent souvent du pupitrage ou du développement COBOL. Les premiers connaissent bien l'ordonnanceur et la console, les seconds le JCL et les programmes, et chacun a des manques. En mission, la personne doit aussi reprendre vite les procédures et les outils maison du client.
Les acquis à contrôler chez un ingénieur de production z/OS
- Lecture du JCL, des sorties et des codes d'abend
- Reprise et relance de chaînes batch
- Ordonnancement : plan, dépendances, calendriers
- Livraison et retour arrière (Endevor, ChangeMan)
- Effets d'une livraison sur CICS, IMS et Db2
- Incidents, changements et automatisation du run
Cinq situations de production mainframe et les réponses attendues
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é
Un job de nuit est tombé en SB37. Que s'est-il passé, et comment le relancez-vous ?
Une bonne réponseUn fichier en sortie a manqué de place : l'allocation primaire et les extensions secondaires sont épuisées sur le volume. La personne trouve dans la sortie la DD concernée et le message d'erreur d'espace, fait corriger le paramètre SPACE ou l'allocation, puis traite le fichier à moitié écrit avant de relancer l'étape. Un bon profil distingue SB37, SD37 (pas d'allocation secondaire prévue) et SE37 (plus d'extensions ou de volumes possibles).
Signal d'alerte« On relance » sans rien changer, ou on agrandit l'espace sans s'occuper du fichier partiel, et la relance tombe en erreur parce que le fichier existe déjà.
Question 2 · confirmé
La procédure d'un job dit « relançable depuis le début ». Il est tombé après avoir validé des mises à jour Db2. Le relancez-vous tel quel ?
Une bonne réponsePas sans vérifier. La personne regarde ce que le programme a validé avant l'abend et s'il gère sa propre reprise, par exemple avec une table de points de reprise. Si les mises à jour déjà faites seraient rejouées en double, il faut une remise en état avant : restauration demandée au DBA, suppression des fichiers créés, remise à zéro d'un compteur. En cas de doute, elle appelle l'astreinte applicative avant de relancer.
Signal d'alerteUne relance immédiate parce que la procédure le dit, sans se demander si la procédure tient compte d'un abend après validation.
Question 3 · confirmé
Dans l'ordonnanceur, quelle différence faites-vous entre mettre un job en attente, l'annuler du plan et le forcer à terminé ?
Une bonne réponseEn attente, le job et ses successeurs patientent jusqu'à la libération. Annulé du plan, il ne tournera pas, et ses successeurs peuvent ne jamais partir si rien ne remplace la dépendance. Forcé à terminé, il est considéré comme réussi et libère ses successeurs, ce qui n'est acceptable que si le travail est fait autrement ou inutile ce jour-là. La personne donne l'équivalent dans l'outil qu'elle connaît, par exemple Set to OK dans Control-M.
Signal d'alerteUn job forcé à terminé pour « débloquer la chaîne », sans se demander ce que les jobs suivants vont lire.
Question 4 · confirmé
Un job crée la génération (+1) d'un GDG et tombe à l'étape suivante. Que se passe-t-il si vous le relancez sans rien faire ?
Une bonne réponseTout dépend du DISP prévu en cas d'abend. Si la génération a été cataloguée, une relance en crée une nouvelle et les jobs suivants qui lisent la génération (0) prennent la dernière, alors que la (-1) ne désigne plus le même fichier. La personne vérifie d'abord avec un LISTCAT, supprime la génération incomplète ou adapte la reprise, puis relance. Elle sait qu'une relance en étape dans le même job ne se comporte pas comme un nouveau job pour les références relatives.
Signal d'alerteUne relance directe, et le lendemain une chaîne qui lit le mauvais fichier sans que personne comprenne pourquoi.
Question 5 · confirmé
Une livraison contient un programme CICS modifié. Après la promotion, que faut-il pour que la nouvelle version tourne vraiment ?
Une bonne réponseLe module doit être dans une bibliothèque de la concaténation DFHRPL de la région. S'il contient du SQL, le package Db2 doit être lié (BIND) avec la même version. Ensuite, un NEWCOPY ou un PHASEIN par CEMT fait charger la nouvelle version, vérifiée par CEMT INQUIRE PROGRAM. Pour un module batch dans une bibliothèque gérée par LLA, un rafraîchissement de LLA est nécessaire.
Signal d'alerte« La promotion suffit », et des utilisateurs qui tournent sur l'ancienne version jusqu'au redémarrage de la région.
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
Production mainframe : questions fréquentes
Quelle différence entre un ingénieur de production mainframe et un ingénieur système z/OS ?
L'ingénieur système z/OS, ou system programmer, installe et maintient le système lui-même : SMP/E, IPL, paramétrage du Sysplex, montées de version. L'ingénieur de production mainframe travaille sur les applications qui tournent dessus : chaînes batch, livraisons, ordonnanceur, incidents. Les deux se parlent souvent, mais les questions d'entretien n'ont presque rien en commun. Une offre qui mélange les deux mérite d'être clarifiée avant de recevoir les candidats.
Quelle part de COBOL attendre d'un ingénieur de production mainframe ?
Il doit lire un programme COBOL assez pour suivre ce qu'il fait d'un fichier ou d'une table, et comprendre une erreur remontée dans la sortie d'un job. Écrire ou modifier du code n'est pas son rôle. Le JCL compte bien plus : il le lit chaque jour, le corrige parfois sur les paramètres d'exécution et doit savoir ce qu'une étape a créé avant de tomber.
Quel test technique proposer à un ingénieur de production mainframe ?
Une sortie de job réelle, anonymisée, avec un abend à expliquer, convient bien : la personne dit ce qui s'est passé et comment elle relancerait. S'y ajoute un extrait de plan de nuit avec des dépendances : quel est l'effet d'un job forcé à terminé ? Vingt à trente minutes suffisent, sans accès à un système. La manière de lire la sortie renseigne autant que la conclusion.
Les ordonnanceurs CA 7, IZWS et Control-M sont-ils interchangeables sur un CV ?
La logique est la même : plan, dépendances, calendriers, déclenchement par fichier, reprise. Les écrans, les commandes et le vocabulaire diffèrent, et un candidat en apprend un nouveau sur le terrain. La pratique d'un ordonnanceur mainframe en production compte plus qu'un produit précis, sauf si le poste consiste à créer et maintenir les définitions de jobs, où la connaissance de l'outil en place fait gagner du temps.
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.
