Vous trouverez ci-dessous les paramètres en commun entre EXEC et JOB :
Paramètre de mot-clé
Description
ADDRSPPC
ADDRSPC codé dans l’instruction JOB remplace l’ADDRSPC codé dans l’instruction EXEC de toute étape de job.
TIME
Si TIME est codé dans une instruction EXEC, il s’applique uniquement à cette étape de job. S’il est spécifié à la fois dans les instructions JOB et EXEC, les deux seront en vigueur et peuvent provoquer une erreur de temporisation due à l’un ou l’autre. Il n’est pas recommandé d’utiliser le paramètre TIME dans les instructions JOB et EXEC ensemble.
REGION
Si REGION est codé dans une instruction EXEC, il s’applique uniquement à cette étape de travail.
REGION codée dans l’instruction JOB remplace la REGION codée dans l’instruction EXEC de toute étape de job.
COND
Utilisé pour contrôler l’exécution de l’étape de travail en fonction du code de retour de l’étape précédente.
Si un paramètre COND est codé dans une instruction EXEC d’une étape de job, le paramètre COND de l’instruction JOB (s’il est présent) est ignoré. Les différents tests pouvant être effectués à l’aide d’un paramètre COND sont expliqués dans Traitement conditionnel.
Exemple
Voici un exemple simple de script JCL avec les instructions JOB et EXEC :
Chaque JCL peut être composé de plusieurs étapes de job. Chaque étape de tâche peut exécuter directement un programme ou appeler une procédure qui, à son tour, exécute un ou plusieurs programmes (étapes de tâche). L’instruction, qui contient les informations de programme/procédure d’étape de job, est l’instruction EXEC.
Le but de l’instruction EXEC est de fournir les informations requises pour le programme/la procédure exécuté(e) dans l’étape de job. Les paramètres codés dans cette instruction peuvent transmettre des données au programme en cours d’exécution, peuvent remplacer certains paramètres de l’instruction JOB et peuvent transmettre des paramètres à la procédure si l’instruction EXEC appelle une procédure au lieu d’exécuter directement un programme.
Syntaxe
Voici la syntaxe de base d’une instruction JCL EXEC :
//Nom-step EXEC Position-param, Keyword-param
Description
Voyons la description des termes utilisés dans la syntaxe de l’instruction EXEC ci-dessus.
Nom-step
Ceci identifie l’étape de travail dans le JCL. Il peut être de longueur 1 à 8 avec des caractères alphanumériques.
EXEC
Il s’agit du mot-clé pour l’identifier en tant qu’instruction EXEC.
POSITION-PARAM
Ce sont des paramètres positionnels, qui peuvent être de deux types :
Paramètre de position
Description
PGM
Il s’agit du nom du programme à exécuter dans l’étape de travail.
PROC
Il s’agit du nom de la procédure à exécuter dans l’étape de travail. Nous en parlerons dans un chapitre séparé.
KEYWORD-PARAM
Voici les différents paramètres de mots-clés pour l’instruction EXEC. Vous pouvez utiliser un ou plusieurs paramètres en fonction des besoins et ils sont séparés par une virgule :
Paramètre de mot-clé
Description
PARM
Utilisé pour fournir des données paramétrées au programme en cours d’exécution dans l’étape de job. Ceci est un champ dépendant du programme et n’a pas de règles définies, sauf que la valeur PARM doit être incluse entre guillemets en cas de caractères spéciaux.
Par exemple donné ci-dessous, la valeur “CUST1000” est transmise sous forme de valeur alphanumérique au programme. Si le programme est en COBOL, la valeur transmise via un paramètre PARM dans un JCL est reçue dans la LINKAGE SECTION du programme.
ADDRSPPC
Ceci est utilisé pour spécifier si l’étape de travail nécessite un stockage virtuel ou réel pour l’exécution. Le stockage virtuel est paginable alors que le stockage réel ne l’est pas et est placé dans la mémoire principale pour exécution. Les étapes de travail, qui nécessitent une exécution plus rapide, peuvent être placées dans un stockage réel.
Voici la syntaxe : ADRESPC=VIRT | REAL
Lorsqu’un ADDRSPC n’est pas codé, VIRT est celui par défaut.
ACCT
Cela spécifie les informations comptables de l’étape de travail.
Voici la syntaxe : ACCT=(ID utilisateur)
Ceci est similaire aux informations de comptabilisation des paramètres positionnels dans l’instruction JOB. S’il est codé à la fois dans les instructions JOB et EXEC, les informations de comptabilisation dans l’instruction JOB s’appliquent à toutes les étapes de travail où un paramètre ACCT n’est pas codé. Le paramètre ACCT dans une instruction EXEC remplacera celui présent dans l’instruction JOB pour cette étape de travail uniquement.
L’instruction JOB est la première instruction de contrôle dans un JCL. Cela donne l’identité du travail au système d’exploitation (OS), dans le spool et dans le planificateur.
Les paramètres de l’instruction JOB aident les systèmes d’exploitation à allouer le bon planificateur, le temps CPU requis et à envoyer des notifications à l’utilisateur.
Syntaxe
Voici la syntaxe de base d’une instruction JCL JOB :
//Nom-job JOB Position-param, Keyword-param
Description
Voyons la description des termes utilisés dans la syntaxe de l’instruction JOB ci-dessus.
Nom-job
Cela donne un identifiant au job lors de sa soumission au système d’exploitation. Il peut être long de 1 à 8 avec des caractères alphanumériques et commence juste après //.
JOB
Il s’agit du mot-clé pour l’identifier en tant qu’instruction JOB.
Position-param
Il existe des paramètres positionnels, qui peuvent être de deux types :
Paramètre de position
Description
Information sur le compte
Il s’agit de la personne ou du groupe à qui le temps CPU est dû. Il est défini selon les règles de l’entreprise propriétaire des mainframes. S’il est spécifié comme (*), il prend alors l’identifiant de l’utilisateur, qui s’est actuellement connecté au terminal mainframe.
Nom du programmeur
Ceci identifie la personne ou le groupe qui est en charge du JCL. Ce paramètre n’est pas obligatoire et peut être remplacé par une virgule.
Keyword-param
Voici les différents paramètres de mot-clé, qui peuvent être utilisés dans l’instruction JOB. Vous pouvez utiliser un ou plusieurs paramètres en fonction des besoins et ils sont séparés par une virgule :
Paramètre de mot-clé
Description
CLASS
En fonction de la durée et du nombre de ressources requises par l’emploi, les entreprises attribuent différentes catégories d’emplois. Ceux-ci peuvent être visualisés comme des planificateurs individuels utilisés par le système d’exploitation pour recevoir les travaux. Placer les travaux dans le bon planificateur facilitera l’exécution des jobs.
Certaines entreprises ont des classes différentes pour les emplois dans les environnements de test et de production.
Les valeurs valides pour le paramètre CLASS sont les caractères de A à Z et les chiffres de 0 à 9 (de longueur 1).
Voici la syntaxe : CLASS=0 à 9 | A à Z
PRTY
Pour spécifier la priorité du job dans une classe de job. Si ce paramètre n’est pas spécifié, le job est ajouté à la fin de la file d’attente dans la CLASS spécifiée.
Voici la syntaxe : PRTY=N
Où N est un nombre compris entre 0 et 15 et plus le nombre est élevé, plus la priorité est élevée.
NOTIFY
Le système envoie le message de réussite ou d’échec (code de condition maximum) à l’utilisateur spécifié dans ce paramètre.
Voici la syntaxe : NOTIFY=”userid | &SYSUID”
Ici, le système envoie le message à l’utilisateur “userid” mais si nous utilisons NOTIFY = &SYSUID, alors le message est envoyé à l’utilisateur soumettant le JCL.
MSGCLASS
Pour spécifier la destination de sortie des messages système et de travail lorsque le travail est terminé.
Voici la syntaxe : MSGCLASS=CLASS
Les valeurs valides de CLASS peuvent aller de “A” à “Z” et de “0” à “9”. MSGCLASS = Y peut être défini comme une classe pour envoyer le journal des jobs au JMR (JOBLOG Management and Retrieval : un référentiel dans les mainframes pour stocker les statistiques des jobs).
MSGLEVEL
Spécifie le type de messages à écrire dans la destination de sortie spécifiée dans MSGCLASS.
Voici la syntaxe : MSGLEVEL=( ST, MSG )
ST = Type d’instructions écrites dans le journal de sortie – Lorsque ST = 0, instructions Job uniquement. – Lorsque ST = 1, JCL ainsi que les paramètres symboliques sont développés. – Lorsque ST = 2, entrée JCL uniquement.
MSG = Type de messages écrits dans le job de sortie. – Lorsque MSG = 0, les messages d’allocation et de fin sont écrits à la fin d’un travail anormal. – Lorsque MSG = 1, les messages d’allocation et de fin sont écrits quelle que soit la nature de l’achèvement du travail.
TYPRUN
Spécifie un traitement spécial pour le job.
Voici la syntaxe : TYPRUN = SCAN | HOLD
Où SCAN et HOLD ont la description suivante : – TYPRUN = SCAN vérifie les erreurs de syntaxe du JCL sans l’exécuter. – TYPRUN = HOLD met le travail en attente dans la file d’attente des jobs. Pour libérer le job, “A” peut être tapé contre le job dans le SPOOL, ce qui amènera le job à s’exécuter.
TIME
Spécifie l’intervalle de temps à utiliser par le processeur pour exécuter le travail.
Voici la syntaxe : TIME=(mm, ss) ou TIME=ss
Où mm = minutes et ss = secondes
Ce paramètre peut être utile lors du test d’un programme nouvellement codé. Afin de s’assurer que le programme ne s’exécute pas trop longtemps à cause d’erreurs de bouclage, un paramètre de temps peut être codé de sorte que le programme se termine anormalement lorsque le temps CPU spécifié est atteint.
REGION
Spécifie l’espace d’adressage requis pour exécuter une étape de travail dans le job.
Voici la syntaxe : REGION=nK | nM
Ici, la REGION peut être spécifiée comme nK ou nM où n est un nombre, K est un kilo-octet et M est un méga-octet.
Lorsque REGION = 0K ou 0M, le plus grand espace d’adressage est fourni pour l’exécution. Dans les applications critiques, le codage de 0K ou 0M est interdit pour éviter de gaspiller l’espace d’adressage.
Ici, l’instruction JOB est étendue au-delà de la 70e position d’une ligne, nous continuons donc à la ligne suivante qui devrait commencer par “//” suivi d’un ou plusieurs espaces.
Paramètres divers
Il existe peu d’autres paramètres pouvant être utilisés avec l’instruction JOB, mais ils ne sont pas fréquemment utilisés :
ADDRSPPC
Type de stockage utilisé : Virtuel ou Réel
BYTES
Taille des données à écrire dans la log de sortie et action à entreprendre lorsque la taille est dépassée.
LINES
Nombre maximum de lignes à imprimer dans la log de sortie.
PAGES
Nombre maximum de pages à imprimer dans la log de sortie.
USER
ID utilisateur utilisé pour soumettre le job
PASSWORD
Mot de passe de l’ID utilisateur spécifié dans le paramètre USER.
COND et RESTART
Ceux-ci sont utilisés dans le traitement conditionnel des étapes de job et sont expliqués en détail lors de la discussion sur le traitement conditionnel.
Chacune des instructions JCL est accompagnée d’un ensemble de paramètres pour aider les systèmes d’exploitation à terminer l’exécution du programme. Les paramètres peuvent être de deux types :
Paramètres de position
Apparaît à la position et dans l’ordre prédéfinis dans l’instruction. Exemple : Le paramètre d’informations comptables ne peut apparaître qu’après le mot-clé JOB et avant le paramètre du nom du programmeur et les paramètres du mot-clé. Si un paramètre positionnel est omis, il doit être remplacé par une virgule.
Les paramètres positionnels sont présents dans les instructions JOB et EXEC. Dans l’exemple ci-dessus, PGM est un paramètre positionnel codé après le mot clé EXEC.
Paramètres du mot-clé
Ils sont codés après les paramètres de position, mais peuvent apparaître dans n’importe quel ordre. Les paramètres de mots-clés peuvent être omis s’ils ne sont pas nécessaires. La syntaxe générique est KEYWORD= value . Exemple : MSGCLASS=X, c’est-à-dire que le journal du job est redirigé vers le SPOOL de sortie après l’achèvement du job.
Dans l’exemple ci-dessus, CLASS, MSGCLASS et NOTIFY sont des paramètres de mots clés de l’instruction JOB. Il peut également y avoir des paramètres de mots clés dans l’instruction EXEC.
Ces paramètres ont été détaillés dans les chapitres suivants avec des exemples appropriés.
Les instructions JCL numérotées ont été expliquées ci-dessous :
(1) Instruction JOB – Spécifie les informations requises pour la mise en file d’attente du travail, telles que l’ID du travail, la priorité d’exécution, l’ID utilisateur à notifier à la fin du travail.
(2) Instruction //* – Il s’agit d’une instruction de commentaire.
(3) Instruction EXEC – Spécifie le PROC/Programme à exécuter. Dans l’exemple ci-dessus, un programme SORT est en cours d’exécution (c’est-à-dire trier les données d’entrée dans un ordre particulier)
(4) Instruction DD d’entrée – Spécifie le type d’entrée à transmettre au programme mentionné en (3). Dans l’exemple ci-dessus, un fichier séquentiel physique (PS) est passé en entrée en mode partagé (DISP = SHR).
(5) Instruction DD de sortie – Spécifie le type de sortie à produire par le programme lors de l’exécution. Dans l’exemple ci-dessus, un fichier PS est créé. Si une instruction s’étend au-delà de la 70e position d’une ligne, elle se poursuit sur la ligne suivante, qui doit commencer par “//” suivi d’un ou plusieurs espaces.
(6) Il peut y avoir d’autres types d’instructions DD pour spécifier des informations supplémentaires au programme (dans l’exemple ci-dessus : la condition SORT est spécifiée dans l’instruction DD SYSIN) et pour spécifier la destination du journal des erreurs/exécutions (exemple : SYSUDUMP/ SYSPRINT). Les instructions DD peuvent être contenues dans un ensemble de données (fichier mainframe) ou sous forme de flux de données (informations codées en dur dans le JCL), comme indiqué dans l’exemple ci-dessus.
(7) Instruction /* marque la fin des données du flux.
Toutes les instructions JCL, à l’exception des données de flux, commencent par //. Il doit y avoir au moins un espace avant et après les mots clés JOB, EXEC et DD et il ne doit y avoir aucun espace dans le reste de l’instruction.
Un JOB est une unité de travail qui peut être composée de plusieurs étapes de travail. Chaque étape de travail est spécifiée dans un langage de contrôle des jobs (JCL – Job Control Language) via un ensemble d’instructions de contrôle des jobs.
Le système d’exploitation utilise le système d’entrée des travaux (JES – Job Entry System) pour recevoir les travaux dans le système d’exploitation, planifier leur traitement et contrôler la sortie.
Le traitement des jobs passe par une série d’étapes comme indiqué ci-dessous :
Processus de traitement de job
Soumission de job Soumission du JCL au JES (Job Entry System).
Conversion de job Le JCL avec le PROC est converti en un texte interprété pour être compris par JES et stocké dans un ensemble de données, que nous appelons SPOOL.
Job Queuing JES décide de la priorité du job en fonction des paramètres CLASS et PRTY dans l’instruction JOB (expliqué dans le chapitre JCL – Instruction JOB ). Les erreurs JCL sont vérifiées et le travail est planifié dans la file d’attente des travaux s’il n’y a pas d’erreurs.
Exécution du job Lorsque le travail atteint sa priorité la plus élevée, il est repris pour exécution à partir de la file d’attente des travaux. Le JCL est lu à partir du SPOOL, le programme est exécuté et la sortie est redirigée vers la destination de sortie correspondante, comme spécifié dans le JCL.
Purge Lorsque le job est terminé, les ressources allouées et l’espace JES SPOOL sont libérés. Afin de stocker le journal des job, nous devons copier le journal des job dans un autre ensemble de données (dataset) avant qu’il ne soit réalisé à partir du SPOOL.
Liste de certaines des transactions CICS importantes
CESN
CESN est connu sous le nom de CICS Execute Sign On.
CESN est utilisé pour se connecter à la région CICS.
Nous devons fournir l’ID utilisateur et le mot de passe donnés par l’administrateur CICS pour se connecter à CICS. La capture d’écran suivante montre à quoi ressemble l’écran de connexion –
CEDA
CEDA est connu sous le nom de CICS Execute Definition and Administration. Il est utilisé par les administrateurs système CICS pour définir les entrées de table CICS et d’autres activités d’administration.
CEMT
CEMT est connu sous le nom de CICS Execute Master Terminal. Il est utilisé pour demander et mettre à jour l’état des environnements CICS ainsi que pour d’autres opérations système.
En utilisant la commande CEMT, nous pouvons gérer les transactions, les tâches, les fichiers, les programmes, etc.
Pour obtenir toutes les options possibles, tapez CEMT et appuyez sur ENTER. Il affichera toutes les options.
CECI
CECI est connu sous le nom d’interpréteur de commandes d’exécution CICS. De nombreuses commandes CICS peuvent être exécutées à l’aide de CECI.
CECI est utilisé pour vérifier la syntaxe de la commande. Il exécute la commande, uniquement si la syntaxe est correcte.
Tapez l’option CECI sur l’écran CICS vide après vous être connecté. Elle vous donne la liste des options disponibles.
CEMT est essentiellement utilisé pour charger un nouveau programme dans le CICS ou pour charger une nouvelle copie du programme dans le CICS après la modification du programme ou du mapset.
CEDF
CEDF est connu sous le nom de CICS Execute Debug Facility. Il est utilisé pour déboguer le programme étape par étape, ce qui aide à trouver les erreurs.
Tapez CEDF et appuyez sur Entrée dans la région CICS. Le message Le terminal est en mode EDF s’affiche. Tapez maintenant l’identifiant de la transaction et appuyez sur la touche Entrée. Après l’initiation, à chaque touche d’entrée, une ligne est exécutée. Avant d’exécuter une commande CICS, il affiche l’écran dans lequel nous pouvons modifier les valeurs avant de continuer.
CCMC
CMAC est connu sous le nom de messages CICS pour les codes de fin anormale. Il est utilisé pour trouver l’explication et les raisons des codes de fin anormale CICS.
CESF
CESF est connu sous le nom de CICS Execute Sign Off. Il est utilisé pour se déconnecter de la région CICS.
CEBR
CEBR est connu sous le nom de CICS Execute Temporary storage Browse. Il est utilisé pour afficher le contenu d’une file d’attente de stockage temporaire ou TSQ.
CEBR est utilisé lors du débogage pour vérifier si les éléments de la file d’attente sont écrits et récupérés correctement. Nous discuterons plus de TSQ dans les prochains modules.
Afin d’éviter de faire tomber le moniteur CICS lorsqu’une erreur est provoquée par une transaction, CICS émet un ordre SVC pour intercepter l’abend.
Ainsi par exemple, lors d’une opération arithmétique condensée avec des variables EBCDIC en COBOL (ce qui déclenche un program check au niveau du système d’exploitation), l’abend obtenu n’est pas le même qu’en environnement batch (qui produit un abend system S0C7 ).
Lorsque le système d’exploitation détecte le program check, il redonne le contrôle à CICS qui abandonne la tâche par un code qui lui est propre : ASRA. Tout abend ASRA signifie qu’un programme a commis une violation de type program check.
En COBOL, généralement cette erreur est due à une tentative d’opération arithmétique sur des variables qui ont des types d’images mixtes, ou qui n’ont pas été correctement initialisées.
La première étape de l’analyse consiste à trouver l’endroit où s’est produit l’abend, c’est-à-dire de relever le PSW (program status word) au moment du program check. Cette information est disponible dans un dump, ou peut être retrouvée par EDF. Ensuite, il est nécessaire de trouver dans quel programme s’est produit l’erreur, et à partir de là l’instruction fautive. En général, le coupable est le programme qui était en cours d’exécution lors de l’abend.
Tous les codes AEIx et AEYx sont le résultat de conditions exceptionnelles rencontrées dans des programmes, et pour lesquelles aucune commande HANDLE CONDITION n’est active.
Le tableau de la page suivante liste les principaux codes abend de cette famille.
Après chaque code, figurent les informations suivantes : la condition exceptionnelle associée, le type de commande, et les valeurs correspondantes des champs EIBFN et EIBRCODE .
Les raisons de ces abend sont détaillées dans la brochure CICS/ESA Application
Programming Référence pour les conditions correspondantes.
Certaines erreurs, comme ILLOGIC et INVREQ, sont liées à plusieurs causes.
Par exemple, sur un abend ILLOGIC, l’octet 1 du champ EIBRCODE contient le code retour VSAM et l’octet 2 contient le code erreur VSAM.
Si l’on détermine que la condition est le résultat d’une erreur de logique dans le programme, il faut corriger le programme et refaire le test.
Si par contre cette condition peut survenir normalement, il est nécessaire d’ajouter une commande HANDLE CONDITION dans le programme et de la gérer.
Liste des principaux codes abend de la famille AEIx et AEYx
Code
Condition
Service
EIBFN
EIBRCODE
AEIA
ERROR
N/A
N/A
AEIK
TERMIDERR
ICP
10
12
AEIL
FILENOTFOUND
FCP
06
01
AEIM
NOTFND
FCP
06
81
OU ICP
10
81
AEIN
DUPREC
FCP
06
82
AEIP
INVREQ
FCP
06
08
OU TSP
0A
20
OU PCP
0E
E0
AEIQ
IOERR
FCP
06
80
AEIR
NOSPACE
FCP
06
83
OU TSP
0A
08
AEIS
NOTOPEN
FCP
06
0C
AEIT
ENDFILE
FCP
06
0F
AEIU
ILLOGIC
FCP
06
02
AEIV
LENGERR
FCP
06
E1
OU TSP
0A
E1
OU ICP
10
E1
AEIZ
ITEMERR
TSP
0A
01
AEI0
PGMIDERR
PCP
0E
01
AEI1
TRANSIDERR
ICP
10
11
AEI3
INVTSREQ
ICP
10
14
AEI8
IOERR
TSP
0A
04
OU ICP
10
04
AEI9
MAPFAIL
BMS
18
04
AEYB
INVMPSZ
BMS
18
08
AEYH
QIDERR
TSP
0A
02
Informations supplémentaires:
En absence d’une commande HANDLE CONDITION, les conditions exeptionnelles suivantes auront comme effet un arrêt anormal de la tâche avec un code retour abend au noveau de l’interface correspondant au tableau ci-dessous
Ce code abend survient lors de l’utilisation d’un fichier en statut DISABLED.
Ce code se produit rarement. Si le fichier est fermé pour une quelconque raison, et si cette condition n’est pas gérée, c’est le code abend AEIS qui est émis à la place.
En cas d’abend AFCA, le fichier incriminé peut être retrouvé par la transaction CEMT suivante :
CEMT INQUIRE DATASET ( nom-fichier )
Le problème disparaît dès que le fichier est rendu disponible.