Bases de JCL et du traitement par lots : instructions JOB/EXEC/DD, codes retour, soumission depuis USS et lecture de la sortie

Ce que c'est

Le Job Control Language (JCL) décrit une unité de travail par lots sous la forme d'une structure réduite et fixe. Une instruction JOB nomme le job et porte les informations de comptabilité et de classe. Une ou plusieurs instructions EXEC nomment chacune un programme (ou une procédure cataloguée) à exécuter comme étape. Les instructions DD (Data Definition) rattachent à l'étape les datasets, fichiers USS ou données in-stream que le programme lit ou écrit, sous les ddnames qu'il attend (par exemple SYSIN pour les commandes en entrée, SYSPRINT pour un rapport). Le cursus d'initiation aux mainframes d'IBM enseigne cette structure avec JES et SDSF (System Display and Search Facility).

Chaque étape produit un code condition (son code retour) à la fin de son exécution. Selon une convention ancienne, suivie par les utilitaires IBM et la plupart des programmes bien conçus, 0 signifie une exécution réussie, 4 un avertissement (l'étape a bien effectué quelque chose, mais il faut le signaler), 8 une erreur assez grave pour qu'on ignore normalement les étapes suivantes, et 12 ou plus une erreur sérieuse ou fatale. Le JCL peut utiliser le paramètre COND= d'une étape, ou les constructions JCL plus récentes IF/THEN/ELSE, pour exécuter ou sauter les étapes suivantes en fonction du code retour d'une étape précédente. C'est l'équivalent batch d'un test de $?, déclaré dans le JCL. Attention : COND= indique quand une étape est court-circuitée, soit l'inverse d'un if. Un abend (fin anormale, affiché sous la forme d'un code système tel que S0C7 ou S806, ou d'un code utilisateur Unnnn) n'est pas un code retour : l'étape n'a pas de RC, et les étapes suivantes sont sautées, sauf si elles précisent COND=EVEN/ONLY ou testent ABEND dans un IF.

Depuis un shell z/OS UNIX, submit filename lit un dataset ou un fichier USS contenant du JCL, le transmet à JES pour exécution, puis affiche le nom du job et l'identifiant de job attribué par JES. La sortie peut ensuite être lue de manière interactive avec SDSF, l'outil intégré à ISPF pour parcourir la sortie spool d'un job et ses codes condition, ou de manière programmatique avec l'API REST jobs de z/OSMF, qui renvoie l'état et le contenu du spool sous forme de réponses HTTP structurées. C'est la plus adaptée aux agents des deux (voir l'article sur z/OSMF).

Pourquoi c'est important

Un agent qui soumet des travaux par lots doit vérifier les codes condition réels de chaque étape, et pas seulement que « la commande submit a réussi » (la soumission signifie seulement que JES a accepté le job ; le job lui-même peut encore échouer à chaque étape). Il lui faut aussi un moyen de récupérer la sortie spool qui ne l'oblige pas à piloter un émulateur de terminal.

Comment l'appliquer

• Avant de considérer un job soumis comme réussi, vérifier le code retour de chaque étape et rechercher les abends ou un JCL ERROR (le job ne s'est jamais exécuté), et ne pas se limiter à l'état d'achèvement global du job.
• Préférer submit associé à l'API REST jobs de z/OSMF (ou à SDSF) pour récupérer l'état et la sortie spool par programme, plutôt que d'extraire le contenu d'un écran 3270.
• Lire les instructions DD d'un job avant de supposer quel dataset ou fichier une étape a réellement utilisé : les noms de fichiers par défaut du programme ne comptent plus dès qu'une instruction DD les remplace.

Pièges

• Traiter systématiquement RC=4 comme un échec ; de nombreux utilitaires l'emploient pour des avertissements bénins, et certains pour des avertissements significatifs. C'est la documentation du programme concerné qui tranche.
• Supposer qu'un job avec RC=0 à chaque étape a fait ce qui était prévu ; un code retour indique le signal de réussite propre au programme, et non si le résultat métier est correct.