Lire du JCL commence par l'ordre d'exécution

Le JCL devient lisible dès qu'on cesse de le prendre pour un programme et qu'on le traite comme un graphe de contrôle sérialisé. La source nomme les programmes, fournit les ressources et déclare les conditions, mais plusieurs systèmes décident de ce qui s'exécute réellement : le convertisseur développe les procédures, le catalogue résout les jeux de données, JES et l'initiateur fixent le contexte du job, le planificateur peut injecter des symboles, et un opérateur peut reprendre le job au milieu. Lire seulement les cartes visibles mène facilement à un diagramme convaincant et faux.

Le premier passage vise une seule chose : retrouver les étapes dans l'ordre, les données lues et écrites par chacune et les conditions qui peuvent les supprimer. Les détails de syntaxe viennent ensuite. J'ai vu des équipes passer une matinée sur les colonnes et les virgules sans voir qu'une procédure cataloguée ajoutait six étapes et que le planificateur choisissait la génération de la veille. Commencez par le comportement, puis prouvez-le par la syntaxe.

Un membre JCL est un graphe de contrôle, pas un script

Un job contient normalement une instruction JOB suivie d'instructions EXEC, avec des instructions DD rattachées à chaque EXEC. Cela paraît séquentiel et l'est au niveau supérieur : sans saut, erreur, reprise ou fin anormale, JES présente les étapes dans l'ordre à un initiateur. Pourtant, le membre affiché peut ne contenir qu'une partie du graphe. Un EXEC peut appeler une procédure cataloguée ou intégrée, JCLLIB peut changer les bibliothèques de recherche, et INCLUDE peut ajouter des instructions avant l'exécution.

Séparez quatre phases. À l'entrée, JES lit le job et applique les règles d'entrée. À la conversion, le système vérifie le JCL, développe les procédures et résout les symboles. À l'allocation, z/OS trouve ou crée les jeux de données et périphériques nécessaires à l'étape. À l'exécution, le programme choisi tourne et renvoie un code ou se termine anormalement. Le traitement des sorties et la purge entourent ce flux sans transformer le JCL en logique applicative.

Cette distinction explique pourquoi un job peut échouer avant le lancement de son premier programme. Une procédure absente, un paramètre symbolique non résolu, un nom d'étape en double, un DD invalide ou un jeu de données indisponible peut produire une erreur JCL pendant la conversion ou l'allocation. Ne qualifiez pas tout job rouge d'échec applicatif. Demandez d'abord si un programme a reçu le contrôle. Les messages JES et le journal du job le disent.

Dessinez un graphe sommaire avant de lire les opérandes. Créez un nœud par étape EXEC développée, une flèche pleine pour la séquence normale, une flèche pointillée pour chaque condition et des arêtes de données pour les jeux nommés entre producteurs et consommateurs. Ajoutez trois états qui ne sont pas des fichiers ordinaires : symboles résolus à la conversion, état du catalogue consulté à l'allocation et codes retour produits à l'exécution. Ce dessin révèle vite les preuves manquantes.

L'ordre source reste utile, mais il ne répond qu'à une question : dans quel ordre les étapes éligibles passeraient-elles ? Il ne dit pas si elles sont éligibles, ce qu'une procédure développe, quelle génération physique désigne un GDG relatif ni où commence une reprise. Le membre est l'entrée d'une exécution, pas son compte rendu.

Les instructions EXEC définissent les unités de travail

Chaque EXEC crée une étape, et son opérande indique si elle lance directement un programme ou appelle une procédure. EXEC PGM=IEFBR14 nomme un programme. EXEC PROC=DAILY, ou la forme courte EXEC DAILY, appelle une procédure. Le nom à gauche d'EXEC est le repère stable pour conditions, substitutions, reprises et messages. Notez-le exactement.

Partons d'un exemple compact :

//BILLING  JOB (ACCT),'DAILY BILL',CLASS=A,MSGCLASS=X
//EXTRACT  EXEC PGM=EXTBILL,PARM='DAILY'
//INPUT    DD DSN=APP.CUST.MASTER,DISP=SHR
//OUT      DD DSN=APP.BILL.WORK(+1),DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(20,10)),UNIT=SYSDA
//SORT     EXEC PROC=SORTBILL,INDSN=APP.BILL.WORK(+1)
//LOAD     EXEC PGM=LOADBILL,COND=(0,NE,SORT)
//IN       DD DSN=APP.BILL.SORTED(+1),DISP=SHR

Le plan visible est EXTRACT, SORT, LOAD. Ce n'est pas encore un plan d'exécution. SORTBILL peut développer plusieurs étapes. SORT identifie l'étape appelante, tandis que les messages et conditions internes utilisent des noms qualifiés tels que SORT.COPY. Une condition peut supprimer LOAD. Les deux noms de génération relatifs exigent le contexte du catalogue.

Lisez un EXEC dans cet ordre : nom d'étape, PGM ou procédure, contrôles conditionnels, limites de région ou de temps si présentes, puis texte de paramètre transmis au programme. PARM n'est pas de la logique JCL. Le JCL transmet le texte; seul le contrat du programme explique PARM='DAILY'. Même avertissement pour SYSIN. Son contenu ressemble souvent à un autre langage parce qu'il en est un, consommé par un utilitaire, un outil de base de données, un compilateur ou un programme interne.

Une procédure crée deux espaces de noms. Le job appelant a un nom d'étape externe et la procédure des noms internes. Les messages, substitutions et reprises peuvent les qualifier. Dans votre tableau aplati, nommez chaque étape SORT.COPY et conservez sa source de procédure. Sinon, deux procédures qui possèdent STEP1 paraîtront désigner la même étape.

Les programmes peuvent aussi allouer des données dynamiquement via SVC 99 ou une bibliothèque. Ces allocations n'apparaissent pas sous forme de DD dans le JCL soumis. Si un programme ouvre un jeu introuvable, consultez ses messages, traces d'allocation, sources ou configuration avant de conclure qu'un DD manque. Le JCL déclare une grande partie de l'environnement, pas forcément sa totalité.

Les instructions DD lient les noms du programme aux ressources

Une instruction DD appartient à l'EXEC précédent jusqu'au prochain EXEC. Son nom de gauche est généralement celui que le programme ouvre; les opérandes décrivent la ressource et son cycle de vie. Lisez //INPUT DD DSN=APP.CUST.MASTER,DISP=SHR ainsi : pour cette étape, lier le nom INPUT du programme à ce jeu catalogué avec accès partagé. INPUT n'est pas une variable persistante. Une autre étape peut définir son propre INPUT avec un autre sens.

Classez chaque DD dans l'une de cinq catégories : jeu catalogué, nouveau jeu, jeu temporaire, données intégrées ou sortie système. DSN= identifie un jeu. DD * et DD DATA introduisent des enregistrements dans le job. SYSOUT=* envoie la sortie vers la classe du job. DUMMY fait agir de nombreuses méthodes d'accès comme si l'entrée était vide ou la sortie jetée. Un DD absent peut être volontaire si le programme alloue dynamiquement ou le traite comme facultatif; vérifiez son contrat.

DISP comporte jusqu'à trois parties : statut initial, action après fin normale et action après fin anormale. DISP=(NEW,CATLG,DELETE) demande un nouveau jeu, le catalogue après fin normale et le supprime après fin anormale. DISP=SHR demande un jeu existant en partage. OLD exige en général l'exclusivité, tandis que MOD positionne pour extension et possède des règles de création à vérifier dans le manuel IBM. DISP décrit allocation et devenir, pas la réussite métier. Un programme peut rendre 8 normalement, et l'action normale s'applique puisqu'il n'a pas abendé.

Les noms temporaires commencent par && et vivent normalement pendant le job. Le passage d'un tel nom du producteur au consommateur crée une arête de données nette, même sans catalogue. À l'inverse, deux DSN permanents de noms proches ne prouvent aucun lien. Le planificateur peut fournir les deux, ou un job antérieur avoir créé l'entrée.

La concaténation piège aussi la lecture visuelle. Des DD consécutifs peuvent former un seul flux logique lorsque les suivants omettent le ddname. Les bibliothèques STEPLIB ou JOBLIB sont cherchées dans l'ordre, donc le premier module correspondant gagne. Les concaténations d'entrée sont présentées en séquence, mais leur compatibilité dépend de la méthode d'accès et des attributs. Conservez-les comme une liaison ordonnée.

Les substitutions peuvent remplacer ou ajouter des DD dans une procédure. //SORT.COPYIN DD DSN=APP.SPECIAL.INPUT,DISP=SHR cible COPYIN dans l'étape COPY de la procédure appelée par SORT. La procédure seule ment alors sur l'exécution, et le membre appelant semble porter un DD orphelin. Seule l'expansion donne une vue fidèle.

La référence IBM z/OS JCL définit les opérandes, mais pas les ddname exigés par votre programme ni les enregistrements attendus dans SYSIN. Cherchez la documentation d'interface ou le comportement OPEN et d'allocation dynamique du programme. Le JCL décrit la liaison, le programme décrit le contrat. Confondre les deux donne des migrations qui gardent les noms de fichiers et cassent le comportement.

Le développement des procédures révèle la source absente

Vous ne pouvez établir l'ordre d'exécution avant d'avoir développé toutes les procédures et tous les groupes INCLUDE avec les bibliothèques et symboles du run. Une procédure cataloguée est du JCL réutilisable stocké en bibliothèque. Une procédure intégrée se trouve entre PROC et PEND dans le job. Toutes deux peuvent contenir EXEC, DD, paramètres symboliques et appels imbriqués dans les limites du système.

La liste développée dans les sorties JES vaut souvent mieux qu'une recherche du dépôt, car elle enregistre ce que la conversion a produit pour cette soumission. Cherchez la liste JCL, souvent JESJCL, et les messages JESYSMSG et JESMSGLG. La configuration locale change conservation et affichage. Si la liste et Git divergent, vérifiez d'abord si le planificateur a soumis un membre généré ou choisi une autre PROCLIB.

Les paramètres symboliques prennent des formes comme &INDSN.. Le point peut terminer le nom et disparaître à la substitution. Les valeurs par défaut vivent sur PROC, l'appelant les remplace sur EXEC, SET affecte des valeurs et le planificateur peut substituer avant même que JES lise le texte. Gardez l'expression et la valeur résolue. La seule valeur rend le prochain run imprévisible; la seule source empêche d'expliquer le run observé.

JCLLIB et les concaténations locales contrôlent la recherche. Deux bibliothèques peuvent contenir un membre du même nom; leur ordre choisit celui qui sera développé. C'est l'équivalent d'une version de dépendance encodée dans l'ordre des bibliothèques plutôt que dans un manifeste. Relevez le membre, la bibliothèque, le niveau de modification disponible et les instructions développées.

Les substitutions s'appliquent après la définition réutilisable. Elles peuvent changer des paramètres EXEC, remplacer ou neutraliser des DD et ajouter des liaisons. Une syntaxe très courte peut donc cacher un gros changement. Marquez chaque champ remplacé dans le graphe aplati et citez les deux emplacements.

Ne collez pas manuellement le texte des procédures pour déclarer l'analyse terminée. On oublie vite appels imbriqués, limites de symboles, priorité des bibliothèques et substitutions. Prenez la sortie de conversion d'un run enregistré comme référence, puis reconstruisez son origine. TYPRUN=SCAN sert souvent à vérifier la syntaxe, mais son effet exact dépend de la politique JES locale. Un scan ne prouve rien sur les données applicatives ni le comportement à l'exécution.

Les noms GDG dépendent d'un catalogue changeant

Un generation data group est une entrée de catalogue gérant une suite de jeux de générations. Une base telle que APP.BILL.WORK se référence par nom absolu ou relatif : (0) pour la génération courante, (-1) pour la précédente et souvent (+1) pour une nouvelle. La forme relative est pratique en exploitation mais incomplète pour l'analyse, car le nom physique dépend du catalogue.

Lorsqu'une étape crée APP.BILL.WORK(+1) avec NEW et que les suivantes lisent la même génération relative, le job transmet la nouvelle génération sans figer son GxxxxVyy. Votre graphe doit conserver la référence relative et le nom absolu observé. Ne remplacez jamais les références par ce que signifie (0) aujourd'hui. Le catalogue a pu avancer depuis.

Le cas difficile est celui d'un producteur sauté ou en échec suivi d'un consommateur. Si EXTRACT alloue WORK(+1), abende et applique DELETE, SORT ne reçoit aucune nouvelle génération valide. Selon ses conditions et le moment d'allocation, il sera sauté, échouera à l'allocation ou verra un autre état du catalogue. Reprendre seulement SORT plus tard peut faire de (+1) une nouvelle allocation au lieu de la sortie attendue. La syntaxe relative ne porte pas la filiation.

Un autre piège traverse les jobs. Le planificateur peut faire créer une génération par JOB A et lire (0) par JOB B. Aucun membre ne montre cette dépendance. Si JOB B part trop tôt ou qu'un opérateur rejoue JOB A, (0) peut désigner autre chose. Plan du planificateur, historique du catalogue et horaires font partie du programme. Le dépôt ne prouve pas les enregistrements lus.

Construisez un registre GDG avec étape, DD, référence relative, disposition, DSN absolu résolu, action catalogue et résultat observé. Remplissez-le avec les messages d'allocation et les preuves du catalogue, jamais par supposition. Pour un échec, notez si l'allocation a fini et quelle disposition s'est appliquée. Ce registre tranche généralement la question d'une reprise qui réutilise ou recrée une génération.

La documentation IBM distingue la base GDG, son modèle et ses limites des jeux de générations individuels. Gardez cette distinction. Supprimer ou décataloguer une génération ne modifie pas la base, et une génération sortie de la limite n'est pas forcément effacée immédiatement du volume. En pratique, une référence GDG relative est une requête de catalogue dans le contexte du run, pas un nom de fichier fixe.

Les codes condition suppriment des étapes selon les résultats antérieurs

Un programme terminé normalement fournit un code retour, souvent RC ou CC dans la sortie. Le JCL peut l'utiliser pour décider si une étape ultérieure passe. Un code d'abend diffère d'un retour normal, et une erreur de conversion ou d'allocation peut empêcher tout code programme. Mettez RC, abend système, abend utilisateur et erreur JCL dans des colonnes séparées. Les réduire à succès ou échec détruit l'information utile aux conditions.

L'ancien paramètre COND est un test de contournement. Avec COND=(0,NE,SORT), le système compare le littéral 0 au RC de SORT avec NE. Si 0 diffère du RC, le test est vrai et l'étape courante est sautée. LOAD ne passe donc que lorsque SORT rend 0. Beaucoup inversent le sens en lisant COND comme une condition d'exécution. Préfixez toujours par sauter si, puis traduisez la comparaison.

Quelques exemples rendent l'inversion nette :

• COND=(4,LT,COMPILE) signifie sauter si 4 est inférieur au RC de COMPILE, donc un RC supérieur à 4 supprime l'étape.
• COND=(0,EQ,CHECK) signifie sauter si CHECK a rendu 0.
• COND=EVEN permet d'examiner l'étape même après un abend antérieur, sous réserve des autres règles.
• COND=ONLY ne lance l'étape qu'après un abend antérieur, toujours dans le contexte complet.

Le JCL moderne peut employer IF, THEN, ELSE et ENDIF, plus proches de la logique applicative. Les expressions peuvent citer des retours qualifiés et l'état d'abend. Elles contrôlent les étapes, pas l'intérieur des programmes. Imbrication et qualification peuvent étendre un bloc IF au-delà de l'écran; marquez les limites sur le plan développé.

COND au niveau job et étape interagit avec les erreurs, et une procédure peut définir des conditions remplacées par l'appelant. Ne les réduisez pas à une flèche verte. Pour chaque étape, écrivez une expression d'éligibilité fondée sur les résultats précédents, puis évaluez-la pour le run. Vous séparez ainsi chemins possibles et chemin historique.

Le sens d'un code retour appartient au programme. RC 4 signifie souvent avertissement pour des utilitaires IBM, mais un programme interne peut décider autrement. Un planificateur peut accepter une plage comme succès tandis qu'un COND distingue 0 de 4. Conservez trois politiques : ce que dit le programme, ce que le JCL saute et ce que le planificateur classe réussi. Un voyant ne les représente pas toutes.

Une reprise change le début sans changer le membre

Un job repris ne démarre pas nécessairement à son premier EXEC. La reprise peut nommer une étape du job ou d'une procédure; un outil local ou le planificateur peut générer la demande effective. Le membre peut rester identique alors que l'exécution commence au milieu. Tout diagramme dépourvu d'identité de run et de métadonnées de reprise reste provisoire.

La sûreté d'une reprise dépend de l'état des données, pas seulement de l'ordre. Les étapes antérieures ont pu cataloguer des sorties, modifier une base, imprimer des enregistrements, envoyer des messages ou valider des checkpoints. Commencer à STEP5 n'annule rien. À l'inverse, une disposition anormale peut avoir supprimé une entrée nécessaire à STEP5. Avant d'autoriser la reprise, listez tous les effets antérieurs et toutes les entrées requises.

Une reprise sur checkpoint dans un programme diffère d'une reprise d'étape JCL. Un utilitaire peut continuer à l'intérieur d'une étape, tandis que JES reprend à une frontière EXEC. Preuves et règles de récupération diffèrent. Si un opérateur dit que le job a été repris, demandez mécanisme, cible et identifiants exacts.

Les planificateurs ajoutent une couche invisible. Ils calculent des dates, choisissent des membres, injectent des SET, ajoutent des dépendances, attendent des ressources et classent les codes retour. Rien de cela ne doit figurer dans le JCL stocké. Un job amont peut produire le DSN lu par la première étape visible. Une règle calendaire peut choisir une autre procédure en clôture mensuelle. Obtenez définition et trace de soumission du planificateur avec le spool.

L'état externe modifie même un rejeu propre. La génération GDG courante avance, les entrées sont remplacées, les tables changent et l'ordre des bibliothèques peut charger un nouveau programme. Un rejeu prouve le comportement actuel sous l'état actuel. Il ne reproduit l'original qu'avec ses entrées, résolutions de catalogue, binaires, symboles et contrôles.

Les opérateurs donnent aussi des commandes et répondent à des demandes de volume ou de périphérique. Ces actions vivent rarement dans le dépôt. Journal du job, logs d'automatisation et ticket d'exploitation peuvent contenir l'arête manquante. Si une étape attendait une bande ou a été annulée après un délai, la source seule n'expliquera ni durée ni statut final.

Le spool est une preuve, pas du bruit

La façon la plus rapide de comprendre un batch hérité consiste à associer la source au spool d'un succès et d'un échec représentatif. La source montre les possibilités prévues. Le spool montre conversion, allocation, messages, retours et chemin d'une soumission réelle. Aucun ne remplace l'autre.

Commencez par nom du job, job ID, système, heure de soumission, ordre ou run ID du planificateur et statut de reprise. Réunissez ensuite liste JCL convertie, messages JES et système, puis SYSOUT applicatif. JESJCL, JESMSGLG et JESYSMSG sont des noms fréquents, mais la politique locale varie. Conservez la matière brute avant sa purge.

Lisez chronologiquement en étiquetant les phases. Les messages du convertisseur expliquent symboles et syntaxe. Ceux d'allocation relient DD, jeux et volumes. Les messages de fin donnent programme, retour et abend. Les messages applicatifs expliquent comptes métier et décisions d'utilitaires. Les sorties sont tamponnées, donc utilisez aussi identité d'étape et de message, pas seulement l'heure.

Pour chaque étape développée, relevez une ligne observée :

SORT.COPY | PGM=SORT | ran=yes | RC=0004 | abend=none
  COPYIN  -> APP.BILL.WORK.G0123V00      DISP=SHR
  COPYOUT -> APP.BILL.SORTED.G0098V00   DISP=(NEW,CATLG,DELETE)
  gate    -> eligible after EXTRACT RC=0000

Ce format volontairement banal se compare facilement et force l'inconnu à apparaître. Si le DSN absolu manque, écrivez inconnu et nommez la preuve requise. Ne substituez jamais silencieusement la valeur actuelle du catalogue.

Comparez succès et échec par étape développée, programme, DSN résolus, symboles, conditions et résultats. La première différence compte souvent plus que l'abend final. Une génération d'entrée différente peut provoquer un contrôle tardif; une STEPLIB modifiée peut charger un autre code sous le même nom; un RC d'avertissement peut sauter le nettoyage et polluer le run suivant.

Masquez identifiants secrets et données réglementées avant de déplacer le spool vers des systèmes d'ingénierie généraux. JCL et SYSOUT peuvent contenir champs de compte, jetons dans PARM, instructions de base ou enregistrements métier complets. Traitez le spool comme une preuve de production. En environnement isolé, gardez preuves et outils dans le périmètre du client.

Un tableau de trace rend l'archéologie vérifiable

Un tableau doit permettre à un autre ingénieur de contester votre modèle sans relire tout le spool. Utilisez une ligne par EXEC développé, dans l'ordre effectif. Les colonnes minimales sont nom qualifié, programme, origine de procédure, symboles résolus, DD d'entrée et sortie, règle d'éligibilité, RC ou abend observé et conséquence de reprise. Ajoutez les allocations dynamiques découvertes.

Suivez cette séquence :

1. Figez source, enregistrement du planificateur, JCL développé, spool et résolutions catalogue d'un run sous un identifiant commun.
2. Développez procédures et INCLUDE, résolvez les symboles et donnez un nom qualifié à chaque EXEC.
3. Rattachez DD et concaténations, puis résolvez les GDG vers les noms absolus observés.
4. Traduisez chaque COND ou IF en règle d'éligibilité et évaluez-la contre les résultats enregistrés.
5. Marquez début réel, étapes sautées, allocations dynamiques, actions opérateur et effets importants pour la reprise.

Relisez le tableau dans deux sens. De haut en bas, confirmez le contrôle. Pour chaque jeu, suivez producteur et consommateurs afin de confirmer la filiation. Un fichier sans producteur peut être un flux externe, une dépendance du planificateur ou un reste. Une sortie sans consommateur peut être un rapport, un échange ou du travail mort. Ne la supprimez pas avant de comprendre exploitation et rétention.

Séparez faits et hypothèses. SORT.COPY returned 4 est un fait du spool. RC 4 means duplicate records reste une hypothèse avant confirmation par les contrôles et messages SORT. La résolution de APP.BILL.WORK(+1) en G0123V00 est historique. Prédire le même nom à la reprise exige une analyse du catalogue et de la reprise. Cette discipline empêche une histoire plausible de devenir spécification.

Le tableau révèle aussi la frontière de migration. Programmes, conditions JCL, dépendances du planificateur, catalogue et gestes opérateur forment ensemble le batch. Traduire le COBOL en ignorant le JCL ne conserve que sa partie visible. Un service moderne a besoin d'orchestration explicite, d'identité durable des données, de règles de rejeu et de résultats observables conformes à l'ancien comportement utile.

CodeHero lit ensemble tout l'arbre COBOL et JCL, puis vérifie le système réécrit contre le trafic de production enregistré avec un harnais de parité. Une conversion ligne par ligne ne peut retrouver le comportement qui vivait dans le choix des procédures, les DD, l'état GDG ou les habitudes de reprise.

La modernisation doit rendre l'ordre caché explicite

La modernisation la plus sûre ne reproduit pas chaque instruction JCL dans une syntaxe neuve. Elle conserve le comportement observable et transforme les dépendances implicites en contrats nommés et testables. Un jeu temporaire peut devenir un objet ou une table de préparation, un passage GDG un artefact immuable lié au run, une condition COND une transition d'état explicite. L'architecture cible peut changer, mais les tests de parité doivent couvrir ce dont dépendent systèmes et opérateurs.

Commencez la spécification par des runs enregistrés, pas un dessin de mémoire. Choisissez cas normaux, avertissements, pannes de producteur, échecs d'allocation et reprises. Capturez identité des entrées, étapes développées, sorties, classes de retour et effets externes. Le trafic de production constitue une preuve utile s'il inclut messages et échanges qui définissent le comportement, sous les contraintes de sécurité du client.

Ne reproduisez pas aveuglément les accidents historiques. Certains comportements sont contractuels, d'autres servent l'exploitation, d'autres sont des défauts invisibles. Demandez quels consommateurs dépendent d'un détail, puis écrivez un test qui nomme la décision. Si le nouveau système change volontairement une règle, consignez l'écart approuvé au lieu d'affaiblir la comparaison jusqu'à son passage.

Une exécution isolée peut être requise lorsque sources, spool ou données de production ne doivent pas quitter le périmètre client. Cela concerne déploiement et traitement des données; ce n'est pas une certification de conformité. Séparez ces affirmations en revue d'architecture et en achat.

Un plan de bascule crédible répond à des questions concrètes : quelle opération neuve correspond à chaque ancienne étape, comment figer l'identité des entrées, comment éviter les effets en double lors d'un rejeu, comment mapper les avertissements, comment reprendre un run partiel et quelle preuve établit la parité. Si l'équipe ne sait pas répondre, elle n'a pas fini de lire le JCL. Étudier davantage la syntaxe ne réparera rien. Reconstituez complètement un run avec tout ce que le membre a omis, et le batch cessera d'être mystérieux.