Développeur COBOL z/OS : CICS, DB2, JCL et abends de production

Le développeur COBOL z/OS maintient et fait évoluer des applications qui tournent sur mainframe IBM depuis des années : transactions CICS, programmes batch enchaînés par JCL, données dans DB2 et dans des fichiers VSAM. La plupart du travail porte sur du code qu'il n'a pas écrit, et une erreur se révèle souvent la nuit, dans une chaîne de production.

Recevoir la fiche complète

Mis à jour le Par l'équipe Delectus5 min de lecture

La fiche Développeur COBOL z/OS : technologies, chaîne du poste, une question et la grille d'évaluation

Un poste COBOL z/OS mélange souvent maintenance, évolutions et support de production. Le développeur lit un programme de plusieurs milliers de lignes, retrouve les copybooks et les tables DB2 qu'il touche, modifie la règle demandée, compile, fait le BIND, teste en recette et prépare la livraison avec l'outil du site, Endevor ou ChangeMan par exemple. Le matin, il regarde aussi les chaînes batch tombées pendant la nuit.

Les CV se ressemblent : COBOL, JCL, DB2, CICS, TSO/ISPF. L'écart se voit sur les incidents. Un développeur expérimenté lit un abend S0C7 ou ASRA, retrouve l'instruction fautive dans le listing de compilation et reprend un job à l'étape en échec sans doubler les écritures en base. Demandez le dernier incident de production traité et la façon dont il a été diagnostiqué.

Le poste change aussi. Enterprise COBOL 6 a remplacé les anciennes versions du compilateur, et la migration peut modifier le comportement d'un programme sur des données numériques invalides. Beaucoup d'équipes travaillent aussi sous VS Code avec Zowe et Git, à côté de l'écran 3270. Le PDF contient 30 questions sur six axes et un cas de 20 minutes.

Le socle z/OS d'un développeur COBOL

Enterprise COBOL for z/OS

Le compilateur COBOL d'IBM, aujourd'hui en version 6. Le langage sert aux règles de gestion, aux calculs sur montants et au traitement de fichiers. Les zones numériques packées (COMP-3) et les copybooks partagés entre programmes sont au centre du quotidien. Le compilateur 6 ajoute des options de contrôle des données à l'exécution, utiles lors d'une migration.

JCL

Le langage qui décrit les travaux batch : programmes à lancer, fichiers en entrée et en sortie, conditions d'enchaînement des étapes. Un développeur COBOL écrit et lit du JCL tous les jours, avec les utilitaires associés (DFSORT, IDCAMS, IEBGENER) et les GDG pour l'historique des fichiers.

DB2 for z/OS

La base relationnelle du mainframe. Le SQL est embarqué dans le COBOL, précompilé, puis lié en package par le BIND, qui fixe le chemin d'accès. Le développeur doit lire un SQLCODE, gérer les curseurs et les COMMIT d'un batch, et comprendre un EXPLAIN avec le DBA.

CICS Transaction Server

Le moniteur transactionnel qui fait tourner les écrans 3270 et, de plus en plus, des services appelés par d'autres applications. Les programmes sont écrits en pseudo-conversationnel et échangent leurs données par COMMAREA ou par channels. La version actuelle est CICS TS 6.3.

VSAM

Les fichiers indexés ou séquentiels du mainframe, encore très présents à côté de DB2. Le KSDS, accédé par clé, est le plus courant. On les définit et on les recharge avec IDCAMS. Les FILE STATUS renvoyés au programme disent si une lecture ou une écriture a réussi.

IMS

La base hiérarchique et le moniteur transactionnel historiques d'IBM, présents sur une partie des sites seulement. Les programmes accèdent aux segments par des appels DL/I. Si votre application en utilise, écrivez-le dans l'offre : peu de développeurs COBOL le pratiquent.

Ordonnanceurs

TWS, Control-M ou CA 7 enchaînent les jobs de la nuit selon leurs dépendances et leurs calendriers. Le développeur ne les administre pas, mais il décrit à l'exploitation ce que fait chaque job, ses codes retour et la conduite à tenir en cas d'abend.

Outils de développement

Endevor ou ChangeMan ZMF pour gérer les sources et les livraisons. BMC AMI DevX (anciens outils Compuware) avec File-AID, Abend-AID et Code Debug, ou IBM z/OS Debugger. Zowe et VS Code complètent TSO/ISPF sur les sites qui ont modernisé leur poste de travail.

Le développeur COBOL z/OS travaille en maintenance applicative ou en équipe projet, sur des applications de gestion qui traitent de gros volumes. Les intitulés varient : analyste programmeur, concepteur développeur, ingénieur études et développement. Le poste comprend presque toujours une part de support de production et une part de spécifications avec les équipes métier. Beaucoup d'équipes forment aussi des développeurs venus d'autres langages, qui apprennent COBOL en quelques mois. Pour ces profils, la compréhension du batch, du transactionnel et de la reprise après incident compte plus que le nombre d'années. Précisez dans l'offre si le site utilise IMS, MQ ou un générateur comme PACBASE : ce sont des compétences à part.

Les six compétences à évaluer sur un profil COBOL z/OS

  • Langage COBOL et formats numériques
  • SQL embarqué et DB2 z/OS
  • Programmation CICS pseudo-conversationnelle
  • JCL, batch et reprise après incident
  • Fichiers VSAM, échanges et IMS
  • Analyse d'impact et mise en production

Questions de production pour un développeur COBOL z/OS

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.

  1. Question 1 · confirmé

    Un batch est tombé en S0C7 cette nuit. Comment retrouvez-vous la donnée et l'instruction en cause ?

    Une bonne réponseS0C7 est une exception de données : un calcul, un MOVE ou une comparaison sur une zone packée (COMP-3) ou zonée qui contient autre chose que des chiffres, des espaces ou des low-values par exemple. Il part du dump ou du rapport d'Abend-AID, prend l'offset dans le module et le rapproche du listing de compilation (options LIST ou OFFSET) pour trouver l'instruction et la zone. Il regarde ensuite l'enregistrement d'entrée avec File-AID. La correction ne se limite pas au plantage : test IF ... NUMERIC à l'entrée, zone initialisée, enregistrement rejeté vers un fichier d'anomalies.

    Signal d'alerte« Je relance le job », ou des zéros forcés dans la zone sans chercher d'où vient la donnée.

  2. Question 2 · junior à confirmé

    Votre programme reçoit un SQLCODE -811 sur un SELECT INTO. Que signifie-t-il, et que faites-vous ?

    Une bonne réponseLe SELECT INTO a trouvé plus d'une ligne. Soit la règle métier garantit une ligne unique et ce sont les données qui posent problème (doublon à analyser, contrainte d'unicité absente), soit la requête doit passer par un curseur, ou par FETCH FIRST 1 ROW ONLY avec un ORDER BY qui désigne la bonne ligne. Il teste SQLCODE après chaque ordre : 0, +100 et les négatifs.

    Signal d'alerteAjouter FETCH FIRST 1 ROW ONLY sans se demander quelle ligne sera retenue.

  3. Question 3 · confirmé

    Pourquoi une transaction CICS s'écrit-elle en pseudo-conversationnel, et comment le programme retrouve-t-il son contexte à l'écran suivant ?

    Une bonne réponsePour ne garder aucune tâche, aucun verrou ni aucune mémoire pendant que l'utilisateur lit l'écran. Le programme envoie la map puis fait EXEC CICS RETURN TRANSID(...) COMMAREA(...). Au retour, EIBCALEN indique s'il s'agit du premier passage, et la COMMAREA restaure l'état. Elle est limitée à 32 Ko : au-delà, on passe par des channels et des containers.

    Signal d'alerteUn RECEIVE qui attend la saisie en gardant la tâche active, ou un état gardé en WORKING-STORAGE d'un écran à l'autre.

  4. Question 4 · confirmé

    Un job de six étapes tombe à l'étape 4 après avoir écrit dans une table et créé un fichier. Comment le relancez-vous ?

    Une bonne réponseIl regarde d'abord ce que les étapes 1 à 3 ont produit et si l'étape 4 a déjà commité une partie de ses mises à jour. Les fichiers créés sont supprimés ou réutilisés selon leur DISP, par exemple DISP=(NEW,CATLG,DELETE). Il redémarre à l'étape en cause (RESTART sur la carte JOB ou par l'ordonnanceur) en s'appuyant sur la table de reprise du programme. Il suit la consigne d'exploitation du job, ou la rédige si elle manque.

    Signal d'alerteRelancer tout le job depuis le début sans vérifier ce qui a déjà été écrit.

  5. Question 5 · confirmé

    On vous demande de modifier le calcul d'un montant dans un programme de 8 000 lignes que personne ne connaît plus. Par où commencez-vous ?

    Une bonne réponsePar l'analyse d'impact : lecture de la PROCEDURE DIVISION autour du calcul, des copybooks et du listing de référence croisée pour suivre la zone. Il cherche les autres programmes qui relisent ce montant dans les fichiers ou les tables, et les jobs ou transactions qui appellent le programme. Avant de toucher au code, il prépare un jeu d'essai et garde les sorties de la version actuelle pour les comparer après la modification. La modification reste minimale et documentée.

    Signal d'alerteModifier le paragraphe repéré et tester un seul cas.

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 en COBOL z/OS, les doutes fréquents

Un développeur COBOL sans expérience CICS peut-il prendre le poste ?

Oui si le poste est surtout batch, et c'est fréquent. S'il comporte des écrans ou des services transactionnels, prévoyez quelques semaines d'apprentissage : le pseudo-conversationnel, la COMMAREA, les codes RESP et la gestion des abends sous CICS ne s'improvisent pas. En entretien, vérifiez qu'il connaît au moins le principe. Un développeur solide en batch et en DB2 apprend CICS plus vite qu'un profil faible ne progresse en batch.

COBOL sur AS400 et COBOL z/OS, est-ce le même profil ?

Le langage est proche, l'environnement non. Sur IBM i, il n'y a ni JCL, ni CICS, ni VSAM : le développeur travaille avec du CL, des écrans 5250 et DB2 for i. Un développeur COBOL AS400 lit sans peine un programme z/OS, mais il lui faudra plusieurs mois pour être autonome sur les chaînes batch, le BIND DB2 et les outils du mainframe. Traitez-le comme une reconversion partielle.

Un test technique a-t-il du sens pour un développeur COBOL ?

Oui, à condition de rester proche du poste. Donnez un programme court avec un abend et son listing, et demandez de trouver la cause. Ou un JCL de trois étapes à relancer après un échec. Trente minutes en entretien suffisent. Un exercice d'algorithmique générique dit peu de choses sur un développeur qui passera ses journées dans du code existant et des chaînes de production.

Faut-il exiger IMS dans l'offre ?

Seulement si votre application l'utilise vraiment. IMS ne concerne qu'une partie des sites mainframe, et les développeurs qui le pratiquent sont rares. Si vous l'exigez sans en avoir besoin, vous réduisez beaucoup le vivier. S'il est présent, écrivez si c'est IMS DB, IMS TM ou les deux, et posez au moins une question sur les appels DL/I. Un bon développeur DB2 apprend IMS en quelques semaines avec un accompagnement.

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.

Les fiches voisines

Toutes les fiches →

Voyez Delectus sur vos propres offres.

Commencez gratuitement. Passez à l'échelle quand vous êtes prêt.

Demander une démo

Votre ATS, connecté à Delectus

  • Workable
  • Teamtailor
  • iCIMS
  • Lever
  • SmartRecruiters
  • Jobvite
  • Greenhouse
  • Pinpoint