1) Avec mon profil DevOps / Backend, quels modules ou compétences

devrais-je approfondir pour être rapidement opérationnel sur un projet

mainframe ?
Exemples concrets :

● JCL (Job Control Language) : c’est l’équivalent d’un script shell qui lance les
traitements batch. Ex : tu écris un script JCL pour compiler un programme COBOL
ou lancer un job de reporting journalier.

● COBOL : apprendre les bases pour comprendre la logique métier. Par exemple,
savoir lire un programme de calcul d’intérêt sur un prêt.

● DB2 (SQL sur mainframe) : pour gérer les bases de données relationnelles. Tu
devras par exemple optimiser une requête qui extrait les clients dont le solde est
négatif.

● Outils de déploiement comme Jenkins ou IBM UrbanCode Deploy : si tu fais déjà du

Jenkins, comprendre comment il s’interface avec des jobs JCL ou des scripts de
transfert de load modules en PROD.

● Systèmes de fichiers (VSAM, séquentiels) : savoir différencier un fichier indexé d’un

séquentiel dans un traitement de relance client.
● // Commandes AS400

2) Est-ce que la communauté autour de COBOL est active ? Existe-t-il

des forums ou des communautés techniques ?
Exemples concrets :

Oui, la communauté est bien vivante, notamment sur :

● Stack Overflow, où tu peux poser des questions techniques sur COBOL, JCL, DB2…

● Reddit (r/cobol, r/mainframe) : discussions actives, retours d’expérience.

● IBM Developer : propose des articles, webinaires et documentations sur COBOL,

DB2, etc.

● LinkedIn : de nombreux groupes COBOL/Mainframe pour le partage de bonnes

pratiques.

● Micro Focus Forums : utiles si tu utilises Visual COBOL ou Enterprise Developer.

3) Quelles sont les tendances pour moderniser les applications

COBOL ?
Exemples concrets :

● Exposition des traitements COBOL via API REST : par ex., un programme COBOL
de consultation de solde peut être exposé via une API consommée par une appli
web Angular.

● Utilisation de wrappers Java ou Python autour des programmes COBOL.

● Migration vers des plateformes cloud hybrides : certaines banques migrent des
traitements COBOL vers AWS en utilisant des émulateurs z/OS comme Micro Focus
ou IBM ZD&T.

● Modernisation de l’interface utilisateur : remplacement des écrans verts 3270 par des
interfaces web.

4) Est-ce que la gestion du code source COBOL se fait avec des outils
modernes (Git, GitLab…) ou via des outils mainframe spécifiques ?
Exemples concrets :

● Oui, les deux existent :

○ Git/GitLab/GitHub sont utilisés avec des plugins comme Zowe ou IBM

Dependency Based Build pour intégrer le code mainframe dans un pipeline
CI/CD.

○ Exemple : tu pushes ton code COBOL sur Git, Jenkins déclenche un build
avec compilation via JCL.

○ ARCAD Skipper / RTC / Endevor / Changeman : outils traditionnels de

gestion de version sur mainframe, souvent intégrés dans un workflow
sécurisé pour PROD.

5) Est-ce qu’il existe des environnements de développement COBOL

locaux ou cloud pour pratiquer sans accéder directement au
mainframe ?
Exemples concrets :

● Micro Focus Visual COBOL (Windows/Linux) : environnement local complet avec

débogueur, éditeur, simulateur de fichiers VSAM. Ex : tu peux coder un programme
COBOL qui lit un fichier [Link] et affiche les soldes.

● IBM ZD&T (Z Development and Test Environment) : émule un mainframe z/OS sur
un PC ou dans le cloud. Utilisé par les banques pour former leurs développeurs sans
impacter la PROD.

● GnuCOBOL : open source, bon pour apprendre la syntaxe mais ne gère pas les
spécificités mainframe comme les JCL, CICS, etc.
 ● IBM Wazi Sandbox : environnement cloud sur IBM Cloud pour simuler un z/OS
complet, pratique pour tester COBOL + DB2 + JCL.

6) En termes de debugging, est-ce que les outils mainframe permettent

du pas-à-pas comme dans les IDE modernes ?
Exemples concrets :

● IBM Debug Tool : outil natif pour le pas-à-pas, visualisation des variables,
breakpoints. Ex : tu mets un point d’arrêt dans une boucle de traitement de comptes
pour voir pourquoi un solde est erroné.

● Rational Developer for z (RDz) ou VS Code avec Zowe : permettent le debug à

distance sur le mainframe avec interface graphique, très proche de ce que tu connais
sur Visual Studio Code ou IntelliJ.

● Explication pratique : tu peux suivre l’exécution ligne par ligne d’un traitement
COBOL batch, voir la valeur des variables en mémoire, et stopper dès qu’une
condition est remplie.

7) Sur la partie DB2 : y a-t-il des outils pour visualiser facilement les
plans d’exécution et optimiser les requêtes ?
Exemples concrets :

● IBM Data Studio : équivalent de SQL Server Management Studio, permet de

visualiser les plans d’exécution, identifier les full scans, créer des index.

● DSN_STATEMENT_TABLE : permet de capturer les statistiques d’un SQL

dynamique ou statique.

● Pratique typique : tu identifies qu’une requête sur le fichier des transactions

bancaires prend 10s à s’exécuter, tu utilises Data Studio pour voir qu’elle n’utilise
pas d’index sur le champ DATE_TRANSACTION, donc tu proposes d’en créer un.

● Autres outils : BMC Catalog Manager, IBM OMEGAMON for DB2.

8) En intégration d’API REST/SOAP avec COBOL, y a-t-il des contraintes

de sécurité ou des standards spécifiques au mainframe ?
Exemples concrets :

● Oui, contraintes fortes côté sécurité :

 ○ Authentification souvent via certificats, tokens JWT ou Basic Auth sécurisé.

○ Sécurité TLS/SSL gérée par RACF (système d’habilitation mainframe).

● Appels REST/SOAP depuis COBOL via des wrappers C ou des passerelles comme
IBM z/OS Connect EE :

○ Exemple : un service COBOL de virement est exposé via z/OS Connect et

appelé par une appli mobile.

● Standards : respect du modèle API Gateway + sécurité mutualisée (OAuth2, IP

whitelisting, etc.)

9) Quelle est la différence entre UrbanCode et Jenkins dans le contexte

mainframe ?
Exemples concrets :

● Jenkins : généraliste, bon pour déclencher des pipelines CI/CD (test, build COBOL
via JCL, déploiement).

○ Exemple : un commit sur GitLab déclenche un Jenkins Pipeline qui exécute

un job JCL pour compiler un programme.

● UrbanCode Deploy (UCD) : spécialisé dans le déploiement multi-environnement

(DEV, TEST, PROD) avec contrôle de version, rollback, approbations.

○ Exemple : tu déploies une nouvelle version d’un programme de calcul

d’intérêts sur plusieurs LPARs, avec rollback automatique en cas d’échec.

● En pratique : Jenkins = automatisation, UrbanCode = orchestration de déploiement

sécurisé.

10) Sur IBM DataStage, quelles sont les bonnes pratiques pour
concevoir des flux ETL performants ?
Exemples concrets :

● Partitionnement : diviser les gros volumes pour traitement parallèle. Ex : découpage

par plage de dates pour charger les opérations bancaires.

● Push-down optimization : déléguer au maximum les transformations à DB2 (via SQL)

plutôt qu’à DataStage.

● Limiter les lookups volumineux : par ex., utiliser un hash file ou join explicite au lieu
d’un lookup dynamique sur une grande table client.
 ● Utiliser les séquences de jobs : pour chaîner les traitements avec gestion d’erreurs,
logs, relances automatiques.

● Rejet et audit : prévoir des flux de rejets pour les lignes KO (ex : données
corrompues dans des virements).

1. Explique-moi la structure d'un programme COBOL classique.

Structure type :

cobol
CopierModifier
IDENTIFICATION DIVISION.
PROGRAM-ID. CALCUL-INTERETS.

ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT FICHIER-CLIENT ASSIGN TO '[Link]'.

DATA DIVISION.
FILE SECTION.
FD FICHIER-CLIENT.
01 CLIENT-RECORD.
05 NUM-CLIENT PIC 9(5).
05 NOM PIC A(30).
05 SOLDE PIC 9(7)V99.

WORKING-STORAGE SECTION.
01 INTERET PIC 9(5)V99 VALUE 0.
01 FIN-FICHIER PIC X VALUE 'N'.

PROCEDURE DIVISION.
DEBUT.
OPEN INPUT FICHIER-CLIENT
PERFORM JUSQU'A FIN-FICHIER = 'O'
READ FICHIER-CLIENT
AT END MOVE 'O' TO FIN-FICHIER
NOT AT END
COMPUTE INTERET = SOLDE * 0.03
DISPLAY "INTERET : " INTERET
END-READ
 END-PERFORM
CLOSE FICHIER-CLIENT
STOP RUN.

Explication :

● IDENTIFICATION DIVISION : nom du programme.

● ENVIRONMENT DIVISION : description de l’environnement, notamment les fichiers.

● DATA DIVISION : variables de travail, fichiers en entrée/sortie.

● PROCEDURE DIVISION : logique métier, boucles, traitements, calculs.

2. Comment gère-t-on la lecture et l’écriture de fichiers en COBOL ?

Exemples :

● Fichier d’entrée :

cobol
CopierModifier
READ FICHIER-ENTREE
AT END MOVE 'O' TO FIN
NOT AT END DISPLAY CLIENT-RECORD
END-READ

● Fichier de sortie :

cobol
CopierModifier
WRITE FICHIER-SORTIE FROM DONNEE-CALCULEE

Types d’accès :

● Séquentiel : lecture ligne par ligne (comme un CSV).

● Indexé (VSAM) : accès direct à un enregistrement via une clé.

Exemple concret :
Un programme lit tous les virements du jour (fichier séquentiel) et écrit les anomalies dans
un fichier de rejet.
3. Quelles sont les différences entre un fichier séquentiel et un fichier
indexé en COBOL ?
Critère Fichier Séquentiel Fichier Indexé (VSAM)

Accès Séquentiel uniquement Accès direct et séquentiel

Performance Lent pour gros volumes Rapide si la clé est bien choisie

Usage typique Logs, historiques Fichiers clients, contrats,

comptes

Exemple concret :

● Un fichier séquentiel contient la liste des transactions du jour (ordre chronologique).

● Un fichier indexé permet de chercher rapidement les infos d’un client via son NUM-
CLIENT.

4. Comment traiter les erreurs d'exécution dans un programme COBOL ?

Méthodes courantes :

● Utiliser les mots-clés INVALID KEY, AT END, ON SIZE ERROR :

READ FICHE-CLIENT
AT END DISPLAY "FIN DU FICHIER"

MULTIPLY A BY B
ON SIZE ERROR DISPLAY "OVERFLOW"

● Utiliser des codes de retour (RETURN-CODE, variables spécifiques) :

MOVE 8 TO RETURN-CODE

● Logs et Fichiers de rejet :

Ex : si une ligne contient une valeur illisible (ex : solde négatif ou champ non
numérique), on l’écrit dans un fichier de rejet.
5. Comment gérer les performances d’un traitement batch COBOL
volumineux ?
Bonnes pratiques :

● Limiter les accès base/fichiers : éviter les accès répétés à DB2 dans une boucle.

● Utiliser des READ SEQUENTIEL optimisés : regrouper les lectures et les écritures.

● Travailler en mémoire avec des tables internes (arrays COBOL) :

OCCURS 10000 TIMES

● Traitements par lot (commit DB2 régulier) : tous les 500 ou 1000 enregistrements.

● Index bien définis pour les accès DB2 ou VSAM.

● Déclenchement en horaires creux (nocturnes).

Exemple concret :
Une banque exécute un batch de relance client sur 1 million de lignes :

● Lecture du fichier client en séquentiel.

● Traitement avec table COBOL.

● Commit DB2 tous les 1000 clients.

● Rejets traités à part.

Questions sur JCL et exécution Mainframe

1. Qu'est-ce que JCL et comment soumet-on un job ?

JCL (Job Control Language) : langage de script mainframe pour exécuter des
programmes, compiler, gérer des fichiers, etc.

Exemple de soumission :

//JOB1 JOB (ACCT),'TRAITEMENT DAILY',CLASS=A,MSGCLASS=X

//STEP1 EXEC PGM=CALCUL-INTERETS
//INFILE DD DSN=[Link],DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*

Soumission :

● Depuis TSO/ISPF : commande SUB sur l’écran 3.4 ou via SDSF.

● Automatiquement via Jenkins, UrbanCode ou un ordonnanceur (Control-M, OPC…).

2. Quelles sont les étapes de compilation et d'exécution d’un programme

COBOL via JCL ?
Étapes classiques :

1. Précompilation (si DB2) : transforme le code avec des appels SQL en code
COBOL + DB2 API.

○ DSNHPC est utilisé.

2. Compilation COBOL : IGYCRCTL ou IGYCRCT.

3. Link-Edit : création du load module.

○ IEWL est appelé.

4. Exécution :

○ JCL appelle le programme via EXEC PGM=….

Exemple :

//COMPILE EXEC PGM=IGYCRCTL

//STEPLIB DD DSN=[Link],DISP=SHR
//SYSLIN DD DSN=&&OBJ,UNIT=SYSDA,DISP=(MOD,PASS)
//SYSPRINT DD SYSOUT=*

//LINK EXEC PGM=IEWL

//SYSLMOD DD DSN=[Link](PROG1),DISP=SHR

3. Comment gérer les dépendances entre plusieurs jobs dans un flux

batch ?
Méthodes :
 ● Utiliser ORDONNANCEURS (Control-M, OPC/Tivoli, DollarU).

○ Exemple : le job de génération des relevés n’est lancé qu’après le job de

calcul des intérêts.

● Dans un JCL : IF (RC = 0) pour vérifier si le step précédent est OK.

● Dans un script Jenkins : enchaîner les jobs par statut (build job1 && build
job2).

4. Quelles sont les méthodes pour relancer un job en erreur sans

reprendre tout le traitement ?
Méthodes :

● RESTART dans le JCL :

//JOB1 JOB ...,RESTART=STEP3

● Utiliser un ordonnanceur qui permet la relance ciblée du step en erreur.

● Étapes idempotentes : découper les steps pour relancer facilement, par exemple :

○ STEP1 : chargement fichier

○ STEP2 : traitement

○ STEP3 : mise à jour DB2

Questions sur DB2

5. Comment interroger une base DB2 depuis COBOL ?

Syntaxe :

EXEC SQL
SELECT NOM, SOLDE INTO :NOM-C, :SOLDE-C
FROM CLIENTS
WHERE NUMERO = :NUM-C
END-EXEC.

● Le : indique des host variables COBOL.

● La clause INTO stocke les résultats dans des variables COBOL.

6. Comment gérer les erreurs SQL dans un programme COBOL ?

Utilisation de SQLCODE et SQLSTATE :

cobol
CopierModifier
IF SQLCODE < 0
DISPLAY "ERREUR SQL : " SQLCODE
END-IF

Exemple :

● SQLCODE = 0 → OK

● +100 → Pas de ligne trouvée

● -911 → Timeout ou deadlock

7. Quelles sont les bonnes pratiques pour améliorer les performances

des requêtes DB2 ?
● Utiliser des index sur les colonnes de recherche.

● Éviter les SELECT *.

● Limiter les accès dans des boucles COBOL.

● Analyser les plans d'exécution avec IBM Data Studio.

● Batch : regrouper les updates dans des commits réguliers.

● JOINTURES INNER LEFT RIGHT

8. Comment faire du commit/rollback dans un programme COBOL qui

manipule DB2 ?
EXEC SQL COMMIT END-EXEC.
EXEC SQL ROLLBACK END-EXEC.

Exemple concret :

● Tu fais un traitement de virement par lot.

● Tous les 500 clients, tu fais un COMMIT.

● Si erreur critique, tu fais un ROLLBACK et tu logues l’incident.

💸 Questions sur les flux bancaires

9. Quels sont les types de flux batch qu’on peut retrouver dans un
système bancaire ?
● Flux de virements / prélèvements SEPA

● Mise à jour des soldes journaliers

● Calcul des agios, intérêts, commissions

● Éditions de relevés de compte

● Chargement des fichiers BDF, Swift, BCE

10. Comment garantir la cohérence des transactions dans un traitement

bancaire batch ?
● Contrôle de verrouillage (LOCKING) des lignes DB2.

● Utilisation de COMMIT/ROLLBACK pour maintenir l’atomicité.

● Numéros de lot / date traitement pour tracer chaque opération.

● Fichiers de rejet + logs pour ne traiter que les lignes valides.

11. Quels contrôles met-on en place pour garantir l’intégrité des

données dans un système bancaire Mainframe ?
 ● Contrôles de structure : longueur, type de champs, clé présente.

● Contrôles métier : solde suffisant, client actif, IBAN valide.

● Contrôles croisés : total des montants sortants = total des entrants.

● Logs + validation manuelle en cas d’écarts.

12. Comment sont gérées les coupures / redémarrages lors des

traitements critiques (fin de journée bancaire) ?
● Fichiers de reprise : permettent de savoir où reprendre.

● Points de synchronisation (COMMIT régulier).

● Ordonnanceurs qui relancent automatiquement en cas de coupure.

● États de batch stockés dans des tables techniques.

🔐 Questions autour de la sécurité

13. Comment sécuriser les échanges de données dans un

environnement Mainframe bancaire ?
● SFTP / FTPS pour transferts sécurisés.

● TLS/SSL avec certificats.

● Chiffrement PGP/GPG des fichiers sensibles.

● Accès REST via Gateway sécurisée (OAuth2, Basic Auth).

14. Comment gérer les habilitations et les droits d'accès dans un

système bancaire Mainframe ?
● RACF (IBM) : gère les utilisateurs, groupes, profils. Ressource Access Control
Facility

○ Exemple : l’utilisateur DEV001 a accès à [Link].* mais pas PROD.*

● Top Secret / ACF2 : alternatives à RACF selon les organisations.

15. Quelles sont les meilleures pratiques pour assurer la traçabilité et
l’auditabilité des traitements ?
● Logs détaillés par job/step.

● Historique des traitements (qui a lancé quoi, quand, avec quoi).

● Journaux DB2 (audit trail).

● Contrôles croisés automatisés + vérifications manuelles.

🔄 Questions sur la modernisation et l’intégration

16. Comment intégrer un système Mainframe avec des systèmes

modernes (API REST/SOAP, middleware) ?
● z/OS Connect EE : expose COBOL/DB2 via REST.

● MQSeries : pour échanger des messages asynchrones (Java ↔ COBOL).

● APIGEE / IBM API Gateway en frontal.

Exemple : une appli mobile appelle une API REST → passe par z/OS Connect →
exécute un programme COBOL → réponse en JSON.

17. Quels sont les outils ou techniques pour moderniser

progressivement une application COBOL sans refonte complète ?
● Écriture de wrappers Java autour des fonctions COBOL critiques.

● Utilisation de Microservices qui appellent des API COBOL.

● Migration incrémentale vers Java avec Gradle et JPA, en gardant DB2.

18. Quel est l’apport du CI/CD dans un environnement bancaire

Mainframe ?
● Automatisation des compilations, tests et déploiements via Jenkins.
● Réduction du temps de mise en prod (plus besoin de soumission manuelle).

● Rollback rapide via UrbanCode.

● Suivi qualité du code (SonarQube pour COBOL).