Discussion :

[Exosh]

Bonjour,

Je débute sur Z/OS et, après avoir vu quelques tutoriels, je me pose encore une petite question.

Sous GCOS, il est possible de faire un jump pour aller à une étiquette et, par conséquent, pour sauter des bouts de JCL. Existe-t-il un équivalent sous Z/OS ? Le RESTART permet de faire cela, mais il ne semble utile qu'en cas d'abort et non pour sauter des bouts de JCL en fonction des values.

Merci.

[Luc Orient]

... Sous GCOS ...

Quel GCOS ?

il est possible de faire un jump pour aller à une étiquette et, par conséquent, pour sauter des bouts de JCL. Existe-t-il un équivalent sous Z/OS ? Le RESTART permet de faire cela, mais il ne semble utile qu'en cas d'abort et non pour sauter des bouts de JCL en fonction des values. Merci.

Non, à ma connaissance, pas de strict équivalent, en matière de JCL z/OS ...

[Exosh]

Quel GCOS ?
Non, à ma connaissance, pas de strict équivalent, en matière de JCL z/OS ...

GCOS 7. Je faisais un simple comparatif.

J'ai à peine regardé Rexx pour le moment, mais j'ai vu qu'il pouvait être utilisé comme du JCL (cours pour débutant, trouvé sur developpez.com). Je suppose qu'avec ses conditions il me permettrait d'avoir un résultat similaire à ce que je recherche.

En tout cas, merci pour ta réponse.

[Luc Orient]

J'ai à peine regardé Rexx pour le moment, mais j'ai vu qu'il pouvait être utilisé comme du JCL (cours pour débutant, trouvé sur developpez.com). Je suppose qu'avec ses conditions il me permettrait d'avoir un résultat similaire à ce que je recherche.

A mon sens REXX est plutôt un langage de script qu'un véritable langage de commande. mais bon, parfois la frontière peut apparaître mince entre les deux types d'outils.

Sinon, au niveau du JCL et pour gérer des cas alternatifs il y a les très pratiques instructions JCL IF / THEN / ELSE / ENDIF.

[Exosh]

Sinon, au niveau du JCL et pour gérer des cas alternatifs il y a les très pratiques instructions JCL IF / THEN / ELSE / ENDIF.

C'est limité aux erreurs/anomalies des steps. L'absence d'erreurs/anomalies étant prise en compte, il doit être possible, dans certains cas, de sauter des bouts de JCL.

Merci pour tes réponses. Je vais mettre le sujet en "résolu".

[escartefigue]

bonjour,

RESTART permet de sauter une partie du job, très pratique en cas de reprise ou de mise au point d'un job
Et de son côté, le JCL conditionnel permet de conditionner l'exécution d'un ou plusieurs steps aux CR d'un au plusieurs autres steps .

Du coup je ne vois pas ce qui peut manquer ?

[Exosh]

bonjour,

RESTART permet de sauter une partie du job, très pratique en cas de reprise ou de mise au point d'un job
Et de son côté, le JCL conditionnel permet de conditionner l'exécution d'un ou plusieurs steps aux CR d'un au plusieurs autres steps .

Du coup je ne vois pas ce qui peut manquer ?

Bonjour,

C'est vrai que l'on peut faire quelque chose qui se rapproche de ma demande avec RESTART et les conditions.

Toutefois, si je veux aller à un endroit précis d'un step (entre deux allocations de fichiers temporaires créés à partir de deux fichiers présents sur disque par exemple) comment faire ? Pour l'exemple on va partir du principe que la première allocation a réussi, mais pas la seconde.

Avec RESTART, il y a les chekpoints. Déjà, j'avoue ne pas comprendre comment ils fonctionnent précisément. J'ai l'impression que dans un premier temps il faut passer le job avec un SYSCKEOV et un CHKPT=EOV, puis repasser le job avec RESTART=(step, chekid) et un SYSCHK. J'ai fait quelques tests qui n'ont pas été concluant. S'il faut vraiment mettre des checkpoints partout pour avoir plus de possibilités de relance, ça risque d'alourdir considérablement le code JCL.

Sauf erreur de ma part, les conditions fonctionnent au niveau des steps seulement (EXEC).

[Luc Orient]

J'ai parfois vu du RESTART au STEP (avec des avantages et des inconvénients), mais je n'ai jamais vu de RESTART à l'intérieur d'un STEP sur un point de reprise. Mais sans doute, n'ai je pas tout vu ...

A titre de comparaison, que permet le JCL de GCOS7 ?

[escartefigue]

Attention : le restart au step est du ressort du JOB mais le restart sur un point de synchro est du ressort du programme. Il faut que le programme ait sauvegardé un contexte d'exécution qui lui permette de redémarrer au point souhaité (en général il s'agit d'une valeur d'identifiant sauvegardée dans une table du SGBD au moment du commit)

[Exosh]

A titre de comparaison, que permet le JCL de GCOS7 ?

JUMP NOM_ETIQUETTE;
..instructions..
NOM_ETIQUETTE:
..instructions..

On peut mettre le nom de l'étiquette et le jump n'importe où, tant que ça ne coupe pas une instruction en deux. On peut mettre une étiquette après chaque allocation de fichier par exemple et créer un jump, en cas d'abort, ce qui permettra de sauter les allocations qui ont marché. Il est même possible d'utiliser les values/variables pour le jump et donc de sauter des parties de code en ne touchant que la déclaration des values.

Un jump sur une étiquette qui n'existe pas entraîne un abort mais une étiquette sans jump ne pose pas de problème. C'est rapide à écrire et très utile.

Attention : le restart au step est du ressort du JOB mais le restart sur un point de synchro est du ressort du programme. Il faut que le programme ait sauvegardé un contexte d'exécution qui lui permette de redémarrer au point souhaité (en général il s'agit d'une valeur d'identifiant sauvegardée dans une table du SGBD au moment du commit)

Si je comprends bien, dans le code ci-dessous trouvé sur https://www.tutorialspoint.com/jcl/j...processing.htm, chk5 se trouve dans le programme MYCOBB et le JCL sera lu à partir du début de STP01, c'est ça ?

//CHKSAMP JOB CLASS=6,NOTIFY=&SYSUID,RESTART=(STP01,chk5)
//*
//SYSCHK DD DSN=SAMPLE.CHK,DISP=OLD
//STP01 EXEC PGM=MYCOBB
//*SYSCKEOV DD DSNAME=SAMPLE.CHK,DISP=MOD
//IN1 DD DSN=SAMPLE.IN,DISP=SHR
//OUT1 DD DSN=SAMPLE.OUT,DISP=(,CATLG,CATLG)
// CHKPT=EOV,LRECL=80,RECFM=FB

[escartefigue]

Je ne connais pas ce type de reprise par checkpoint JCL et je ne l'ai jamais rencontré.

Je ne comprends d'ailleurs pas quel peut en être l'utilité :
- si le traitement concerne des mises à jour de bases de données relationnelles, alors seul le SGBD lui même peut assurer la cohérence des données dans la base. Un fichier séquentiel qui ne fait pas partie des objets de la BDD ne saurait garantir l'intégrité des données post reprise.
- si le traitement ne concerne que des objets hors BDD, alors l'intérêt d'une reprise à l'enregistrement est relativement limité, mais pourquoi pas

Ce dont je parlais plus haut, c'est la possibilité pour un traitement qui modifie une BDD de redémarrer à chaud suite à un plantage. Pour ce besoin, il faut que le traitement en question (le programme principal) ait prévu un mode de démarrage en "restart" (avec positionnement juste après le dernier commité, ce qui implique un traitement selon une certaine séquence)

[Exosh]

Ce dont je parlais plus haut, c'est la possibilité pour un traitement qui modifie une BDD de redémarrer à chaud suite à un plantage. Pour ce besoin, il faut que le traitement en question (le programme principal) ait prévu un mode de démarrage en "restart" (avec positionnement juste après le dernier commité, ce qui implique un traitement selon une certaine séquence)

Ok, je comprends mieux.

Un fichier séquentiel qui ne fait pas partie des objets de la BDD ne saurait garantir l'intégrité des données post reprise.

Justement, dans mon exemple, le premier fichier est créé, mais pas le second. Le JCL est en abort. Il est inutile de toucher au premier, mais il faut créer le second. Je n'ai pas encore testé, mais je suppose que je peux faire :
SET MACHIN=(NEW,CATLG)
... DES INSTRUCTIONS ...
... DD .. DISP=&MACHIN
Si cela est possible, il me suffirait de mettre ce set avant le fichier que je dois créer et de mettre un SET MACHIN=SHR avant le fichier déjà créé. Bien sûr, le RESTART est nécessaire dans cet exemple.